Дефолт не для людей

https://access.redhat.com/documentation/ru-ru/red_hat_enterprise_linux/6/html...

2 — отказ обработки запросов, запрашивающих память, размер которой превышает суммарный размер памяти пространства подкачки и ОЗУ в соответствии с overcommit_ratio.

почему вы решили, что это как в винде? какому поведению это соответствует как в винде?

спасибо

Включаешь deadline - у него приоритет чтения перед записью. В большинстве случаев этого хватает.

это если проблема в работе i/o с накопителей.
а если проблема не в нём, а с ОЗУ? как выше некоторые пишут про overcommit_ratio

Windows по умолчанию ограничивает количество committed memory (доступной к использованию, приблизительный аналог выделенной страницы в Linux) суммой RAM и файла подкачки, опционально умноженной на небольшую константу.

http://video.ch9.ms/teched/na/2011/ppt/WCL406.pptx слайды 20-23.

Ведь цель по умолчанию - приемлемый отклик интерфейса, а не серверные функции.

для кого? с чего вдруг? меня вот сервера волнуют, а не твой десктоп. но вообще вместо планировщиков поищи тред хакавлада. hakavlad ему по-моему твой совет нужен, хотя он этого и не понимает.

От серверов тоже часто (но не всегда) требуется низкая, или хотя бы предсказуемая задержка, в том числе и интерфейса.

меня вот сервера волнуют,

значит ты должен знать, что делать, что поменять в ядре.

Оверкоммит ни при чем. А вот неправильные настройки vm - вполне себе «при чём». Вообще смысла гадать на кофйной гуще нет - для каждого случая надо индивидуально разбирать что имело место быть.

Вам показать ссылку на соответствующий параметр sysctl?

Ведь цель по умолчанию - приемлемый отклик интерфейса, а не серверные функции

Жир потек из экрана

Это который я упоминал десятью комментариями выше в контексте «как сделать поведение MM в Linux таким же как в Windows»?

ой слушай вообще не понял. какой там у тебя интерфейс на сервере. какие-то твои личные половые проблемы. не грузи меня ими.

значит ты должен знать, что делать, что поменять в ядре.

я-то знаю, но твой пост не информативен. вообще поток сознания.

I в CLI.

по-моему ты меня стебешь, а я даже этого не понимаю:) если у меня несколько сотен этих CLI, то как-то же я эту проблему решил)

Альтернативные планировщики i/o лучше дефолтных в ядре

Так было раньше, когда дефолтом был cfq.

Теперь же mq-deadline - отличный планировщик по умолчанию.

курсор в видеопамяти и в ОЗУ, и работает с процессором, какого чёрта он зависит от планировщика i/o

Работа io - это создание кэшей, которые конкурируют за память. Возможно кэш io вытесняет кэш видео.

Ведь цель по умолчанию - приемлемый отклик интерфейса, а не серверные функции

Линукс - это в основном серверные парки и большее значение имеет производительность.

почему ведущие дистрибутивы linux для десктопа (н.п. ubuntu, fedora, debian, arch) не включают их умолчанию?

На самом деле вопрос правильный - десктопные дистры могли бы и получше потюнить хотя бы sysctl - например, ограничивать dirty bytes.

На самом деле десктопные дистроделы ненавидят юзеров - даже в убунту используют обычный своп-файл вместо zram, и это в 2021.

В федора только в 2020 дошло до вкл zram по дефолту.

Десктопному линуксу надо минимум 8гб озу, что бы из за лишней вкладки в хроме у тебя все не зависло намертво, осталось решить вопрос что файлы на флешку записываются как попало, пишет что скопировалось, а на самом деле еще и половины нет на флешке

осталось решить вопрос что файлы на флешку записываются как попало, пишет что скопировалось, а на самом деле еще и половины нет на флешке

Решается уменьшением vm.dirty_background_bytes и vm.dirty_bytes.

Я так и не понял, надо переключаться на BFQ или нет? У меня сейчас mq-deadline.

Включаешь deadline - у него приоритет чтения перед записью. В большинстве случаев этого хватает.

cat /sys/block/sdb/queue/scheduler
[mq-deadline] none
darkshvein@lexx9:~$ cat /sys/block/sda/queue/scheduler
[mq-deadline] none


алсо, дэдлайн и стоял

Поддерживаю.

Но ни одна из этих опций не значит, что BFQ по умолчанию выбран. Только то, что он в принципе включен в ядре.

Выбранный I/O шедулер можно так посмотреть:

cat /sys/block/*/queue/scheduler

Не надо. На самом деле mqd хорош. Это при cfq имело смысл.

надо переключаться на BFQ или нет? У меня сейчас mq-deadline.

cat /sys/block/sd*/queue/scheduler
[none] mq-deadline bfq kyber 
mq-deadline [bfq] kyber none
mq-deadline bfq [kyber] none

ssd, hdd, флешка. 20.04.

Но это я выделывался-выделывался, да так и оставил.

Когда-то говорили, что bfq лучше, чем cfq для hdd. Теперь, видать, всё, времена mq.

Концепция подкачки — это вообще вредительство, особенно с современными объёмами оперативной памяти

Кажется, вы не в курсе, что такое концепция подкачки.

Кажется, вы не в курсе, что такое концепция подкачки.

