У меня проблема с серверами Debian. Мы запускаем 4 разных сервера, каждый из которых имеет процессоры Intel и 128 ГБ оперативной памяти. Двое из них управляют Уизи, двое - Джесси. Мы запускаем программное обеспечение Java в тех системах, которые сильно используют память и могут съесть всю память.
Для этих случаев я установил раздел подкачки на каждом сервере, который хранится в RAID 1, работающем на 2 SSD.
Проблема с системами Jessie: когда системе почти не хватает памяти, она начинает подкачку. Это настраивается параметром vm.swappiness = 10, и мне кажется, что это нормально. Но сама своппинг выполняется так сильно, что система полностью зависает / зависает. Сделано столько disk io, что система больше не отвечает.
Я провел несколько тестов на всех системах и искусственно заполнил оперативную память до 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 (29.02.2016) x86_64 GNU / Linux
Кто-нибудь сталкивался с такой же проблемой и нашел решение?
Редактировать: Спасибо всем за комментарии и пояснения. Конечно, я не хочу использовать подкачку как резервную память. Использование 120% было просто тестом. В производственной среде системы используют примерно 100 0001% памяти и уже перестают реагировать. В производственном режиме с запущенным нашим программным обеспечением также происходит очень высокая частота изменения данных, поэтому система может быть занята постоянным обменом очень небольшого количества данных туда и обратно.
Вы можете рассмотреть три варианта:
1) Настройте использование памяти вашим приложением, чтобы оно не превышало доступную память в системе, и полностью отключите подкачку. Я настраиваю системы со свопом только в очень необычных обстоятельствах. Если на вашем сервере более одного узла NUMA, просмотрите конфигурацию самого большого потребителя памяти и найдите параметры, связанные с NUMA. Если их нет, используйте numactl, чтобы установить память процесса для чередования узлов. Google для "безумия подкачки mysql" для получения более подробной информации о том, почему NUMA может вызывать необычные условия подкачки и OOM, даже когда доступно много памяти.
2) Установите swappiness = 100. Это заставит ядро выгружать страницы при первых признаках давления. Это может привести к тому, что замена будет происходить чаще, но с меньшими приращениями, и, таким образом, помешать работе системы надолго.
3) Настройте своп на zram со сжатием lz4. Это намного быстрее, чем замена на вращающуюся ржавчину или даже на SATA SSD (хотя, возможно, медленнее, чем современные NVMe). Убедитесь, что вы настроили размер zram меньше объема доступной памяти после вычета всей памяти, зарезервированной для огромных страниц. Например, если у вас 128 ГБ ОЗУ и зарезервировано 64 ГБ огромных страниц, настройте zram, скажем, на 60 ГБ. Он динамически выделяется и освобождается, а страницы с нулевым заполнением (вы удивитесь, сколько из них находится в рабочей памяти) полностью отбрасываются.
Мы по-прежнему сталкиваемся с этой проблемой с нашими Java-приложениями даже на серверах с текущими выпусками ОС Debian Buster.
Что мы сделали, чтобы этого не допустить: добавили в конец
/etc/sysctl.conf
параметр конфигурации
vm.swappiness = 0
Пока система действительно не нуждается в этом, своп не используется. Кроме того, мы обязательно настроили наше приложение Java на использование только макс. объем памяти.