Самый дешевый vds: избыточная нагрузка на диск |
Владельцы выделенных физических и виртуальных серверов часто обнаруживают, что несмотря на достаточный объем процессорного времени (CPU) и свободного ОЗУ (RAM) веб-сайты работают медленно.
Проблема перегрузки подсистемы диска сервера и самый дешевый vds
В случае если нет перегрузки сервера по процессору, сетевому порту или оперативной памяти, то можно предположить, что причина в перегрузке подсистемы диска сервера (HDD) или же ее малой производительности.
Проблема очень актуальна для тех ситуаций, когда на сервере размещается большое число VPS-контейнеров, а в качестве специальной дисковой подсистемы применяются жесткие диски SATA, независимые, либо объединенные на программном уровне в RAID-массив.
Несколько менее подвержен проблеме самый дешевый vds, который размещается на очень мощных нодах с дисками SAS в аппаратном массиве (такая система способна превышать по производительности обычные SATA-диски в разы). Те, у кого выделенные серверы, тоже могут столкнуться с подобной проблемой, хоть и довольно редко.
Самый дешевый vds: порядок действий при перегрузке подсистемы диска сервера
Рассмотрим общий порядок действий, позволяющий определить причину проблемы и ликвидировать ее.
Во-первых
Выясняем, реально ли общая производительность дисковой подсистемы недостаточна. На серверах с ОС Linux необходимо зайти на сервер по SSH, затем включить мониторинг процессов Top. Посмотреть на показатель WA в строке Cpu (s):
На скриншоте указанный выше показатель отмечен прямоугольником красного цвета. Wa обозначает общий процент времени простоя процессора из-за ожидания ввода-вывода. Такой простой будет тем больше, чем сильнее нагружена подсистема диска, поскольку на ожидание операций ввода-вывода понадобится больше времени.
В случае если значение этого показателя стабильно больше 20%, проблема действительно есть, и необходима оптимизация работы всей дисковой подсистемы.
Всем пользователям VPS Украина крайне важно понимать то, что высокие показатели WA вместе с низкой Load Average на контейнере говорят о перегрузке подсистемы диска иным контейнером (или контейнерами), и в таком случае решения проблемы стоит ожидать прежде всего от хостинг провайдера.
На серверах с ОС 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 — показатель среднего времени транзакции, в миллисекундах. Лучше, если этот показатель имеет очень низкие значения – на незанятых и производительных дисках операции ввода-вывода не будут осуществляться долго.
Во-вторых
Полностью убедившись в наличии проблемного места в работе подсистемы диска, необходимо запустить так называемый анализатор процессов, который вам покажет, какие процессы/сервисы создают на диск избыточную нагрузку.
Мы советуем применять анализатор atop. Это превосходное приложение портировано и на ОС FreeBSD c сохранением функциональности, а также добавлением определенных опций, которые специфические для данной ОС.
Запуск специальной команды atop с функциями -Dd покажет все процессы, которые сильно нагружают диск, и сделает сортировку по столбцу DSK, который показывает всю нагрузку в процентах для каждого из сервисов. Вдобавок, критически нагруженные диски станут подсвечиваться специальным красным цветом:
На картинке показано, что перегружены диски sdb и sda, а причина нагрузки — процессы сжатия и архивации данных gzip и tar. Определив PID процесса, который создает высокую нагрузку (на примере PID-ы сложных процессов обладают значениями 3225 и 3224), вы можете получить гораздо более полную информацию о данных процессах. Например, для получения сведений о процессе tar с PID 3224, необходимо выполнить специальную комманду ps aux | grep 3224.
В-третьих
Обнаружив наличие проблемы, а также ее причины, можно перейти к их ликвидации. Для этого необходимо тщательно проанализировать все процессы, которые создают слишком высокую нагрузку на диск, и после этого принять требуемые меры.
К примеру, если диск перегружается именно сервисом MySQL (что совсем не редкость), то можно сделать анализ запросов при помощи специального приложения Mytop, определить и ликвидировать тяжелые и медленные запросы к БД. Также временные таблицы можно вынести в RAM (tmpfs), что даст очень хороший эффект. Кроме того, можно настроить специальное файловое кеширование для веб-сайта, чтобы сократить общее количество запросов к базе данных.
В случае если нагружается диск веб-сервером Apache, и подавляющее большинство запросов идут именно к статическим файлам, можно в качестве фронт-енда к Apache установить Nginx, настроить прокси-кеширование, вынести прокси-кеш в RAM (tmpfs), чтобы его не хранить на диске.
В случае если диск перегружается в связи с логированием большого количества запросов к сервисам, то можно отключить логирование, при этом направив всю запись логов в /dev/null, а при потребности — опять его включить.