На сервере Centos 7 с оперативной памятью 32 ГБ я запускаю несколько программ, а именно MySQL, Apache2, PHP. Недавно я хотел проверить количество оставшейся оперативной памяти, так как я планировал установить еще несколько программ, но, к моему удивлению, объем памяти был очень низким! После расследования я обнаружил, что Slab использует более 20 ГБ. 2 дня назад я сбросил кеш, поэтому использование slab упало до 0 и снова медленно увеличилось. Во время мониторинга с помощью программы я заметил, что использование растет линейно. За последние 24 часа он увеличился до ~ 5200 МБ (общее увеличение на 13 ГБ за 60 часов). Общий объем данных на диске не превышает 40 ГБ. Результат «find /» составляет всего несколько МБ. Вроде как-то много дентри кешируется?
У меня есть сообщения, в которых говорится, что причиной была NSS, которая пришла с завитком. Я проверил, какая версия NSS установлена, и к этой версии должно быть применено исправление.
Я также нашел сообщения, предлагающие использовать vfs_cache_pressure, однако его увеличение, похоже, не останавливает рост использования до чрезвычайно высоких значений.
Я хотел бы знать, каков нормальный объем памяти идентификаторов для небольшого диска <50 ГБ? А как найти источник и как это исправить?
Связанные изображения:
Скриншот slabtop: Вот
График восстанавливаемой и кешированной памяти плиты: Вот
Редактировать:
# sysctl -n vm.vfs_cache_pressure
10000
(Раньше было 100, я увеличил его на x100, но память все равно увеличивается на ту же величину)
# find / -type d -size +10M -ls
#
(нет вывода)
Что касается cronjobs, помимо ежедневной ротации логов существует один скрипт, который устанавливает несколько TCP-соединений для получения данных и сохраняет их в базе данных (сырые сокеты, без curl или что-то еще). Помимо этого cronjob есть 2 резервных cronjobs, которые запускаются раз в неделю. Единственное, что должно вызывать ввод-вывод, - это веб-сервер apache2 с установленным SMF. Лично я подозреваю, что это может быть проверка mod_rewrite на наличие файлов или что-то в этом роде.
Полная версия ядра:
Linux #1 SMP Tue Mar 18 14:48:24 CET 2014 x86_64 x86_64 x86_64 GNU/Linux
Установленное ПО: пастебин
Выход ps aux: пастебин
# strace -fc -e trace=access curl 'https://www.google.com' > /dev/null
Process 7342 attached
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 259 100 259 0 0 903 0 --:--:-- --:--:-- --:--:-- 905
% time seconds usecs/call calls errors syscall
------ ----------- ----------- --------- --------- ----------------
100.00 0.000048 0 7877 7872 access
------ ----------- ----------- --------- --------- ----------------
100.00 0.000048 7877 7872 total
Я всегда использую top
искать самые большие процессы VSIZE / VSS или RSS,
Затем я перехожу в подкаталог /proc/<.PID>/.
И изучите smaps
файл для наиболее опасного объектного файла, сокета и часто библиотеки.