Система подкачки блоков Linux (заморозить)
У меня проблема с моими серверами Debian. Мы используем 4 разных сервера с процессорами Intel и 128 ГБ оперативной памяти. Двое из них управляют Уизи, двое из них управляют Джесси. На тех системах мы запускаем программное обеспечение Java, которое интенсивно использует память и может поглотить всю память.
Для этих случаев я установил раздел подкачки на каждом сервере, который находится на RAID 1, работающем на 2 SSD.
Проблема с системами Jessie: когда системе почти не хватает памяти, она начинает меняться. Это настраивается параметром vm.swappiness = 10 и выглядит нормально для меня. Но сам обмен выполняется так сильно, что система полностью зависает / зависает. Выполнено столько дисков, что система больше не отвечает.
Я провел несколько тестов на всех системах, искусственно заполнив оперативную память до 120%, используя:
stress --vm-bytes $(awk '/MemFree/{printf "%d\n", $2 * 1.2;}' < /proc/meminfo)k --vm-keep -m 1
Система начинает подкачку и зависает, пока идет подкачка 20%. После ~20-х годов система вернулась и снова стала использоваться, но во время остановки больше ничего не работает.
Конечно, такое поведение неприемлемо для продуктивной системы. Я ожидаю, что обмен имеет высокий приоритет, но никогда не должен использовать более 90% всех системных ресурсов, так что система все равно может быть обработана.
Настройка перестановки на разные значения не помогла..
Мы используем следующие ядра:
Wheezy: Linux A 3.2.0-4-amd64 # 1 SMP Debian 3.2.68-1 + deb7u1 x86_64 GNU / Linux
Джесси: Linux B 3.16.0-4-amd64 #1 SMP Debian 3.16.7-ckt20-1+deb8u4 (2016-02-29) x86_64 GNU/Linux
Кто-нибудь сталкивался с такой же проблемой и нашел решение?
Изменить: Спасибо всем за комментарии и объяснения. Конечно, я не хочу использовать своп как запасную память. Использование 120% было просто тестом. В производстве системы используют, возможно, 100,0001% памяти и уже перестают отвечать на запросы. В производственном режиме с запущенным нашим программным обеспечением также существует высокая частота изменения данных, так что система может быть занята, просто обмениваясь очень маленьким объемом данных все время назад и вперед.
0 ответов
Мы по-прежнему сталкиваемся с этой проблемой с нашими Java-приложениями даже на серверах с текущими выпусками ОС Debian Buster.
Что мы сделали, чтобы этого не допустить: добавили в конец
/etc/sysctl.conf
параметр конфигурации
vm.swappiness = 0
Пока система действительно не нуждается в этом, своп не используется. Кроме того, мы обязательно настроили наше приложение Java на использование только макс. объем памяти.
Вы можете рассмотреть три варианта:
1) Настройте использование памяти вашим приложением, чтобы оно не превышало доступную память в системе, и полностью отключите подкачку. Я настраиваю системы со свопом только в очень необычных обстоятельствах. Если на вашем сервере более одного узла NUMA, просмотрите конфигурацию самого большого потребителя памяти и найдите параметры, связанные с NUMA. Если их нет, используйте numactl, чтобы установить память процесса для чередования узлов. Google для "безумия подкачки mysql" для получения более подробной информации о том, почему NUMA может вызывать необычные условия подкачки и OOM, даже когда доступно много памяти.
2) Установите swappiness=100. Это заставит ядро выгружать страницы при первых признаках давления. Это может привести к тому, что замена будет происходить чаще, но с меньшими приращениями, и, таким образом, помешать работе системы на долгое время.
3) Настройте своп на zram со сжатием lz4. Это намного быстрее, чем замена на вращающуюся ржавчину или даже на SATA SSD (хотя, возможно, медленнее, чем современные NVMe). Убедитесь, что вы настроили размер zram меньше объема доступной памяти после вычета всей памяти, зарезервированной для огромных страниц. Например, если у вас 128 ГБ ОЗУ и зарезервировано 64 ГБ огромных страниц, настройте zram, скажем, на 60 ГБ. Он динамически выделяется и освобождается, а страницы с нулевым заполнением (вы удивитесь, сколько из них находится в рабочей памяти) полностью отбрасываются.