воскресенье, 1 мая 2016 г.

Не слишком верьте UNIX Top

Я достаточно часто замечаю, как многие системные администраторы используют лишь одну, весьма древнюю и очень давно не обновляющуюся утилиту для мониторинга производительности и принятия всевозможных решений на эту тему.

Да, я говорю о UNIX top.

Хочу заметить следующее.

  1. Она написана во времена, когда компания DEC еще была жива. Т.е. во времена Она.
  2. Кроме беты 1 версии 3.8, которой самой сто лет в обед и которая знаменита непрерывно текущей памятью и постоянными дампами, единственной стабильной версией является 3.7 - еще более старая и не имеющая ни малейшего понятия о современных ядрах.
  3. Эта утилита брешет как Лев Троцкий на третьем партийном съезде и вводит в заблуждение тех, кто ей слепо доверят.

Я поделюсь своими долговременными наблюдениями за показаниями top 3.7 и мы сравним ее показания с другими утилитами, а также сделаем соответствующие выводы.

Итак, смотрите сюда:



Что вы видите? На первый взгляд, система кажется не загруженной. Однако что-то не так.

Смотрите внимательней.

Да, free swap меньше, чем total swap.

То есть - вероятно, происходит свопинг, не так ли?

Скажу больше. Такая же картина и в момент пиковой дневной загрузки, что приводит нас к мысли, что какой-то процесс однозначно расходует оперативную память и свопится. 

Однако давайте не будем принимать на веру показания top и выполним перекрестную проверку средствами других, штатных для системы, утилит:


Что мы видим в первую очередь? Мы не видим высокой дисковой активности, верно?

Наш своп находится на одном из системных дисков, следовательно, мы бы видели эту активность, если бы она имела место, хотя и косвенно, в общем потоке IO операций.

Хорошо, посмотрим теперь на общую картину утилитой vmstat:


Что мы видим здесь? Дисковая активность действительно имеется и показатели примерно соотносятся с тем, что показывает iostat, однако активность свопинга и пейджинга равна нулю (столбцы si, so - swap in и swap out, и pi,po - page in и page out соответственно).

То есть в действительности никакого свопинга и даже пейджинга в системе не наблюдается в принципе, хотя, если вернуться к показаниям top, видно, что свободной памяти в системе совсем немного.

Как, в таком случае, следует понимать показания top в начале статьи?

  1. Необходимо помнить о том, что механизмы свопинга различным образом реализованы в различных ядрах. Эти механизмы сильно завязаны на подсистему планировщика заданий (scheduler) и подсистему аллокатора памяти ядра OS.
  2. top зачастую не содержит специфических знаний об особенностях реализации данных механизмов и показывает страницы, которые распределены в области подкачки, но ничего не сообщает о том, как они используются и используются ли вообще.
  3. Таким образом, top не может и не показывает реальной картины, есть ли в данный момент свопинг в системе или нет, если не смотреть на другие объективные показатели - например, на время ядра (kernel time), количество процессов на процессорах, реальные задержки отклика процессов и т.п. Причем даже и в этом случае картина может быть необъективной без контрольных проверок другими инструментами.
Возвращаясь к первоначальному примеру.

Данный пример взят с системы, которая предварительно резервирует пространство в области свопинга, чтобы при необходимости без задержек начать вытеснение страниц, но при этом фактически свопинг не выполняет вплоть до момента, когда оперативная память начнет реально исчерпываться.

Может показаться, что этот момент не за горами, так как свободной памяти в системе, согласно показаниям top, совсем немного.

Однако, следует иметь в виду (и это опять-таки специфика систем, причем их большинства), что часть памяти, которая показывается как занятая, причем значительная часть, в действительности занята кэшами файловых систем, и, в большинстве случаев, ядро освобождает такую память после синхронизации кэшей на диски по первому требованию процессов. Механизмы выделения страниц в действительности несколько более сложные, однако в общих чертах происходящие процессы именно таковы.

То есть до начала реального свопинга в действительности весьма и весьма далеко.


Более того, при отсутствии реальных утечек памяти мне приходилось наблюдать картину, как система, всего лишь с десятком мегабайт свободной оперативной памяти, месяцами находится в стабильном состоянии, не начиная свопинга вовсе.

Да, может начаться процесс пейджинга как результат, в частности, фрагментации оперативной памяти в процессе работы, увеличивающий kernel time и уменьшающий время отклика системы (впрочем, не очень значительно), однако это совсем другая история, впрямую со свопингом зачастую не связанная и не обязательно приводящая к свопингу в конечном итоге.