LINUX.ORG.RU

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

 , ,


0

3

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)
Ответ на: комментарий от rtxtxtrx

А вообще всё сводится к тому, что мне нужно ждать ядра 6.8++ и уже там перепроверять поведение всех опций по новой. Этот новый планировщик памяти ещё глюкодром, а в 6.1 - особенно.

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

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

anonymous
()
28 января 2025 г.
Ответ на: комментарий от kirill_rrr

z3fold

Прочитал статью и она мне совершенно не нравится. Он провёл непонятный тест

Все, капец ‘котенку’, теперь официально Распределитель Z3fold Планируется удалить из ядра Linux.

Поскольку Z3fold был признан устаревшим в течение двух циклов работы ядра без жалоб, в настоящее время ожидаются исправления для удаления Z3fold из ядра Linux.

Ожидается, что устаревание/удаление Zbud также произойдет в ближайшее время

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

Они вроде как устранили ключевой недостаток zsmalloc. Он не мог выгружать память! А по плотности упаковки изначально был круче двух других. Хотя кажется ты и сам это знаешь.

kirill_rrr ★★★★★
() автор топика
Последнее исправление: kirill_rrr (всего исправлений: 1)
Ответ на: комментарий от LamerOk
rrr@raspberrypi:/tmp/yt $ free -m
               total        used        free      shared  buff/cache   available
Mem:            3794        2502         233         700        1057         460
Swap:          38145        2610       35535
rrr@raspberrypi:/tmp/yt $ uptime
 00:58:47 up 11 days, 13:51,  7 users,  load average: 1,20, 1,30, 1,66
rrr@raspberrypi:/tmp/yt $

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

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

commit

