LINUX.ORG.RU

Слишком много free памяти

 , ,


0

1

Raspberry Pi 4 4Gb, Raspbian, ядро 6.1

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

rrr@raspberrypi:/media/files $ free -m
               total        used        free      shared  buff/cache   available
Mem:            3794        1969         671         788        1152         431
Swap:          38145        2898       35247

Тюнинг памяти:

echo z3fold > /sys/module/zswap/parameters/zpool
echo 25 > /sys/module/zswap/parameters/max_pool_percent
echo 1 > /sys/module/zswap/parameters/enabled
echo 64 > /proc/sys/vm/page-cluster
echo 100 > /proc/sys/vm/swappiness
echo 500 > /proc/sys/vm/watermark_scale_factor
echo 32768 > /proc/sys/vm/min_free_kbytes

Также подключена tmpfs в /tmp и туда вынесены временные файлы пользователя, как минимум кеш браузера, миниатюр и qml.

Насколько я знаю, free-память это не всякие кеши и буферы, не tmpfs, не zswap. До сих пр я не встречался с ситуациями, когда +-15-20% памяти простаивает в холостую во время дефицита - кроме одного раза, когда cgrops_mem позволял пользователю использовать в сеансе не более 50%, но даже там память использовалась под дисковый кеш. При открытии новых вкладок браузера система удерживает свободными от 480М до 800М. При создании крупного файла в /tmp показатель free кратковременно снижается, но затем память откачивается до того же уровня.

Ядро 6.1 перешло на cgrops v2, и я вроде как не вижу там управления памятью (для v1 я его всегда отключал), но возможно я просто не знаю куда смотреть. Но вообще по ощущениям похоже на какой то лимит со стороны cgrops.

Что это мжет быть? Свопинг конечно мягкий, но он чувствуется и кажется могло бы работать ещё лучше на эти самые 300-500М.

★★★★★

Последнее исправление: kirill_rrr (всего исправлений: 1)

Ответ на: комментарий от vbcnthfkmnth123

Побеждён лет 15 назад. В особо тяжёлых случаях проявляется с особо медленной флеш-памятью, но лечится кешами, буферами, и вот собственно «echo 32768 > /proc/sys/vm/min_free_kbytes» я против него добавлял, только 32М и 600М это большая разница.

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

kirill_rrr ★★★★★
() автор топика
Последнее исправление: kirill_rrr (всего исправлений: 2)
Ответ на: комментарий от kirill_rrr

Побеждён лет 15 назад

Сказки то не рассказывай. Понаставят SSD/NVME и потом рассказывают друг другу как всё хорошо, это как говорить что с дорогами в буреломе леса всё отлично, ведь у тебя гусеничный трактор 90тонн весом.

anonymous
()

Свопинг конечно мягкий, но он чувствуется

А тут пишут, что не чувствуется: )

впечатление такое будто это ssd

Правда, там ядра вроде актуальные, как минимум 6.8.

krasnh ★★★
()
Последнее исправление: krasnh (всего исправлений: 1)
Ответ на: комментарий от krasnh

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

Если бы оно было допустимым, оно бы означало readahead размером в 2**64 страниц — то есть фактически любой fault-in приводил бы к опустошению всего свопа.

intelfx ★★★★★
()
Последнее исправление: intelfx (всего исправлений: 4)

Свободная память - это «available». 431MB по-твоему много?
Кстати, такой большой своп бесполезен. Когда своп заполняется на объем больший, чем физическая память, обычно начинается swap thrashing, и система встаёт раком.

rupert ★★★★★
()
Ответ на: комментарий от rupert

Свободная память - это «available». 431MB по-твоему много?

Кстати не заметил сразу. Как так avail меньше чем free? Пахнет багом. Хотя к проблеме автора это конечно отношения не имеет.

431MB по-твоему много?

Всё относительно.

Кстати, такой большой своп бесполезен. Когда своп заполняется на объем больший, чем физическая память, обычно начинается swap thrashing, и система встаёт раком.

А вот и нет, разные бывают ситуации. Если у тебя реально замаплено 40ГБ и из них активны только 2ГБ, а остальное используется время от времени, то свап в 10 раз больше оперативки впишется идеально. Можно конечно сказать что такое проектирование прикладного софта - плохое, и возможно даже так и будет, но тем не менее.

