Комментарии 36
Ну или на серверах с бд.
Для серверов БД (например для Оракла) редхат в руководстве по настройке рекомендует swapiness выставлять в 1 для RHEL 7
Не так давно у знакомых пролетал SSD, который из-за свопа за полтора года загнулся…
Смотря как Вы смотрели свободную память. Вероятно это была доступная память, а не free.
В своп всегда можно выкинуть какой-то "мусор", который процессу вероятно не понадобится и использовать освободившееся место для полезного файлового кеша
Это значит, что ядро Linux начинает свопить редко используемые страницы оперативной памяти, когда использование свободной оперативной памяти достигает 100%-60%=40%.
Очень распространенное заблуждение. На самом деле vm.swappines делает следующее:
This control is used to define how aggressive the kernel will swap
memory pages. Higher values will increase aggressiveness, lower values
decrease the amount of swap. A value of 0 instructs the kernel not to
initiate swap until the amount of free and file-backed pages is less
than the high water mark in a zone.
(Из документации к ядру). Уже отсюда ясно, что никакого отношения к % свободной памяти эта настройка не имеет.
Чуть подробнее о работе этой опции рассказано на портале Red Hat:
A value from 0 to 100 which controls the degree to which the system favors anonymous memory or the page cache. A high value improves file-system performance, while aggressively swapping less active processes out of physical memory. A low value avoids swapping processes out of memory, which usually decreases latency, at the cost of I/O performance. The default value is 60.
То есть опция указывает приоритет дискового кэша перед данными приложений. Поэтому уменьшение этой опции увеличивает приоритет данных приложений, взамен ухудшается кэширование I/O.
Было бы очень полезно сделать такое, как минимум, для табов в хроме. А если это сделать в хроме по умолчанию на всех платформах, глядишь, фронтенд-сообщество начнёт думать, как расходовать память экономно.
www.hippolab.ru/linux-zswap-dayte-mashine-shans
Чтобы проверить включен ли zswap, нужно выполнить:
cat /sys/module/zswap/parameters/enabled
если результат будет Y, значит включен.
Чтобы проверить включен ли lz4 компрессор — выполнить:
dmesg | grep -i zswap
если результат — [ 0.715381] zswap: loaded using pool lz4/zbud (обратите внимание на цифру 4), то lz4 — включен.
У меня 8 ГБ ОЗУ, своп не используется. Иногда какой-то процесс отжирает всё ОЗУ, и система впадает в ступор минут на 20-30, непрерывно светя индикатором жёсткого диска. После этого этот процесс убивается, память освобождается и всё продолжает работать нормально. Но что происходит в эти 20-30 минут?
Но так как система у нас многозадачная, то при переключении процессов у нас постоянно происходит загрузка с диска кода и библиотек для текущего процесса и освобождение для этого памяти за счёт других процессов. И так — по кругу. В результате, то что могло выполниться за несколько секунд занимает много минут.
Через 20-30 минут жрущий память процесс убивается, его память освобождается и ядро наконец-то может однократно загрузить код библиотек и других процессов и больше его не выгружать. Работа системы нормализовалась.
Описание сильно упрощено, но суть такова.
Линукс очень плохо обрабатывал ситуации исчерпании памяти. Это пофиксили в 5 или 6 версии вроде. Судя по новостям.
В 2017 году я бы порекомендовал настроить более агрессивный оом киллер или типа того.
Ну, а причину Вам человек в общих чертах описал
Это называется Trashing, причина описана комментом выше: https://habr.com/ru/post/344836/#comment_10576482
Много лет пытаюсь лечить эту проблему друзьям, которым посоветовал Ubuntu вместо Win, и у которых обычно ноутбуки с малым количеством ОЗУ (2..8 Гб).
Все манипуляции с настройкой VM (vm.swappines и т.п.) а также включение ZRAM только оттягивают во времени приход пушистого зверька.
Недавно, удивительное дело, Trashing пропал, после того как установил на ноутбуке (8 Гб озу, Ubuntu, ядро 5.4) IO scheduler в none. ОЗУ кончается и занятая память плавно переливается в SWAP без зависания интерфейска, как у вас описанно, и как обычно случалось и у меня.
Видимо, проблема не только в исчерпании ОЗУ, но и в алгоритмах планирования операций ввода-вывода
при переключении процессов у нас постоянно происходит загрузка с диска кода и библиотек для текущего процесса и освобождение для этого памяти за счёт других процессов. И так — по кругу.
В моем ноутбуке стоит гибридный SSHD у которого по определению внутри сложный встроенный планировщик, который перемещает блоки с магнитного блина на микросхемы SSD. И включение самого тупого IO планировщика в Linux ядре, который просто отправляет запросы к диску, магическим образом спасает от хождения в SWAP по кругу. Я не знаю, как это сработало, только предполагаю.
Но я не надеюсь, что этот способ всем поможет, а в случае с HDD скорее навредит.
В будущем планирую поиграть с ZSWAP и user-space ООМК (out-of-memory-killer): https://github.com/rfjakob/earlyoom
sudo apt install earlyoom
Есть же systemd-swap в репах. С настройками под все возможные варианты.
Нехватка оперативной памяти в Linux на рабочем ПК: оптимизация и действия при зависании