hakavlad |
|
Темы:
0
Сообщения:
21
Участник с: 19 июня 2020
|
vall Как раз в это время в zen ядре была такая проблема - избыточно агрессивные убийства, даже когда своп не исчерпан - https://github.com/zen-kernel/zen-kernel/issues/225 которая далее была исправлена. Прошу повторить тесты снова с актуальным zen ядром - с дефолтами (с mg-LRU), и с выключенным mgLRU (и соответственно с работающим le9). Обратите внимание, что le9 не будет защищать кэш файлов при исчерпании свопа - по умолчанию положительное значение имеет только ручка vm.clean_low_kbytes. Для включения жеской защиты кэша (чтоб быстро приходил киллер) крутите vm.clean_min_kbytes. Выключать mgLRU можно с помощью скрипта https://github.com/hakavlad/mg-lru-helper или напрямую через echo 0 | sudo tee /sys/kernel/mm/lru_gen/enabled |
vall |
|
Темы:
45
Сообщения:
1786
Участник с: 28 марта 2017
|
Со временем с сегодняшнего дня сложновато. Если/как вдруг создастся окно обязательно сделаю. P.S. Чтобы долго не ждать пока на словах и 4 процесса. Картинки потом. 5.13.10-zen1-1-zen #1 ZEN SMP PREEMPT Thu, 12 Aug 2021 21:59:17 +0000 x86_64 GNU/Linux
|
vall |
|
Темы:
45
Сообщения:
1786
Участник с: 28 марта 2017
|
1. Всё по умолчанию. 16 процессов в четырёх окнах. В нескольких случаях посыпался starship. Время 9 мин. 40 сек. (Konsole <4>) указано с момента вызова команды утилитой fzf до практического нажатия. Поэтому ориентироваться на эти данные нельзя. В реальности всё отработало примерно за 16 секунд.
2. Выключаем mgLRU
ВЫВОДЫ: В обоих случаях система под нагрузкой оставалась работоспособной. Были небольшие подтормаживания (особенно при выключении mgLRU). Но в целом ОС полностью восстанавливала работоспособность за 16..22 секунды максимум. |