firkax ★★★★★
()
Ответ на: комментарий от firkax

агрессивный свапинг

Утверждается, что для быстрых SSD/NVME, на которых своп, или для zram, vm.swappiness=100 хорошее значение.
Со zswap не знаю, он как бы в двух агрегатных состояниях - и RAM, и физический своп. Наверно, если HDD, то лучше не менять дефолт.

На SSD-дисках эти подходы практически равны по стоимости, поэтому установка vm.swappiness = 100 (т.е. полное равенство) может работать хорошо.
На вращающихся дисках swapping может быть значительно дороже, т.к. в целом он требует случайного чтения, поэтому вы скорее всего захотите сместиться в сторону меньшего значения.

krasnh ★★★
()
Последнее исправление: krasnh (всего исправлений: 1)

https://github.com/hakavlad/mg-lru-helper

Ты можешь выключить или вкл MGLRU. Это влияет на своппинг сильно. MGLRU - это чудо чудесное, кторое меняет всё. С ним swappiness работает иначе, например. Можешь сравнить поведение с MGLRU и без.

По старым опытам: c MGLRU можно получать сильный своппинг при swappiness=1, например.

hakavlad ★★★
()
Ответ на: комментарий от krasnh

zsmalloc до недавнего времени вообще не умел сбрасывать страницы на диск и в таком виде это была бесполезная игрушка. Как это работает после последних патчей и вошли ли они в 6.1 я не в курсе.

Прочитал статью и она мне совершенно не нравится. Он провёл непонятный тест на сборку ядра с некими неуказанными ограничениями cgrops и тут совсем не ясна глубина свопинга. В моих тестах с браузером zsmalloc в принципе не мог сбрасывать страницы и должен был с треском провалиться, так же как и zram без backing_dev - я его даже не гонял из за очевидной ненужности.

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

kirill_rrr ★★★★★
() автор топика
Последнее исправление: kirill_rrr (всего исправлений: 1)
Ответ на: комментарий от krasnh

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

firkax ★★★★★
()
Ответ на: комментарий от krasnh

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

kirill_rrr ★★★★★
() автор топика
Ответ на: комментарий от kirill_rrr

и вошли ли они в 6.1 я не в курсе

По арчвики, с 6.3. Я давал инфу на будущее обновление ПО.

В последних ядрах (старше 6.3.arch1-1) добавлен распределитель zsmalloc. Он хорошо работает в условиях малого количества доступной RAM и не тратит лишний раз память.

krasnh ★★★
()
Последнее исправление: krasnh (всего исправлений: 1)
Ответ на: комментарий от hakavlad

MGLRU включен?

ядро 6.1

Я всегда, в разных темах, советую использовать ядра ≥ 6.1, но никогда не прошу проверять, включен ли там MGLRU. Считая, что он там по умолчанию включен. Но другого я и не видел, используя оптимизированное кастомное ядро.
Но вот теперь в сомнениях.

krasnh ★★★
()
Ответ на: комментарий от kirill_rrr

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

Хороший планировщик в freebsd, в линуксах не жди.

firkax ★★★★★
()
Последнее исправление: firkax (всего исправлений: 1)
Ответ на: комментарий от intelfx

Прогнал тесты из предположения что там логарифм. Почти наверняка нет. Да, и в любом случае page-cluster никак не связан с резервированием свободной памяти, это всего лишь оптимальность блока для диска.

При малых значениях 1,2,3,4,5,6,8...14 сильный трешинг, причём самые худшие варианты при 3 и 5 - даже звук лагает.

При больших значениях 16,18,20,32,64 трешинг значительно меньше, причём лучши вариант при 32, а худшие - если значение не степень двойки.

256 нормально проглатывается, трешинг средний.

Большие значения и степени двойки улучшают восстановление из свопа - видимо это такая дефрагментация на ссд.

А, да, надо заметить, что предложенный как аргумент мануал относится к ядру 2.6.29

kirill_rrr ★★★★★
() автор топика
Последнее исправление: kirill_rrr (всего исправлений: 1)
Ответ на: комментарий от rupert

Можно подробнее?

available тоже слишком большой, 250-550, редкие просадки до 100.

По данным htop также остаётся значительные кусок неиспользованной под кеш памяти.

kirill_rrr ★★★★★
() автор топика
Ответ на: комментарий от rupert

431MB по-твоему много?

