Часто владельцы виртуальных и выделенных физических серверов обнаруживают, что несмотря на более чем достаточный объем свободной оперативной памяти (RAM) и процессорного времени (CPU) сайты работают медленно.

Если нет перегрузки сервера по процессору, оперативной памяти и сетевому порту, можно предположить, что причина - перегрузка дисковой подсистемы сервера (HDD) или ее недостаточная производительность.

Проблема актуальна для ситуаций, когда на сервере размещено большое количество VPS-контейнеров, а в качестве дисковой подсистемы используются жесткие диски типа SATA, независимые или объединенные в RAID-массив на программном уровне .

Менее подвержены проблеме VPS, размещаемые на мощных нодах с SAS-дисками в аппаратном массиве (подобная система может превышать традиционные SATA-диски по производительности в разы). Иногда проблема встречается и на независимых выделенных серверах, хотя и более редко, чем на VPS.

Рассмотрим порядок действий, который позволит определить источник проблемы и устранить ее:

1) Выясняем, действительно ли производительность дисковой подсистемы недостаточна (диск перегружен). На серверах с Linux нужно зайти на сервер по SSH, запустить мониторинг процессов top и посмотреть на показатель wa в строке Cpu(s):

На скриншоте выше указанный показатель отмечен красным прямоугольником. Wa обозначает процент времени простоя процессора в связи с ожиданием ввода-вывода. Простой будет тем выше, чем сильнее нагружена дисковая подсистема, так как на ожидание операций ввода-вывода потребуется больше времени. Если значение данного показателя стабильно выше 20%, то проблема действительно имеется, и требуется оптимизация работы дисковой подсистемы.

Пользователям VPS важно понимать, что высокие показатели wa в сочетании с низкой Load Average (LA) на контейнере сигнализируют о перегрузке дисковой подсистемы другим контейнером (контейнерами), и в данном случае решения проблемы следует ожидать в первую очередь от хостинг-провайдера.

На серверах с FreeBSD принцип определения данной проблемы похож – нужно запустить анализатор процессов ввода-вывода, выполнив команду iostat -x . В консоль будет выведена примерно следующая информация:

device     r/s   w/s    kr/s    kw/s wait svc_t  %b
aacd0     58.1  93.0   737.0  2606.7    0  78.2  33

Ключевые показатели:

wait - количество дисковых транзакций в очереди. Показатель, близкий к wa в Linux, но не в процентах, а в натуральных единицах. Чем он больше, тем серьезнее характер проблемы, так как если дисковая подсистема имеет достаточную производительность, число отложенных транзакций будет минимальным.

svc_t - среднее время транзакции в миллисекундах. Оптимально, когда данный показатель имеет низкие значения – на производительных и незанятых дисках операции ввода-вывода не будут выполняться долго.

2) Убедившись в наличии узкого места в работе дисковой подсистемы, нужно запустить анализатор процессов, который покажет, какие именно процессы/сервисы создают избыточную нагрузку на диск. Мы рекомендуем использовать анализатор atop. Эта замечательная утилита портирована и на FreeBSD c сохранением всего функционала, а также добавлением некоторых опций, специфических для этой операционной системы.

Запуск команды atop с опциями -Dd покажет процессы, нагружающие диск, и выполнит сортировку по столбцу DSK, показывающему нагрузку в процентах для каждого сервиса. Кроме того, критически нагруженные диски будут подсвечиваться красным цветом:

На скриншоте видно, что перегружены диски sda и sdb, а источником нагрузки являются процессы архивации и сжатия данных tar и gzip. Определив PID процесса, создающего нагрузку (на примере выше PID-ы проблемных процессов имеют значение 3224 и 3225), мы сможем получить более детальную информацию об этих процессах. К примеру, для получения информации о процессе tar с PID 3224, нужно выполнить комманду ps aux | grep 3224

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

Например, если диск перегружается сервисом MySQL (что не редкость), можно провести анализ запросов с помощью утилиты mytop, и определить и устранить медленные и тяжелые запросы к базе данных. Можно также вынести временные таблицы в RAM (tmpfs), что даст хороший эффект. Можно настроить файловое кеширование для сайта, чтобы сократить число запросов к БД и так далее.

Если диск нагружается веб-сервером Apache, и большинство запросов идут к статическим файлам, то можно установить Nginx в качестве фронт-енда к Apache, настроить прокси-кеширование и опять же, вынести прокси-кеш в RAM (tmpfs), а не хранить его на диске. Если диск перегружается из-за логирования большого числа запросов к сервисам, можно отключить логирование, направив запись логов в /dev/null, а при необходимости - снова его включить.

Вопросы, дополнения и замечания, пожалуйста, оставляйте в комментариях.