From: Andrew Kornilov <frutik@gmail.com.>
Date: Mon, 12 Jun 2005 18:21:07 +0000 (UTC)
Subject: Анализ производительности системы в Linux
Оригинал: http://linux.te.ua/documents/LPA.html
Анализ производительности системы в Linux
(с) Flavio Villanustre
translated by Andrew Kornilov (frutik@gmail.com)
http://geminis.dyndns.org/wordpress/index.php/2005/06/05/performance-analysis-on-linux/
Анализ производительности системы и выявление <<узких мест>>
производительности в Linux не слишком сложный процесс. Он требует
некоторых базовых знаний о работе оборудования и архитектуре ядра, а
также использования некоторых стандартных инструментов. Используя
практический подход мы проведем читетля через различные подсистемы и
ключевые индикаторы, чтобы помочь выявить какой компонент является
текущим узким местом в системе.
Часто системный администратор знает, что система требует апгрейда, но
затрудняется определить почему или другими словами, какая именно часть
системы требует апгрейда. Во многих случаях ситуацию <<бутылочного
горлышка>> можна преодолеть более тонкой настройкой системы не
прибегая к аппаратному апгрейду вообще.
Во-первых, давайте рассмотрим некоторые базовые понятия:
С точки зрения анализа производительности, существует три основных
типа критических ресурсов: процессор (исполнение), память и ввод/вывод
(I/O).
Память делится на физическую и виртуальную (физическая плюс память из
области подкачки).
Ввод/вывод может быть разбит на две больших категории: дисковый I/O и
сетевой I/O.
В системах семейства Unix (как в почти в какждой системе с разделением
времени) процессы могут находиться в одном из двух возможных
состояний: исполнении (running) или ожидании (sleeping). Процессы
находящие в состоянии ожидания находятся в нем по одной из двух
причин: потому что они <<израсходовали>> все выделенное им
процессорное время в текущем цикле (то есть ядро переместило их в режим
ожидания до тех пор, пока другие запущенные процессы используют своё
процессорное время) или потому, что они блокированы (то есть они ожидают
выделения не доступных в данный момент ресурсов, таких как дисковый или
сетевой ввод/вывод, etc.). Если ожидающий (sleeping) процесс перемещён
из основной памяти в область подкачки (paged out), он может находиться
в третьем состоянии: "готов к исполнению но жду возврата в основную
память (ready to run but waiting to be paged in)".
Ядро постоянно поддерживает список всех запущеных процессов и помечает
их в зависимости от их текущего состояния. Если процесс помечен как
блокированный, он не может быть переведен в состояние исполнения до
тех пор, пока нужный ему ресурс не будет доступен. Если процесс помечен
как ожидающий по причине того, что он израсходовал свой процессорный
таймслот, он будет находиться в этом сосстоянии до тех пор, пока
другие исполняющиеся процессы используют своё процессорное время, потом
он будет переведён в режим исполнения планировщиком ядра с учётом
выделенного процессу приоритета.
Приоритет определяет то, сколько относительного процессорного времени
может быть выделено этому процессу. Приоритеты для определённых
процессов могут отличаться от стандартных значений и устанавливаться
пользователем отдельно.
Виртуальная память определяется как полное количество памяти в системе
и состоит из физической памяти (RAM) и памяти областей подкачки на
жестких дисках. Физическая память делится между четырьмя пулами:
свободная память (free memory), кеш (cache) (свободная память, которая
динамически назначается кешу файловой системы, и может быть выделена
повторно по мере необходимости), буфера ввода/вывода (I/O buffers) и
использованной памяти (памяти, выделеной запущенным в системе
процессам).
Менеджер виртуальной памяти ядра (Kernel Virtual Memory Manager) может
перемещать ожидающие процессы из физической памяти в область подкачки
при возникновении необходимости в свободной физической памяти (в
соответствии в текущими настройками в /proc/sys/vm/). Если страница
памяти, находящаяся в области подкачки, должна быть загружена для
исполнения, менеджер виртуальной памяти перемещает её обратно в
физическую память. В редких случаях, когда исчерпывается вся
виртуальная память, запускается особый механизм (the Out of Memory
Killer - OOM Killer). С помощью эвристических алгоритмов он
выбирает процесс, который будет уничтожен для того, чтобы освободить
для системы часть физической памяти.
Теперь приступим к рассмотрению инструментов, которые помогут нам
определить какие компоненты системы приводят к низкой
производительности нашей системы.
Наилучший инструмент для такого анализа - утилита vmstat. Vmstat,
будучи запущенным с некоторыми параметрами, показывает обобщённые с
момента запуска системы показатели и обновляет их через определённые
промежутки времени. Обычное представление этих показателей приведено
на рисунке:
Output from vmstat
В заголовке указывается какие имеенно показатели представлены:
* Procs: количество процессов в состоянии исполнения (r) и в
состоянии блокировки (b)
* Memory: количество использованной памяти в областях подкачки
(swpd), сободной памяти (free), использованной под буфера (buff) и
использованной под кеш файловой системы (cache)
* Swap: количество страниц помещённых в область подкачки (si -
swapped in) и извлечённых из неё (so - swapped out) в секунду
* IO: количество блоков, полученных от блокового устройства (bi) или
посланных блоковому устройству (bo), в секунду
* System: количество прерываний в секунду (in) и количество
переключений контекста в секунду (cs)
* CPU: процент полного процессорного времени, проведённого в user
space (us), kernel space (sy), idle (id) и в ожидании ввода/вывода
(wa)
Интерпретация этих значений не представляет особой сложности.
Рассмотрим реальные примеры.
Если в вашей системе постоянно большое количество в состоянии
исполнения (r), это обычно означает что вам необходимо или увеличить
количество процессоров или заменить процессор на более быстрый, так
как процессы постоянно ждут, пока освободится процессор. Важно не
забывать, что допустимая длина <<очереди>> ожидающих процессов
пропорциональна количеству процессоров в системе (то есть 5 или 6
ожидающих процессов в четырехпроцессорной системе эквивалентно
очереди из 1-2 процессов в однопроцессорной системе).
Если вы ищете, что требует оптимизации, взгляните на показатели
использования процессорного времени, они расскажут вам, какая подсистема
больше использует его - ядро или пользовательсике процессы (колонки sy
и us). Запуск утилиты top может подсказать вам главного кандидата на
оптимизацию.
В отдельных случаях, когда в системе есть больше одного процессора,
раздел CPU утилиты vmstat показывает усреднённые велечины, что может
быть не очень точным (если есть только один <<тяжелый>> процесс
исполняющийся в однопоточном режиме). Возможно использование команды
`mpstat -P ALL 5' для просмотра усредненной и раздельной статистики по
отдельным процессорам.
Рассмотрим другую ситацию, когда в вашей системе количество
используемой памяти в области подкачки большое, свободной и
используемой под кеш памяти - маленькое и наблюдается постоянная
активность по перемещению страниц из/в область подкачки. Всё это
указывает на то, что система испытывает недостаток памяти.
Дополнительная память - вот основная статья расходов в этом случае.
Третий типичный случай характеризируется тем, что в системе постоянно
большое количество процессов, находящихся в блокированном состоянии(b),
таймер ожиданий процессора (wa) имеет большие значения, и количество
операций ввода/вывода (bi/bo) постоянно имеет большое значение. Такие
показатели говорят о том, что операции ввода/вывода - узкое место
вашей системы, таким образом ни увеличение количества/частоты CPU или
объёма памяти скореее всего не помогут улучшить ситуацию. На
помощь придёт утилита, позволяющая определить какое блочное устройство
<<виновно>> в большом времени ожидания (и соответственно - кандидат на
замену более быстрым устройством или даже RAM диском): iostat. Iostat,
запущенный с параметром -x, показывает информацию в расширенном
формате, который включает в себя несколько полезных показателей:
iostat -x 5
Ключевые показатели:
%util - показывает какой процент времени процессора используется для
обслуживания запросов к устройству
await - время ожидания, среднее время, которое идёт на ожидание
выполнения запроса
svctm - время обслуживания, которое является временем, необходимым
устройству для обслуживания запросов
Высокое время ожидания, обслуживания и процент от использования указывают,
что устройство слишком медленно для текущей нагрузки.
Сеть - слудующий кандидат на звание <<бутылочного горлышка>>. Для
начала убедитесь, что настройки скорости и дуплексного режима верны
для вашей пары сетевой адаптер/свич (самая частая причина сетевых
ошибок). Далуее утилита netstat -ci позволит проследить количество
трафика в секунду через каждый сетевой интерфейс. Как и в vmstat и
iostat, первая строчка показывает обобщённые результаты, накопленные с
момента загрузки системы, следующие строчки показывают статистику
через каждую секунду:
netstat -ic
Впрочем настройка производительности сетевой подсистемы выходит за
пределы задач этой статьи.
Это руководство не претендует на полноту. Использование описанных
инструментов не позволяет с уверенностью дать ответ на вопросы
определения проблем производительности других подсистем или другими
словами оно не дает ответа на вопросы типа: Является ли <<узким
местом>> системная шина? Как мне узнать что улучшить в первую очередь -
прецессор или видеоадаптер? Не слишком ли медлителен этот тип памяти
для моего центрального процессора?
В любом случае, я практически уверен, что информация, полученная с
помощью этих простых утилит, поможет вам решить больше 90% возникших
проблем с производительностью.
554 Прочтений • [Анализ производительности системы в Linux (linux performance tune optimization speed memory)] [08.05.2012] [Комментариев: 0]
Vova