Которое ссылается на zen-kernel/issues, где предложили, как вариант, временно отключить ZSWAP, но у тамошнего ТС не хватило времени на проверку, но все всё равно решили убрать из ядра дефолтное включение zswap`а.

Да уж, не разобравшись толком, сразу резать. Причем, там вроде как раздался тихий голос "Кто-нибудь обращался к сопровождающим ядра zswap по поводу такого поведения? ", но ‘деструктивный’ процесс уже было не остановить.

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

На самом деле неплохое решение. zram/zswap нормально работают только когда пользователь сам их настраиват адекватно своему железу и задачам. В автомате могут получиться тупые косяки.

Не, условно-хороший дефолт это например zswap+zsmalloc на 10% памяти, но тут надо убедиться что zswap с ним не конкурирует, а физический своп подключен...

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

zsmalloc

Нет пределу совершенства, и на подходе zblock, который еще лучше:

Zblock также превосходит Zsmalloc по средней производительности и наихудшему времени выполнения. В документации отмечается, что тестирование Zblock на Raspberry Pi 5 дает примерно на 5-10% больше bogo ops/s по сравнению с Zsmalloc.

Так что, если все пойдет хорошо, Zblock может быть представлен как часть нового материала MM для предстоящего цикла Linux 6.16.
phoronix

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

Нет пределу совершенства

Еще не заржавела машина новых фич. :) Заявлен новый механизм Kcompressd в помощь к kswapd:

Вчера в список рассылки ядра Linux был отправлен патч «MM» для управления памятью для ядра Linux, предлагающий Kcompressd

мы обнаружили, что применение этого механизма в сценариях с высокой нагрузкой на память может увеличить скорость pgsteal_anon в секунду более чем на 260% по сравнению с ситуацией только с kswapd. Кроме того, мы отметили сокращение более чем на 50% случаев остановки выделения страниц, что еще раз демонстрирует эффективность kcompressd в снижении нагрузки на память и повышении быстродействия системы.
phoronix

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

Это всё ещё было лучше винды на порядок.

Кстати, с момента проектирования подсистемы свопа системы могли подрасти. Уже отмечали что свопинг хорошо работает когда оперативки всего пара гигов, но плохо если десятки гигабайт и свопить надо сопоставимо.

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

Еще не заржавела машина новых фич.

И вновь продолжается бой. )

После недавних обсуждений разработчиками ядра Linux по поводу интеграции функций кэша подкачки и карт подкачки с распределителем подкачки родилась Swap Table.
С Swap Tables можно надеяться на меньшее использование памяти, более высокую производительность, динамическое распределение и рост подкачки, большую расширяемость и другие улучшения по сравнению с существующим кодом подкачки в ядре Linux.

«С этой серией подсистема подкачки получит прирост производительности ~ 20-30% по сравнению с базовой последовательной подкачкой при больших нагрузках, как для фолиантов 4K, так и для mTHP. Использование незанятой памяти уже намного ниже, среднее потребление памяти осталось прежним или будет еще ниже (при дальнейших работах). И это позволяет значительно улучшить будущие оптимизации с более четкими операциями подкачки.»
phoronix



Что удивительно, ЛОРовцы, в большинстве своем, на все вопросы с нехваткой памяти - «Купи память!11».
Профи же, бьются над сокращением узких мест свопа, понимая, наверно, что обьем памяти, сколько бы ее ни было, все же величина конечная.

krasnh ★★★★★
()
2 декабря 2025 г.
Ответ на: комментарий от krasnh

Swap Tables

Добавили уже в ядро 6.18 (опеннет).

Реализован механизм «Swap Table», позволяющий повысить производительность подкачки. Ускорение достигается благодаря уменьшению конкуренции за доступ к кэшу подкачки, более эффективного поиска в кэше и снижения фрагментации.

Бэкенд на базе Swap Table задействован для кэширования подкачки вместо бэкенда XArray и позволил в среднем на 5-20% повысить производительность. В тесте usemem пропускная способность возросла на 17-28%, в тесте на многопоточную пересборку ядра время сборки уменьшилось на 1.12-3.19%, тест redis-benchmark с BGSAVE показал увеличение числа обрабатываемых запросов на 6-7%.



Еще:

Подсистема Zswap переведена на прямое использование системы выделения памяти zsmalloc вместо слоя zpool, который больше нигде не используется и теперь удалён из ядра.


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

Функция сжатия, когда она включена, заставляет zswap сжимать пул, удаляя холодные страницы для подкачки при высоком давлении в памяти.

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

Да, кстати, тестировал 6.12 на zsmalloc/zbud/z3fold, оказалось zsmalloc объективно более оптимальный и быстрый. Хотя z3fold немного дольше откладывал наступление свопинга, но вот потом тормозил более явно.

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

Не «пакетом по», а именно «подряд». 64 страницы подряд при запросе одной единственной. И да, при чтении из свапа подряд записанных страниц (из рамы или диска — не важно). Вот тебе и мерещится большая отзывчивость. Тянешь из свапа сразу по многу. На запись в свап эта крутилка вообще не влияет. По этому и рекомендуют при zram/zswap ставить в 0 (1 страница) и не тянуть лишнего (всё равно с рамы достать быстро не дёргая IO), а при работе с диска 3 (8 страниц). Вполне адекватное значение, но поспорить можно. При NVMe даже без zram/zswap 1 страницы вполне достаточно. При sata SSD тягать по 8 страниц вроде норм. При HDD и большом объёме памяти может и имеет смысл тянуть за раз больше страниц, но всё равно сомнительно. Только всё равно надо учитывать, что «попадания» в нужные страницы будут далеко не всегда, ибо доставание «подряд записанных в свап страниц». Далеко не факт что эти страницы вообще принадлежат одному приложению, которое «ту одну ему нужную» страницу попросило.

Но хозяин — барин. Хочешь тягать по 256 страниц за раз? Да флаг в руки.

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

Вот тебе и мерещится большая отзывчивость

Она не мерещится, она подтверждена тестами.

из свапа подряд записанных страниц (из рамы или диска — не важно)

На данный момент действительно так. Когда я читал док к ядру в прошлый раз около полугода-года назад - слов «последовательно» и «чтения» я там не помню. Вроде бы речь шла о всех операциях свопинга и без указания «последовательности», а это полностью мееняет весь смысл. И точно могу сказать, символ ¶ в форматировании странцы не использовался - это добавляет моей уверенности что док обновлён а не я слепой. Это не значит что переменная работала по-другому, вероятно они просто устранили неоднозначность в документации.

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

И ещё: вот эта моя заметка написана для ядер, на которых переменная ещё не была логарифмической! Как и в случае с swappines - её смысл мог измениться 2-3 раза за это время. Мои тесты показывали, что минимум фризов при свопинге возникает в диапазоне от 16 до 128 страниц, оптимально 32, а 64 я выбрал из неправильного понимания работы в качестве кеша записи.

Но хозяин — барин. Хочешь тягать по 256 страниц за раз?

А что не так? Это же целых 0,02% от огромного объёма в 4гб оперативной памяти! И примерно 0,025мс для сата-ССД.

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

А что не так? Это же целых 0,02% от огромного объёма в 4гб оперативной памяти!

256 страниц = 256 × 4096 ÷ 1024 = 1гб.
Если на АРМе считается по другому, то сори.
64 страницы = 256мб.
0,02% чего, простите?

Есть мнение, что для АРМа вообще по другому ядра допиливают и они мало похожи на x86. Но подтверждений этому я не нашел.

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

А нет объективного мерила фризов, особенно когда фризы от свопинга накладываются на говновеб в браузере с js-интерфейсом как фокс или вивальди.

Из самого объективного - задержки при пробуждении давно открытых и отсвопленых вкладок. Например откорываю 50 штук, а потом начинаю возвращаться, пролистывать, закрывать. И так весь пакет на секундомер. Но секундомер это не латентность, этообщая скорость поднятия из свопа. А фризы только на глаз.

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

256 страниц = 256 × 4096 = 1048576 байт = 1,000 Мбайт. Везде так ситается, а большими страницами можно и пренебречь - их немного.

4 Гб / 1 Мб = 0,0244%, извините округлил не очень хорошо. Но это копейки! Когда 30 лет назад свопилась 1 страница из 16-32М это было примерно сопоставимо.

Есть мнение, что для АРМа вообще по другому ядра допиливают и они мало похожи на x86. Но подтверждений этому я не нашел.

Чем дальше - тем они больше похожи друг на друга. Да там разницы то в паре-трйке нюансов и непонятно, то ли более агресивном, то ли уже нет, выравнивании переменных в памяти. Например софт под armhf/arm6l/arm7l занимает в 2-3 раза меньше памяти, а арм64 столько же сколько амд64.

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