Как работает команда top в Linux
Что проверяют
Умеете ли вы по top понять, что происходит с сервером, а не только знаете названия колонок. Следом обычно дают ситуацию: сервис на Python тормозит, load average 12, что смотреть дальше.
Как отвечать
top из пакета procps-ng читает /proc (/proc/stat, /proc/meminfo, /proc/<pid>/stat) и перерисовывает экран раз в несколько секунд, интервал меняет ключ -d. Разберите шапку:
- load average: сглаженная длина очереди за 1, 5 и 15 минут. В Linux туда входят и процессы в состоянии
D, ждущие ввода-вывода, поэтому сравнивать её нужно с числом ядер, а не с процентами; - %Cpu(s):
usпользовательский код,syядро,waожидание ввода-вывода,stвремя, отнятое гипервизором. Высокийwaуказывает на диск, высокийstна соседей по виртуалке; - память: смотреть на
avail Mem, а не наfree. Кэш страниц занимает свободную память и отдаётся по требованию; - колонки процессов:
RESреально занятая физическая память,VIRTадресное пространство,Sсостояние (R,S,D,Z), а%CPUна многоядерной машине бывает больше 100.
Клавиши: 1 показывает ядра по отдельности, P и M сортируют по CPU и памяти, H переключает на потоки, c показывает полную команду, k отправляет сигнал. Для скриптов есть пакетный режим top -b -n 1, для одного процесса top -p PID.
Python-специфика: процесс с чистым Python-кодом в стандартной сборке CPython упирается примерно в 100% одного ядра из-за GIL, сколько бы потоков в нём ни было. Постоянный рост RES у воркера gunicorn или celery намекает на утечку. Чтобы понять, какая функция ест CPU, после top запускают py-spy top --pid PID, а те же метрики из кода даёт psutil.
Где спотыкаются
Пугаются маленького free и говорят «кончилась память». Пока велик avail Mem, это нормальная работа кэша.
Трактуют load average как загрузку процессора. Высокая нагрузка при простаивающем CPU и большом wa означает проблему с вводом-выводом.
Смотрят top внутри контейнера и делают выводы о лимитах. Там видны память и ядра хоста, а ограничения cgroup показывает docker stats или файлы в /sys/fs/cgroup.