Назад | Перейти на главную страницу

Использование плиты слишком велико?

На сервере 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 файл для наиболее опасного объектного файла, сокета и часто библиотеки.