Как мы узнаем то, что вызывает высокое использование кэша на нашем сервере?
Каждую пятницу около 22:00 наш сервер начинает использовать большой объем кэша и затем перестает работать приблизительно два часа спустя. Посмотрите на следующий график Кактусов.
Мы пытались искать процессы, которые используют большие объемы памяти с 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
=================================
Это - ничто близко к 100G кэша, и мы думали, что 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 выпуск 5.5 Сервера Linux (Tikanga)" бред Linux 2.6.18-194.26.1.el5 № 1 SMP пятница 29 октября 14:21:16 GNU/Linux EDT 2010 x86_64 x86_64 x86_64.
Что мы должны сделать (затем) для обнаружения что случилось?
Я вижу, что bpbkar также активен, я бы посмотрел на этот процесс. Это часть Symantec NetBackup, проверьте, есть ли у вас резервная копия, работающая на момент возникновения проблем. Отключите его и посмотрите, возникнет ли проблема снова, когда резервное копирование не запланировано.
Если виноват процесс bpbkar, вы должны включить полное ведение журнала, чтобы выяснить, где он вызывает эту проблему. Убедитесь, что для него установлены последние обновления, так как они всегда решают большой список проблем.
Ознакомьтесь с служебной программой slabtop. Также удостоверились ли вы, что это не запланированное в вашей системе задание cron с интенсивным вводом-выводом на этот период времени (например, mlocate / updatedb ..)?
slabtop --sort=c