У меня всего 3794, так что больше 10% как ни крути. Практика показывает, что 3-5% резерва более чем достаточно.

Кстати, такой большой своп бесполезен.

Во первых резерв для tmpfs. Во вторых пространство чтобы ssd проще было балансировать износ. В третих свопинг до 150-300% от оперативки бывает вполне себе отзывчивым, от задачи конечно сильно зависит.

kirill_rrr ★★★★★
() автор топика
Ответ на: комментарий от kirill_rrr

мануал относится к ядру 2.6.29

Нет, он претерпел изменения, там выше строка «The Linux Kernel 6.8.0».

Так же, можно посмотреть раздел «swappiness», где упомянуто изменение от 0 до 200, которого не было в старых ядрах.

krasnh ★★★
()
Ответ на: комментарий от kirill_rrr

Просто поставь дефолтное 60 и, я почти уверен, увидишь разницу.

Кто то ставит 150 и 200, и это якобы даже лучше в каких то сценариях.

Наверно у них свап адекватного размера (>= ram).

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

firkax ★★★★★
()
Последнее исправление: firkax (всего исправлений: 1)
Ответ на: комментарий от hakavlad

intelfx

Определённо влияние есть. Причём значения 5-20 сбрасывают избыточный free примерно вдвое, до интервала 150-400М. Более низке значения дают ещё меньше (100-350М), но вызывают фризы и трэшинг при одновременном открытии нескольких новых вкладок. В любом случае, параметр used вырос примерно на полгига и это вроде даже сказывается на отзывчивости пачки вкладок в тестовом окне.

MGLRU был включен с параметром 1. Его включение явно сильно меняет поведение vm.watermark_scale_factor в сторону большего free. Долго пытался понять, как он влияет на отзывчивость... Короче всё сложно. Вроде бы отзывчивость во время свопинга лучше, даже если загнать watermark_scale_factor в 1-2, но при этом вроде бы ниже отзывчивость когда нет активного свопинга. Но в любом случае разница не слишком глобальная.

В итоге остановился на варианте MGLRU=0, vm.watermark_scale_factor=5

Ещё заметил, что сброс vm.watermark_scale_factor сделал avaliable больше чем free, и по итогу перенастройки запись данных на диск не выесняет used-память из оперативки (а до этого вытесняла).

kirill_rrr ★★★★★
() автор топика
Ответ на: комментарий от anonymous

Да ничего там не проявляется. Эту мифическую штуку в оригинале уже давным давно пофиксили, остались только похожие на неё косяки, когда одно отдельное приложение ждёт своего собственного io, и то чтобы лично оно встало - должны звёзды сойтись.

kirill_rrr ★★★★★
() автор топика
Ответ на: комментарий от kirill_rrr

В итоге остановился на варианте MGLRU=0,

Ирония в том, что упомянутый MGLRU уже правили и улучшали в последующих ядрах (ядро 6.1 вышло 12.12.2022).

Я потому и говорю, хотите сидеть на ‘любимых’ старых ядрах, пересобирайте их с последними патчами, того же MGLRU, например. Нет желания компилить, ставьте актуальные ядра, на сегодня это 6.8.
Иначе все это ерунда, и, соответственно, наглядный пример, когда проще выключить ‘сырой’ MGLRU.

krasnh ★★★
()
Ответ на: комментарий от firkax

Попробовал 50. Разница действительно есть. used-память ожидаемо начинает вытесняться позже и интервал free смещается с (теперь уже) 150-350М на 40-350М. Причём после завершения выделения памяти что то продолжает откачку до 200-300М.

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

Думаю всё таки снизить swappines до 75. Уже открытые вкладки переключаются чуть бодрее.

kirill_rrr ★★★★★
() автор топика
Ответ на: комментарий от krasnh

хотите сидеть на ‘любимых’ старых ядрах, пересобирайте их с последними патчами

Ага, вот если бы ещё пересборка и загрузка ядра под arm была простым делом на один вечер... Но Пи4 очень отличается от Пи3, ядра 4.4, 6.1 и 6.8 будут сильно отличаться между собой, что такое device-tree и как это работает я не знаю, да и дебианы 8, 11 и 12 тоже сильно отличаются. Так что может быть в течении месяца я и перенаучусь пересобирать вменяемое ядро.

kirill_rrr ★★★★★
() автор топика