Как мы узнаем, что вызывает высокое использование кеша на нашем сервере?
Каждую пятницу примерно с 22:00 наш сервер начинает использовать большие объемы кеша, а примерно через два часа умирает. Пожалуйста, посмотрите на следующий график Cacti.
Мы пробовали искать процессы, которые используют большой объем памяти, с https://raw.githubusercontent.com/pixelb/ps_mem/master/ps_mem.py но все, что он показывает, это следующее.
...
438.0 MiB + 1.1 MiB = 439.1 MiB XXXEngine XXX 961f4dbc-3b01-0000-0080-ff115176831d xxx
520.2 MiB + 1.7 MiB = 521.9 MiB XXXEngine XXX f2ac330c-3a01-0000-0080-a2adb5561889 xxx
10.4 GiB + 829.0 KiB = 10.4 GiB java -server -Xms1G -Xmx5G -Djava.net.preferIPv4Stack=true -cp ../lib/hazelcast-3.2.2.jar:../lib/xxx.cache.jar com.hazelcast.examples.StartServer (2)
---------------------------------
28.1 GiB
=================================
Это совсем не похоже на 100 ГБ кеш-памяти, и мы думали, что Linux может использовать такой объем памяти для кеширования дискового ввода-вывода, поэтому мы использовали atop измерить это. Это то, что мы получаем, когда бежим atop -r atop-20140919-230002-062979000.bin -d -D (-c).
PID TID RDDSK WRDSK WCANCL DSK CMD 1/405
1 - 907.9G 17.0T 2.8T 97% init
6513 - 175.1G 46.1G 5.9G 1% crond
8842 - 8K 110.3G 128K 1% xxxzmuc0
6296 - 6.5G 25.1G 15.9G 0% sshd
4463 - 4668K 23.2G 0K 0% kjournald
19681 - 1835K 22.5G 22.4G 0% xxxtroker
4469 - 4728K 15.2G 0K 0% kjournald
4475 - 4716K 14.9G 0K 0% kjournald
2401 - 588K 11.4G 0K 0% kjournald
8652 - 7.0G 2.6G 1.3G 0% k6gagent
26093 - 9.5G 0K 0K 0% bpbkar
...
И atop с опцией -c.
PID TID S DSK COMMAND-LINE (horizontal scroll with <- and -> keys) 1/405
1 - S 97% init [3]
6513 - S 1% crond
8842 - S 1% xxzmuc0 -m XXX
6296 - S 0% /usr/sbin/sshd
4463 - S 0% kjournald
19681 - S 0% xxxtroker XXX
4469 - S 0% kjournald
4475 - S 0% kjournald
2401 - S 0% kjournald
8652 - S 0% /opt/IBM/ITM/lx8266/6g/bin/k6gagent
26093 - S 0% bpbkar -r 2678400 -ru root -dt 0 -to 0 -clnt ...
...
Итак, я вижу, что init записал на диск 17 терабайт данных, что кажется много. Однако я понятия не имею, как выяснить, что вызывает это. Я придерживался мнения, что Linux использует кеш для ускорения дисковых операций, но возвращает его, когда он нужен процессам, и что невозможно убить сервер с помощью кеша.
Мы находимся на «Red Hat Enterprise Linux Server версии 5.5 (Tikanga)» Linux delirium 2.6.18-194.26.1.el5 # 1 SMP Пт 29 октября 14:21:16 EDT 2010 x86_64 x86_64 x86_64 GNU / Linux.
Что нам делать (дальше), чтобы выяснить, что не так?
Ознакомьтесь с утилитой slabtop. Также удостоверились ли вы, что на этот период времени в вашей системе не запланировано выполнение задания cron с интенсивным вводом-выводом (например, mlocate / updatedb ..)?
slabtop --sort=c
Я вижу, что bpbkar также активен, я бы посмотрел на этот процесс. Это часть Symantec NetBackup, проверьте, есть ли у вас резервная копия, работающая на момент возникновения проблем. Отключите его и посмотрите, не возникнет ли проблема снова, если резервное копирование не запланировано.
Если виноват процесс bpbkar, вам следует включить полный вход в систему, чтобы выяснить, где он вызывает эту проблему. Обязательно установите для него самые свежие обновления, так как они всегда решают большой список проблем.