Это отгрузка данных из оперативной памяти в сверхтормозной файл/раздел подкачки. В большинстве случаев это вредительство, приводящее к практически зависанию при большом использовании памяти. Подкачка имеет смысл разве что в компиляторе/линкере (и прочих пакетных задачах) и в неактивных вкладках браузера.

и в неактивных

this.
Правильная концепция:
1. ВСЕ процессы зеркалятся в своп (по возмоности, в свободное время)
2. ВСЕ неактивные процессы выкидываются из RAM, когда кому-то срочно нужна RAM
3. Тормоза только при возобновлении процесса
4. своп в разы больше ЛЮБОГО RAM
5. Нет, если RAM не хватает, в своп не уходим

В linux дистрах по умолчанию всё наоборот: своп работает как тормозная RAM

А по-подробнее можно? Почему не надо, чем хорош?

this.

Нет. Активная вкладка может запросто уйти в своп и зависнуть, если не поставить флаги запрета свопа (я не знаю браузеров, которые это умеют). Программы лучше ядра знают когда и что им можно свопить, а что нет.

2. ВСЕ неактивные процессы выкидываются из RAM, когда кому-то срочно нужна RAM

И это плохо. Неактивный процесс может срочно понадобиться (диспетчер задач, оболочка, файловый менеджер и т.п.). Лучше вернуть NULL процессу и не вешать систему. И процесс должен уметь это обработать (не открыть окно/вкладку и т.п.).

3. Тормоза только при возобновлении процесса

Не всегда. Да и с точки зрения ядра нет никакого «возобновления процесса». Процесс может ещё долго виснуть, потому что подгружаются необходимые для нового действия отгруженные страницы памяти.

4. своп в разы больше ЛЮБОГО RAM

Давайте убивать SSD ненужным свопом. Особенно учитывая пункт 1.

5. Нет, если RAM не хватает, в своп не уходим

Это как? Зачем тогда своп нужен?

На рхел8 по умолчанию mq-deadline, а в документации сказано, что bfq для десктопа. Как быть? Конкретно у меня ssd и hdd(помойка, торренты, он медленный, для ноутбука).

Реальная проблема бывает, когда качаешь на полной скорости торренты и смотришь одновременно кино, тогда заикается кино, надо снижать скорость. Я узнал про эти планировщики и пробовал разное, но эту проблему не снимает ни один, емнип.

Что mq-deadline, что bfq на HDD во время интенсивного I/O от тормозов и заиканий не избавляют, так что разницы особо нет что использовать. Я и то, и другое пробовал.

Ок, значит действительно по умолчанию BFQ там.

Это отгрузка данных из оперативной памяти в сверхтормозной файл/раздел подкачки

Напортив, в сверхбыстрый swap on zram.

В торрент-клиенте число потоков можно снижать.

https://www.youtube.com/watch?v=d4Sc80TMEtA

Вот смотри. Достаточно жирная компиляция с уходом в своп. Ни единого лага. 8 гиг памяти, 8 гиг своп на zram.

А это тебе ядро на заметку с патчем le9 https://copr.fedorainfracloud.org/coprs/atim/kernel-futex/

Демо см выше.

Как быть? Конкретно у меня ssd и hdd(помойка, торренты, он медленный, для ноутбука).

Ну, вот я пробовал именно для hdd bfq, можешь и ты так попробовать. Но я так оставил не потому, что так лучше, а потому, что так не хуже. 1 фигня, короче. Я и страшнее вещь скажу: с cfq тоже было ощущение, что не в планировщике дело.

ЗЫ. А у торрент-клиента какие-то настройки есть, сколько он качает в оперативку, при каком наполнении и как часто списывает на диск, etc?

Тот, кто захочет установить другой планировщик должен дойти своим мозгом, что нужно ядро с другими настройками.

Поправил

А в винде все просто работает!

А в винде все просто работает!

Там ядро профессионалы проектировали, это не наколеночная поделка как UNIX/Linux. Правда эти профессионалы много чего перемудрили, но работе это особо не мешает.

Смотрю на системник с Виндой. Человека рядом нет, а он просто работает. Это на нем для красоты и веселья так сделано, чтобы индикатор i/o как цветомузыка был. Это десятка, она в BSOD не выпадает, она просто выпадает. У человека, который не хочет ковырять систему, а хочет просто работать.

А лично я просто подкрутил

vm.swappiness
vm.vfs_cache_pressure
vm.watermark_scale_factor
vm.dirty_bytes
vm.dirty_background_bytes

и у меня просто работает, когда мне надо, а не когда Винде прибздится.

Ради интереса, объём памяти, значения указанных параметров vm.*?

free
                всего        занято        свободно       общая  буф./врем.    доступно
Память:      12175408        939560         9981912      377156     1253936     7706832
Подкачка:    13701116             0        13701116

vm.swappiness=100
vm.vfs_cache_pressure=50
vm.watermark_scale_factor=1000
vm.dirty_bytes=8388608
vm.dirty_background_bytes=8388608

Для заглядывающих любителей копипастить себе чужие настройки говорю: это просто пример по просьбе регистранта выше. ЭТО НЕ УНИВЕРСАЛЬНО.

Интересно, оптимум не подскажешь?

Ок, сунул в закладки, эти ядра из-за интел мне не в тему, поэтому пока пересел на рхел, для федор интел в пролёте, надо радеон покупать, а выбирать — целая история.