Тестируем Linux 5.12—5.17 с патчем Multigenerational LRU Framework

Сказали же, что одно другому не противоречит. Или ты всерьез считаешь, что не нужно прибивать компиляцию, когда память закончилась, а нужно зависать на неопределенный срок?

Помнишь историю успеха?

My success story: I have Archlinux with 8G RAM + zswap + swap. While developing,
I have lots of apps opened such as multiple LSP-servers for different langs,
chats, two browsers, etc… Usually, my system gets quickly to a point of SWAP-
storms, where I have to kill LSP-servers, restart browsers to free memory, etc,
otherwise the system lags heavily and is barely usable.

1.5 day ago I migrated from 5.11.15 kernel to 5.12 + the LRU patchset, and I
started up by opening lots of apps to create memory pressure, and worked for a
day like this. Till now I had not a single SWAP-storm, and mind you I got 3.4G
in SWAP. I was never getting to the point of 3G in SWAP before without a single
SWAP-storm.

Вариант: юзер имел низкий своппинес, и включение mgLRU просто отключило эту вредную фичу в виде низкого своппинес, и своппинг начал идти нормально (как при нормальном swappiness).

Не «средний отклик остаётся терпимым», а «интервалы подвисания остаются меньше, чем всё поубивать и сделать заново». И разница между этим довольно большая.

Ну и есть некоторый класс задач, когда разумно просто переждать забурившуюся в своп систему. Вроде компиляции браузера в 2 гб озу. Там теоретически меньше чем с 8 подходить не стоит, но 99% времени потребление меньше полгига на поток, а пик, когда происходит забуривание в своп хоть и длинный, но всё равно короче чем собирать всё то же самое в 1 поток против 4 (или вообще не собирать).

А ты прогони тесты на своём тредрипере и выложи их в студию.

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

Все так. Но есть и задачи, которым нужны низкие задержки. Например, видеосвязь и прочий чатинг.

У разработчика хромого нет денег на оперативку? Во дела-то.

Любитель бдсм? Я тут c 16гиг озу и 12потоками давно компиляния браузеров забросил.

Я тут c 16гиг озу и 12потоками давно компиляния браузеров забросил.

Вы батенька криворукий лошара. :)

Не школо-компилятору кого-то так называть.

Для этого случая есть сигнал 19. В конце концов одновременно интерактивные задачи и критический перегруз памяти выполняются только в кривых руках.

Я просто давно этим не занимался. Если конкретные цифры сейчас изменились, то принцип - нет.

Новый инструмент для оценки эффективности кэширования Выпуск r-test v0.1.0 -- инструмента для исследования эффективности кэширования файлов при нехватке памяти

https://github.com/hakavlad/r-test

С помощью этого инструмента установлено, например, что Multigenerational LRU Framework, недавно опубликованный гуглом, не вполне корректно работает со swappiness, точнее то, что swappiness (от 1 до 200) очень слабо влияет на результат, в отличие от тестов с применением классического LRU.

Когда зависают линуксы при MgLRU=1 - давление памяти и IO при зависании сильно зависит от vm.watermark_scale_factor.

фактор=1, пиковые давления:

Peak values:  avg10  avg60 avg300
-----------  ------ ------ ------
some cpu       0.90   0.16   0.03
-----------  ------ ------ ------
some io       41.58  17.84  45.60
full io       39.20  16.45  45.16
-----------  ------ ------ ------
some memory   98.98  92.95  48.48
full memory   98.98  92.91  48.44

фактор=1000, пиковые давления

Peak values:  avg10  avg60 avg300
-----------  ------ ------ ------
some cpu       0.00   0.00   0.00
-----------  ------ ------ ------
some io       78.79  74.29  64.39
full io       78.07  73.66  63.79
-----------  ------ ------ ------
some memory   26.36  21.89  18.16
full memory   26.36  21.89  18.16

С низким скейл фактором давление памяти очень высокое, а давл IO низкое, при зависании лампа диска не мигает даже.

С высоким фактором имеем умеренное давление памяти и значительное давление IO.

При зависании уровень MemFree стабилизируется на уровне high watermark:

