Какие команды Linux использовать для мониторинга процессора и памяти на сервере с Java приложениями

Что проверяют

Умеете ли вы пройти путь от «сервер тормозит» до конкретного потока или области памяти в JVM. Следом почти всегда спрашивают, почему процесс Java занимает больше памяти, чем задано в -Xmx.

Как отвечать

Идите от системы к процессу и дальше внутрь JVM:

• top и htop: общая картина, load average, %CPU и RES процесса. top -H -p PID показывает отдельные потоки, номер самого горячего переводите в шестнадцатеричный вид и ищете в дампе потоков по полю nid;
• vmstat 1: очередь готовых к запуску процессов (r), активность свопа (si, so), ожидание ввода-вывода (wa) и время, украденное гипервизором (st);
• free -h: смотрите колонку available, а не free, страничный кеш ядро отдаёт по требованию;
• pidstat -p PID 1 из пакета sysstat: CPU процесса во времени, с -t по потокам, с -r по памяти;
• dmesg или journalctl -k: следы OOM killer, если процесс исчез без стектрейса.

Дальше инструменты JDK: jstat -gcutil PID 1000 и jcmd PID GC.heap_info для заполнения поколений и частоты сборок, jcmd PID Thread.print для дампа потоков, jcmd PID GC.heap_dump /tmp/heap.hprof при подозрении на утечку.

Про память вне кучи: RSS процесса включает Metaspace, стеки потоков, кеш JIT-кода и direct-буферы. Разложить её по областям помогает запуск с -XX:NativeMemoryTracking=summary и команда jcmd PID VM.native_memory summary.

Где спотыкаются

Называют htop графической программой и приводят iostat как команду для памяти. htop работает в терминале, а iostat показывает диски и ввод-вывод.

Сравнивают RES из top с -Xmx и делают вывод об утечке в куче. Разница обычно в нативной памяти, и увеличение -Xmx здесь только усугубит ситуацию.

Смотрят free внутри контейнера и видят память всего хоста. Реальный лимит задаёт cgroup, JVM его учитывает, и размер кучи там разумнее задавать через -XX:MaxRAMPercentage с запасом под нативную память, а не фиксированным -Xmx впритык к лимиту.