Проблема такая
На машине CentOS с ядром 2.6.32 и 128 ГБ физической оперативной памяти несколько дней назад возникли проблемы. Ответственный системный администратор сказал мне, что приложение PHP-FPM перестало своевременно отвечать на запросы из-за свопинга, и, увидев, что свободной памяти почти не осталось, он решил перезагрузить машину. Я знаю, что свободная память может быть перегруженной концепцией в Linux и перезагрузка, возможно, была неправильным решением. Однако упомянутый администратор винит во всем приложение PHP (за которое отвечаю я) и отказывается от дальнейшего расследования.
Перед перезагрузкой свободная память (включая буферы и кэш) составляла всего пару сотен МБ.
Перед перезагрузкой /proc/meminfo сообщил, что Slab использует около 90 ГБ памяти (да, ГБ).
После перезагрузки свободная память составляла 119 ГБ, снизившись примерно до 100 ГБ в течение часа, поскольку рабочие процессы PHP-FPM (их около 600) «просыпались», каждый из них показывал от 30 до 40 МБ в колонке RES сверху (так было в течение нескольких месяцев, что вполне разумно, учитывая характер PHP-приложения). Больше в списке процессов нет ничего, что потребляло бы необычное или заслуживающее внимания количество оперативной памяти. После перезапуска память Slab составляла около 300 МБ.
С тех пор мы наблюдали за системой, и наиболее заметно, что память Slab растет по прямой со скоростью около 5 ГБ в день. В настоящее время объем памяти Slab составляет 46 ГБ. В чем проблема?
Ответ 1
Правильно ли я думаю, что память Slab всегда является физической RAM, а число уже вычитается из значения MemFree?
Является ли такое большое количество записей вставок нормальным? Приложение PHP имеет доступ к примерно 1,5 М файлам, однако большинство из них являются архивами и не используются для обычного веб-трафика.
Чем можно объяснить тот факт, что количество кэшированных узлов намного меньше, чем количество кэшированных вставок, не должны ли они быть как-то связаны?
Если система испытывает проблемы с памятью, не должно ли ядро автоматически освобождать часть вставок? Что может быть причиной того, что этого не происходит?
Есть ли способ «заглянуть» в кэш вставок, чтобы увидеть, что это за память (т. е. какие пути кэшируются)? Возможно, это указывает на какую-то утечку памяти, петлю симлинка или на то, что PHP-приложение делает что-то не так.
Код приложения PHP, а также все файлы активов монтируются через сетевую файловую систему GlusterFS, может ли это быть как-то связано с этим?
Имейте в виду, что я не могу проводить исследование как root, только как обычный пользователь, и что администратор не сможет помочь. Он даже не хочет выполнять типичный тест echo 2 > /proc/sys/vm/drop_caches, чтобы убедиться, что память Slab действительно может быть восстановлена.
Ответ 2
Подтвержденное решение
Всем, кто может столкнуться с той же проблемой. Сегодня ребята из центра обработки данных наконец-то разобрались с этим. Виновником была библиотека NSS (Network Security Services), связанная с Libcurl. Обновление до последней версии решило проблему.
Отчет об ошибке с подробным описанием находится здесь:
https://bugzilla.redhat.com/show_bug.cgi?format=multiple&id=1044666
Очевидно, чтобы определить, является ли какой-то путь локальным или он находится на сетевом диске, NSS искал несуществующий файл и измерял время, которое требуется файловой системе, чтобы отчитаться о проделанной работе! Если у вас достаточно большое количество запросов Curl и достаточно памяти, все эти запросы кэшируются и складываются.
Дополнительно:
См. Https://www.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.7/2.6.7-mm1/broken-out/vfs-shrinkage-tuning.patch
Есть числа, показывающие, что вы можете ожидать некоторого заметного восстановления памяти dentry, когда vfs_cache_pressure установлен намного выше 100. Таким образом, 125 может быть слишком низким, чтобы это произошло в вашем случае.
Ответ 3
Я столкнулся с точно такой же ситуацией. Эта проблема влияет на SSL-запросы, выполняемые с помощью curl или libcurl, или любого другого программного обеспечения, которое использует mozilla NSS для безопасного соединения. Небезопасные запросы не вызывают проблему. Проблема не требует одновременного выполнения запросов curl. Накопление вставок будет происходить до тех пор, пока вызовы curl будут достаточно частыми, чтобы опережать усилия ОС по освобождению оперативной памяти. Новая версия NSS включает исправление этой проблемы, однако вы не получите это исправление бесплатно, вам нужно обновить только nss-softokn (который имеет необходимую зависимость от nss-utils), как минимум. И чтобы получить преимущество, вам нужно установить переменную окружения NSS_SDB_USE_CACHE для процесса, использующего libcurl. Наличие этой переменной окружения позволяет пропустить дорогостоящие проверки несуществующих файлов.
Web