MA=0=0% MF=1091 A=8306 F=3 AF=3 IF=1 D=0 C=3 SF=0 SU=978
MA=0=0% MF=1092 A=8306 F=2 AF=2 IF=1 D=0 C=2 SF=0 SU=978
MA=0=0% MF=1091 A=8306 F=3 AF=2 IF=1 D=0 C=3 SF=0 SU=978
MA=0=0% MF=1091 A=8306 F=3 AF=1 IF=2 D=0 C=3 SF=0 SU=978
MA=0=0% MF=1092 A=8306 F=3 AF=2 IF=1 D=0 C=3 SF=0 SU=978
MA=0=0% MF=1091 A=8306 F=4 AF=3 IF=2 D=0 C=4 SF=0 SU=978
MA=0=0% MF=1092 A=8306 F=4 AF=3 IF=1 D=0 C=4 SF=0 SU=978
MA=4172=43% MF=6270 A=3121 F=4 AF=3 IF=1 D=0 C=4 SF=473 SU=505
MA=7136=73% MF=9225 A=169 F=22 AF=10 IF=11 D=0 C=22 SF=523 SU=455
MA=7125=73% MF=9206 A=173 F=37 AF=19 IF=18 D=0 C=37 SF=528 SU=451
MA=7086=72% MF=9160 A=177 F=51 AF=27 IF=23 D=0 C=50 SF=531 SU=448
MA=7073=72% MF=9145 A=176 F=57 AF=28 IF=29 D=1 C=56 SF=532 SU=447
MA=7062=72% MF=9129 A=181 F=66 AF=30 IF=36 D=1 C=65 SF=536 SU=442
^C--
Got the SIGINT signal
Peak values:
  MA:  min 0.0, max 7135.51
  MF:  min 1088.59, max 9224.83
  A:   min 168.66, max 8305.79
  F:   min 1.39, max 388.23
  AF:  min 0.71, max 358.34
  IF:  min 0.0, max 35.96
  D:   min 0.0, max 1.03
  C:   min 1.39, max 388.2
  SF:  min 0.0, max 607.86
  SU:  min 370.46, max 978.32
Exit.

Здесь MemFree на уровне гигабайта при watermark_scale_factor=1000. C классическим LRU в аналогичной ситуации происходит падение свободной памяти до low wm и приходит оом.

post-factum

Итак, инструменты готовы (вышли 0.1.0 версии cache-bench и mem2log), будем тестировать, логировать и репортить.

Бамп годному треду.

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

Надо софт оптимизировать, чтобы память не жрал, а не oom-киллеры писать.

Золотые слова!

OOMK Killer приходит даже с еще большей задержой, чем при отключении multigen LRU;

Это похоже на то, что было описано здесь Linux 5.10 (комментарий)

Симптомы 12309 с mg-LRU https://github.com/zen-kernel/zen-kernel/issues/216 post-factum

удобный переключатель mg-LRU https://github.com/hakavlad/mg-lru-helper

ValdikSS

«А я и не сплю» от Yu Zhao https://github.com/zen-kernel/zen-kernel/issues/223#issuecomment-885462143

Репортнул неприход киллера. Однако до этого как раз был фикс по похожему поводу. Итог:

mg-LRU теперь ЖЕСТКО РЕЗЕРВИРУЕТ кэш (хз какой объем), даже перед оом кэш не отбрасывается.

swappiness так и остался сломан при использовании mg-LRU, проблему еще предстоит зарепортить.

post-factum ValdikSS

А теперь, когда завезли подобие резервирования в mg-LRU, появились и соответствующие проблемы: https://github.com/zen-kernel/zen-kernel/issues/223#issuecomment-885742654

Yu Zhao обещает запилить le9 для mglru:

Yes, sometime next week.

https://github.com/zen-kernel/zen-kernel/issues/218#issuecomment-886258323

Также он признал проблему с запаздывающим киллером, и даже исправил ее:

https://github.com/zen-kernel/zen-kernel/issues/223

Однако добавил новые проблемы:

[mgLRU] Early OOM and double kill with 5.12.19-zen2 https://github.com/zen-kernel/zen-kernel/issues/225

Проблема признана:

Yeah, I see the problem. Apparently my last fix wasn’t entirely correct. I’ll send another sometime next week.

Но исправление до сих пор не выпущено.

Вышел mgLRU v4 https://lore.kernel.org/lkml/20210818063107.2696454-1-yuzhao@google.com/ в возможностью защиты анонимки (но не файловой), см https://github.com/zen-kernel/zen-kernel/issues/218#issuecomment-897122505

возможностью защиты анонимки (но не файловой)

На самом деле и файловой тоже.

Протестировал 5.14-rc6 с mglru v4.

MGLRU v4 позволяет защищать и файловую, и анонимку.

Однако предоставляет только жесткую защиту всего рабочего набора без возможности отдельной защиты файловой или анонимки.

Итого:

• min_ttl_ms=1000: эффект слабый, защита незначтельна, незначительное ускорение прихода ООМ.
• min_ttl_ms=10000: эффект более заметен, однако может приходить ранний ООМ даже если свопа еще много.

При этом мягкой защиты нет при наличии свопа.

post-factum ValdikSS

Вышел mg-lru-helper v0.2.0 https://github.com/hakavlad/mg-lru-helper

вышел MG_LRU v5 https://lore.kernel.org/lkml/20211111041510.402534-1-yuzhao@google.com/

Почему ты еще не принял мглру? Рост перфоманса огромен же:

    MariaDB 20%+ faster
    Memcached 40%+ faster
    Apache Spark 10%+ faster
    MongoDB 20%+ faster

