Анализ нагрузки на сервер
Анализ нагрузки на сервер позволит быстро понять причины медленной работы. Это необходимо делать ещё и для того, чтобы вовремя планировать покупку новых серверов.
Аппаратная часть любого сервера состоит из 4 основных компонент:
- Процессор
- Память
- Диск
- Сетевой интерфейс
Анализ загруженности сервера заключается в сборе и обработке статистики каждой из этих компонент.
Процессор
Первым делом следует проверить процессор. Самый быстрый способ — использовать top:
top - 22:20:45 up 67 days, 8:04, 2 users, load average: 0.05, 0.03, 0.05 Tasks: 88 total, 1 running, 87 sleeping, 0 stopped, 0 zombie %Cpu(s): 0.0 us, 0.0 sy, 0.0 ni,100.0 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st KiB Mem: 508936 total, 461096 used, 47840 free, 43056 buffers KiB Swap: 0 total, 0 used, 0 free, 237892 cached PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 8867 www-data 20 0 80316 3256 1012 S 0.3 0.6 0:16.06 nginx 30809 mysql 20 0 844m 63m 3332 S 0.3 12.9 38:30.93 mysqld
Необходимо обратить внимание на выделенные участки. Загрузка процессора обычно не должна превышать 10...20%. Исключение составляют сервера специального назначения (например, пережиматоры фоток или медиа данных). Следующие показатели наиболее важные для анализа:
- Показатель us — пользовательские процессы. Высокий показатель означает, что наше приложение нагружает сервер.
- Показатель id — неиспользуемые ресурсы процессора. Этот показатель должен быть высоким (нормальные значения от 80 до 100).
- Показатель wa — ожидание операций ввода/вывода. Высокий показатель означает, что процессор очень долго ждёт ответы от устройств ввода/вывода. Чаще всего это связано с большим количеством операций на диске.
Более развёрнутую статистику можно получить используя утилиту mpstat из пакета sysstat:
# apt-get install sysstat # mpstat -P ALL
Покажет детали по всем процессорам на сервере:
10:30:26 PM CPU %usr %nice %sys %iowait %irq %soft %steal %guest %gnice %idle 10:30:26 PM all 0.47 0.00 0.22 0.07 0.00 0.01 0.03 0.00 0.00 99.20 10:30:26 PM 0 0.47 0.00 0.22 0.07 0.00 0.01 0.03 0.00 0.00 99.20
Инструмент htop умеет показывать нагрузку на процессор в удобном виде:
# apt-get install htop # htop
CPU[|| 11.3%] Tasks: 62, 93 thr; 1 running Mem[|||||||||170/497MB] Load average: 0.15 0.05 0.06 Swp[ 0/0MB] Uptime: 67 days, 08:22:09 PID USER PRI NI VIRT RES SHR S CPU% MEM% TIME+ Command 9377 root 20 0 24596 2064 1372 R 0.5 0.4 0:00.22 htop 9458 www-data 20 0 315M 7328 2824 S 0.0 1.4 0:00.50 php-fpm: pool www
Анализ нагрузки на процессор
Если показатель загрузки процессора (us в top'e) превышает 20%, необходимо оценить возможность оптимизации приложения. Если возможная оптимизация уже была выполнена, необходимо приобретать дополнительные сервера.
В случае высокого показателя ожидания I/O (wa в top'e), необходимо провести дальнейший анализ дисковой и сетевой подсистемы (ниже).
Память
Прежде всего необходимо определить количество занятой и свободной памяти.
# free
Инструмент free покажет данные об использовании памяти:
total used free shared buffers cached Mem: 508936 480540 28396 0 47552 258912 -/+ buffers/cache: 174076 334860 Swap: 0 0 0
Важно обратить внимание на значение free. Это количество свободной памяти. Очень важным показателем является Swap. Это используемое место на диске в том случае, когда оперативной памяти перестаёт хватать.
Более подробную информацию об использовании оперативной памяти можно получить так:
# cat /proc/meminfo
Среди прочего увидим такие сведения:
MemTotal: 508936 kB MemFree: 28148 kB Buffers: 47836 kB Cached: 259388 kB SwapCached: 0 kB Active: 245556 kB Inactive: 178600 kB ... SwapTotal: 0 kB ...
Анализ использования памяти
Малое количество свободной оперативной памяти не является проблемой. Но такая ситуация является предлогом для пристального наблюдения за сервером.
В случае же, если начинает расти Swap, необходимо срочно принимать меры:
- Добавлять оперативную память.
- Приобретать новые сервера и распределять нагрузку между ними.
Старайтесь всегда удерживать используемый своп нулевым.
Диски
Дисковая подсистема может быть нагружена, когда приложение работает с файлами. Кроме этого, диски может нагружать работа с базой данных.
Начать анализ дисков следует с проверки свободного места:
# df -h
Покажет результат по всем разделам:
Filesystem Size Used Avail Use% Mounted on rootfs 20G 2.4G 17G 13% / udev 10M 0 10M 0% /dev tmpfs 5.0M 0 5.0M 0% /run/lock
Колонка Use покажет занятое место. Для основных разделов старайтесь удерживать значение не выше 90%.
Инструмент iotop умеет показывать развёрнутую загрузку диска.
# apt-get install iotop # iotop
Также будет видно распределение по процессам, которые работают с диском:
Total DISK READ : 0.00 B/s | Total DISK WRITE : 2.10 M/s Actual DISK READ: 0.00 B/s | Actual DISK WRITE: 218.22 K/s TID PRIO USER DISK READ DISK WRITE SWAPIN IO> COMMAND 30835 be/4 mysql 0.00 B/s 2.95 K/s 0.00 % 0.07 % mysqld 10273 be/4 www-data 0.00 B/s 194.63 K/s 0.00 % 0.00 % php-fpm: pool www
В примере два процесса — mysqld и php-fpm (это php приложение) — используют операции записи на диск. Необходимо обратить внимание на показатели:
- Actual DISK READ — суммарное фактическое количество данных, читаемых с диска. Отличается от Total DISK READ из-за дискового кэша и оптимизации операций низкого уровня.
- Actual DISK WRITE — суммарное фактическое количество данных, записываемое на диск. Может отличаться от Total DISK WRITE по той же причине.
Анализ дисковой подсистемы
Если диск подвержен большому количеству чтений, правильными вариантами поведения будут:
- В случае, если большинство чтений происходит из приложения, необходимо включить кэширование APC. Если Ваше приложение читает большое количество файлов, продумайте возможность переноса их данных в кэш.
- В случае базы данных убедитесь в правильной настройке её параметров.
- Если чтения происходят в результате обращения к Web серверу (отдача большого количества файлов), обдумайте возможность использования HTTP кэша.
Большое количество записей на диск обычно свидетельствуют о необходимости масштабироваться.
- Убедитесь, что у Вас отключены все логи доступа и отладки. Например, access_log в Nginx'e.
- Большинство записей на диск скорее всего будет генерировать база данных. В таком случае необходимо подумать о выносе её на отдельный сервер. Дальнейшими шагами будет её масштабирование на несколько серверов.
- Большое количество записей также могут генерировать загружаемые файлы.
Сеть
Утилита cbm позволяет увидеть сетевой трафик в реальном времени:
apt-get install cbm cbm
Увидим данные об объёме приёма и передачи в секунду:
Interface Receive Transmit Total lo 10.07 MB/s 10.07 MB/s 20.13 MB/s eth0 73.15 kB/s 2.44 MB/s 2.51 MB/s
Высокий сетевой трафик сам по себе не является проблемой. Но близкие к пиковым показатели указывают на необходимость масштабироваться в ближайшем будущем. Например, средний трафик в 95 Мбит на интерфейсе в 100 Мбит скорее всего будет означать, что текущего сервера вскоре будет недостаточно.
Общая статистика
Удобная утилита dstat покажет общую статистику сервера в реальном времени:
apt-get install dstat dstat
Увидим данные о системе с интервалом в одну секунду:
----total-cpu-usage---- -dsk/total- -net/total- ---paging-- ---system-- usr sys idl wai hiq siq| read writ| recv send| in out | int csw 0 0 99 0 0 0| 873B 18k| 0 0 | 0 0 | 33 75 0 0 100 0 0 0| 0 48k| 640B 1550B| 0 0 | 31 80 0 0 100 0 0 0| 0 0 | 422B 1110B| 0 0 | 29 66 0 0 100 0 0 0| 0 0 | 590B 1110B| 0 0 | 32 70 1 0 99 0 0 0| 0 0 | 478B 1110B| 0 0 | 31 66 0 0 100 0 0 0| 0 0 | 814B 1110B| 0 0 | 34 63 0 0 100 0 0 0| 0 0 | 814B 1110B| 0 0 | 39 70 0 0 100 0 0 0| 0 20k| 814B 1110B| 0 0 | 40 75
Внимание следует обратить на:
- total-cpu-usage — загрузка процессора
- dsk/total — загрузка диска
- net/total — загрузка сети
Самое важное
Не забывайте, что проблемы лучше предупреждать. Поэтому, обязательно используйте системы мониторинга для автоматического отслеживания указанных характеристик.
ruhighload.com