см https://github.com/zen-kernel/zen-kernel/issues/256#issuecomment-965940843

Хотя были у меня какие то надежды что они ускорят процесс.

См https://github.com/zen-kernel/zen-kernel/issues/256#issuecomment-965940843

И? Это вообще связано со свопингом? И кажется это узкоспециальная задача для узкоспециальных серверов, могу поспорить что на большинстве других задач поведение станет хуже.

это узкоспециальная задача для узкоспециальных серверов

узкоспециальных

половина серверов, если не больше, крутят бд.

5.12 - 5.14

старьё

Linux arch 5.15.1-arch1-2 #1 SMP PREEMPT Tue, 09 Nov 2021 16:16:12 +0000 x86_64 GNU/Linux

вышел MG_LRU v5 https://lore.kernel.org/lkml/20211111041510.402534-1-yuzhao@google.com/

для 515

btw у арчика примпт ядро дефолтное же?

Но оптимизировать серверы именно под кручение БД, вероятно в ущерб прочим функциям, имеет смысл именно на узкоспециализированных серверах баз данных.

Как оно с защитой working set’а работает?

Короче суть такова. min_ttl_ms не защищает отдельно файловые или анонимные, а работает только на уровне убийств.

То есть с одной стороны под защитой (min_ttl_ms=30000, например) кэш при своппинге может сильно упасть, с другой стороны в процессе своппинга на середине процесса может прийти киллер.

И невозможно подобрать удобное значение min_ttl_ms, при котором

• кэш будет защищен
• не будет ложных киллов где-то на полпути.

А мягкой защиты кэша и нет вовсе.

Еще момент: mmapped файлы избыточно перезащищены, для них как бы работает swappiness=200, а для немаппленных действует что-то вроде swappiness=100, немаппленные файл страницы спокойно вымываются, и для тех и других swappiness все также не работает.

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

Вот пример:

• с обычным lru под стрессом проблем нет, гуй жив: https://www.youtube.com/watch?v=g9GCmp-7WXw
• с mglru гуй виснет под стрессом: https://www.youtube.com/watch?v=TlTlb6abJuE, причем повышение min_ttl_ms приведет не к повышению отзывчивости, а просто к убийству стрессов.

Я понятно выразился?

именно под кручение БД, вероятно в ущерб

Откуда инфа, что в ущерб? Нет ни одного репорта об ущербе (на самом деле я мог бы привести пример - есть нагрузки, в которых mgLRU проигрывает).

Как оно с защитой working set’а работает?

Add /sys/kernel/mm/lru_gen/min_ttl_ms to protect the working set of a
given number of milliseconds. The OOM killer is invoked if this
working set cannot be kept in memory.

https://lkml.org/lkml/2021/11/10/1448

Инфы нет разумеется. Но здравый смысл подсказывает: если ты выкручиваешь оптимизацию под какую то конкретную операцию то однозначно пострадает что то другое.

выкручиваешь оптимизацию под какую то конкретную операцию

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

https://lwn.net/Articles/856931/

Я понятно выразился?

Чо-т хрень получается.

Разве серверы БД кто то настраивает на работу в свопе?

И я не смогу прочитать эту статью, у меня на перевод нету времени.

совсем кратко на русском тут https://www.opennet.ru/opennews/art.shtml?num=54972

Что именно непонятно?

У разработчика хромого нет денег на оперативку? Во дела-то.

А чё, хромой стал аналогичен по цене майбаху? Нет денег на озу, и ладно.

Возможно, стоит переедать с ноги аналитикам, маркетологам и другим людям, с чьей подачи сайты обвешивают «всяким»?

Ну, да, это я вроде как читал. И всё таки, свопинг и оом это не про настроенные серверы. И ещё была заметка что вроде как патчи гугла местами вызывают больше проблем чем решают.

написал бы вкратце в чем суть патча этого.

Вот на русском: https://justpaste.it/MGLRU kirill_rrr (там снова ничего не понятно)

свопинг и оом это не про настроенные серверы

Давление памяти бывает и в настроенных. То есть бывает нужно как минимум удалить холодный файловый кэш, чтоб освободить место для новых анонимных или файловых страниц. Тут-то mglru и помогает более точно находить неиспользуемые страницы.

Но по крайней мере эта статья будет непонятна раз в 20-30 быстрее.

Вообще там всё довольно понятно за исключением мелких деталей, которые вроде не важны для общей картины.

И, кстати, возможные проблемы и их причины там тоже указаны.

Кстати, как себя ведёт v5.16-rc1 без mglru, но с защитой?

С какой защитой?

mglru предоставляет защиту через min_ttl_ms. le9 через sysctl.

В 5.16 разве должно измениться по сравнению с 514-515? О чем ты? Откуда защита в 516 без доп. патчей?