Устранение неполадок с производительностью и локализация проблем в Linux
Область применения: ✔️ виртуальные машины Linux
Проблемы с производительностью и узкие места
Проблемы с производительностью возникают в различных операционных системах или приложениях, и каждая проблема требует уникального подхода к ее устранению. Процессор, память, сеть и ввод/вывод (I/O) - ключевые области, в которых могут возникнуть проблемы. Каждая из этих областей порождает различные симптомы, иногда одновременно, и требует разных методов диагностики и устранения.
Проблемы с производительностью могут быть вызваны неправильной настройкой приложения или установки. Примером может быть веб-приложение с уровнем кэширования, которое неправильно настроено. Эта ситуация активирует больше запросов, поступающих обратно на сервер-источник, а не обслуживается из кэша.
В другом примере журнал повтора базы данных MySQL или MariaDB находится на диске операционной системы (ОС) или на диске, который не соответствует требованиям к базе данных. В этом сценарии может появиться меньше транзакций в секунду (TPS) из-за конкуренции за ресурсы и более высокое время отклика (задержка).
Если вы полностью понимаете проблему, вы можете лучше определить, где искать стек (ЦП, память, сеть, ввод-вывод). Чтобы устранить проблемы с производительностью, необходимо установить базовый план , позволяющий сравнить метрики после внесения изменений и оценить, улучшилась ли общая производительность.
Устранение неполадок с производительностью виртуальной машины не отличается от устранения проблемы производительности в физической системе. Здесь можно определить, какой ресурс или компонент вызывает узкие места в системе.
Важно понимать, что узкие места всегда существуют. Устранение неполадок с производительностью — это понимание того, где возникает узкий место и как переместить его в менее обиженный ресурс.
Это руководство поможет вам обнаружить и устранить проблемы с производительностью в Azure Виртуальные машины в среде Linux.
Получение указателей производительности
Вы можете получить указатели производительности, подтверждающие или отрицающие наличие ограничения ресурсов.
В зависимости от исследуемого ресурса многие средства помогают получить данные, относящиеся к этому ресурсу. В следующей таблице приведены примеры основных ресурсов.
| Ресурс | Средство |
|---|---|
| ЦП | top, , htopmpstat, pidstatvmstat |
| Диск | iostat, , iotopvmstat |
| Network | ip, , vnstatiperf3 |
| Память | free, , topvmstat |
В следующих разделах рассматриваются указатели и средства, которые можно использовать для поиска основных ресурсов.
Ресурс ЦП
Определенный процент ЦП используется или нет. Аналогичным образом процессы либо тратят время на ЦП (например, 80 процентов usr использования), либо не (например, 80 процентов простоя). Основное средство для подтверждения использования ЦП .top
Средство top выполняется в интерактивном режиме по умолчанию. Он обновляется каждую секунду и отображает процессы, отсортированные по использованию ЦП:
[root@rhel78 ~]$ top
top - 19:02:00 up 2:07, 2 users, load average: 1.04, 0.97, 0.96
Tasks: 191 total, 3 running, 188 sleeping, 0 stopped, 0 zombie
%Cpu(s): 29.2 us, 22.0 sy, 0.0 ni, 48.5 id, 0.0 wa, 0.0 hi, 0.3 si, 0.0 st
KiB Mem : 7990204 total, 6550032 free, 434112 used, 1006060 buff/cache
KiB Swap: 0 total, 0 free, 0 used. 7243640 avail Mem
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
22804 root 20 0 108096 616 516 R 99.7 0.0 1:05.71 dd
1680 root 20 0 410268 38596 5644 S 3.0 0.5 2:15.10 python
772 root 20 0 90568 3240 2316 R 0.3 0.0 0:08.11 rngd
1472 root 20 0 222764 6920 4112 S 0.3 0.1 0:00.55 rsyslogd
10395 theuser 20 0 162124 2300 1548 R 0.3 0.0 0:11.93 top
1 root 20 0 128404 6960 4148 S 0.0 0.1 0:04.97 systemd
2 root 20 0 0 0 0 S 0.0 0.0 0:00.00 kthreadd
4 root 0 -20 0 0 0 S 0.0 0.0 0:00.00 kworker/0:0H
6 root 20 0 0 0 0 S 0.0 0.0 0:00.56 ksoftirqd/0
7 root rt 0 0 0 0 S 0.0 0.0 0:00.07 migration/0
8 root 20 0 0 0 0 S 0.0 0.0 0:00.00 rcu_bh
9 root 20 0 0 0 0 S 0.0 0.0 0:06.00 rcu_sched
10 root 0 -20 0 0 0 S 0.0 0.0 0:00.00 lru-add-drain
11 root rt 0 0 0 0 S 0.0 0.0 0:00.05 watchdog/0
12 root rt 0 0 0 0 S 0.0 0.0 0:00.04 watchdog/1
13 root rt 0 0 0 0 S 0.0 0.0 0:00.03 migration/1
14 root 20 0 0 0 0 S 0.0 0.0 0:00.21 ksoftirqd/1
16 root 0 -20 0 0 0 S 0.0 0.0 0:00.00 kworker/1:0H
18 root 20 0 0 0 0 S 0.0 0.0 0:00.01 kdevtmpfs
19 root 0 -20 0 0 0 S 0.0 0.0 0:00.00 netns
20 root 20 0 0 0 0 S 0.0 0.0 0:00.00 khungtaskd
21 root 0 -20 0 0 0 S 0.0 0.0 0:00.00 writeback
22 root 0 -20 0 0 0 S 0.0 0.0 0:00.00 kintegrityd
Теперь просмотрите dd строку процесса из этого выходных данных:
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
22804 root 20 0 108096 616 516 R 99.7 0.0 1:05.71 dd
Вы можете увидеть, что dd процесс потребляет 99,7 процента ЦП.
Примечание.
Вы можете отобразить использование ЦП в средстве
top, выбрав 1.Средство
topотображает общее использование более 100 процентов, если процесс многопоточный и охватывает более одного ЦП.
Другая полезная ссылка — среднее значение нагрузки. Среднее значение нагрузки показывает среднюю системную нагрузку в 1 минуту, 5-минутные и 15-минутные интервалы. Значение указывает уровень нагрузки системы. Интерпретация этого значения зависит от количества доступных ЦП. Например, если средняя нагрузка составляет 2 в системе с одним ЦП, система настолько загружена, что процессы запускаются в очередь. Если в системе с четырьмя ЦП используется средняя нагрузка на 2, то в целом загрузка ЦП составляет около 50 процентов.
Примечание.
Вы можете быстро получить количество ЦП, выполнив nproc команду.
В предыдущем примере средняя нагрузка составляет 1,04. Это система с двумя ЦП, то есть около 50 процентов использования ЦП. Этот результат можно проверить, если вы заметите значение ЦП в 48,5 процента бездействия. (В выходных данных команды значение простоя top ЦП отображается перед id меткой.)
Используйте среднее значение нагрузки в качестве краткого обзора того, как работает система.
uptime Выполните команду, чтобы получить среднее значение нагрузки.
Ресурс диска (ввода-вывода)
При изучении проблем с производительностью ввода-вывода следующие термины помогают понять, где возникает проблема.
| Срок | Description |
|---|---|
| Размер операций ввода-вывода | Объем данных, обрабатываемых на каждую транзакцию, обычно определенных в байтах. |
| Потоки ввода-вывода | Количество процессов, взаимодействующих с устройством хранилища. Это значение зависит от приложения. |
| Размер блока | Размер ввода-вывода, определенный резервным блоком устройства. |
| Размер сектора | Размер каждого из секторов на диске. Обычно это значение равно 512 байтам. |
| ОПЕРАЦИЙ ВВОДА-ВЫВОДА | Входные выходные операции в секунду. |
| Задержка | Время завершения операции ввода-вывода. Обычно это значение измеряется в миллисекундах (мс). |
| Пропускная способность | Функция объема передаваемых данных за определенный период времени. Обычно это значение определяется как мегабайты в секунду (МБ/с). |
ОПЕРАЦИЙ ВВОДА-ВЫВОДА
Операции ввода-вывода в секунду (IOPS) — это функция количества операций ввода-вывода (операций ввода-вывода), измеряемых в течение определенного времени (в данном случае секунд). Операции ввода-вывода могут быть операции чтения или записи. Удаление или удаление также можно считать операцией в системе хранения. Каждая операция имеет единицу выделения, соответствующую размеру ввода-вывода.
Размер ввода-вывода обычно определяется на уровне приложения как объем данных, записанных или считываемых на транзакцию. Часто используемый размер ввода-вывода — 4K. Тем не менее, меньший размер ввода-вывода, содержащий больше потоков, дает более высокое значение операций ввода-вывода. Так как каждая транзакция может быть завершена относительно быстро (из-за его небольшого размера), меньшее число операций ввода-вывода позволяет выполнять больше транзакций за один и тот же период времени.
Напротив, предположим, что у вас есть одинаковое количество потоков, но используйте больше операций ввода-вывода. Количество операций ввода-вывода в секунду уменьшается, так как каждая транзакция занимает больше времени. Однако пропускная способность увеличивается.
Рассмотрим следующий пример:
1000 операций ввода-вывода в секунду означает, что для каждой секунды завершается одна тысяча операций. Каждая операция занимает примерно одну миллисекунда. (В одной секунде имеется 1000 миллисекунд.) В теории каждая транзакция имеет примерно одну миллисекунда для завершения или около 1 мс задержки.
Зная значение ввода-вывода в секунду и число операций ввода-вывода в секунду, можно вычислить пропускную способность путем умножения операций ввода-вывода в секунду.
Например:
1000 операций ввода-вывода в секунду при 4K IOSize = 4000 КБ/с или 4 МБ/с (3,9 МБ/с, чтобы быть точным)
1000 операций ввода-вывода в секунду при 1M IOSize = 1000 МБ/с или 1 ГБ/с (976 МБ/с, чтобы быть точным)
Более понятной для уравнений версии можно написать следующим образом:
IOPS * IOSize = IOSize/s (Throughput)
Пропускная способность
В отличие от операций ввода-вывода в секунду, пропускная способность — это функция объема данных с течением времени. Это означает, что в течение каждой секунды определенный объем данных записывается или считывается. Эта скорость измеряется в объеме данных>/<> или мегабайтах <в секунду (МБ/с).
Если вы знаете значения пропускной способности и операций ввода-вывода в секунду, можно вычислить операции ввода-вывода в секунду, разделив пропускную способность по ioSize. Следует нормализовать единицы до наименьшего коннотации. Например, если ioSize определен в килобайтах (кб), пропускная способность должна быть преобразована.
Формат уравнения записывается следующим образом:
Throughput / IOSize = IOPS
Чтобы поместить это уравнение в контекст, рассмотрите пропускную способность 10 МБ/с в ioSize 4K. При вводе значений в уравнение результат составляет 10 240/4=2560 операций ввода-вывода в секунду.
Примечание.
10 МБ точно равно 10 240 КБ.
Задержка
Задержка — это измерение среднего количества времени, необходимого для завершения каждой операции. Операции ввода-вывода в секунду и задержки связаны, так как оба понятия являются функцией времени. Например, при 100 операций ввода-вывода в секунду каждая операция занимает примерно 10 мс. Но тот же объем данных можно получить еще быстрее при более низком количестве операций ввода-вывода в секунду. Задержка также называется временем поиска.
Общие сведения о выходных данных iostat
В рамках пакета iostat sysstat средство предоставляет аналитические сведения о производительности диска и метриках использования. iostat может помочь определить узкие места, связанные с подсистемой диска.
Вы можете выполнить iostat простую команду. Базовый синтаксис:
iostat <parameters> <time-to-refresh-in-seconds> <number-of-iterations> <block-devices>
Параметры определяют, какие сведения iostat предоставляются. Без каких-либо параметров iostat команды отображаются основные сведения:
[host@rhel76 ~]$ iostat
Linux 3.10.0-957.21.3.el7.x86_64 (rhel76) 08/05/2019 _x86_64_ (1 CPU)
avg-cpu: %user %nice %system %iowait %steal %idle
41.06 0.00 30.47 21.00 0.00 7.47
Device: tps kB_read/s kB_wrtn/s kB_read kB_wrtn
sda 182.77 5072.69 1066.64 226090 47540
sdd 2.04 42.56 22.98 1897 1024
sdb 12.61 229.23 96065.51 10217 4281640
sdc 2.56 46.16 22.98 2057 1024
md0 2.67 73.60 45.95 3280 2048
По умолчанию iostat отображаются данные для всех существующих блочных устройств, хотя минимальные данные предоставляются для каждого устройства. Доступны параметры, которые помогают выявить проблемы, предоставляя расширенные данные (например, пропускную способность, операции ввода-вывода в секунду, размер очереди и задержку).
Запустите, iostat указав триггеры:
sudo iostat -dxctm 1
Для дальнейшего iostat расширения результатов используйте следующие параметры.
| Параметр | Действие |
|---|---|
-d |
Отображение отчета об использовании устройства. |
-x |
Отображение расширенной статистики. Этот параметр важен, так как он предоставляет размеры операций ввода-вывода в секунду, задержки и очереди. |
-c |
Отображение отчета об использовании ЦП. |
-t |
Печать времени для каждого отчета, отображаемого. Этот параметр полезен для длительных запусков. |
-m |
Отображение статистики в мегабайтах в секунду, более удобочитаемой формой. |
Число 1 в команде сообщает iostat обновляться каждую секунду. Чтобы остановить обновление, нажмите клавиши CTRL+C.
Если включить дополнительные параметры, выходные данные похожи на следующий текст:
[host@rhel76 ~]$ iostat -dxctm 1
Linux 3.10.0-957.21.3.el7.x86_64 (rhel76) 08/05/2019 _x86_64_ (1 CPU)
08/05/2019 07:03:36 PM
avg-cpu: %user %nice %system %iowait %steal %idle
3.09 0.00 2.28 1.50 0.00 93.14
Device: rrqm/s wrqm/s r/s w/s rMB/s wMB/s avgrq-sz avgqu-sz await r_await w_await svctm %util
sda 0.02 0.52 9.66 2.46 0.31 0.10 70.79 0.27 23.97 6.68 91.77 2.94 3.56
sdd 0.00 0.00 0.12 0.00 0.00 0.00 64.20 0.00 6.15 6.01 12.50 4.44 0.05
sdb 0.00 22.90 0.47 0.45 0.01 5.74 12775.08 0.17 183.10 8.57 367.68 8.01 0.74
sdc 0.00 0.00 0.15 0.00 0.00 0.00 54.06 0.00 6.46 6.24 14.67 5.64 0.09
md0 0.00 0.00 0.15 0.01 0.00 0.00 89.55 0.00 0.00 0.00 0.00 0.00 0.00
Общие сведения о значениях
Основные столбцы из выходных iostat данных показаны в следующей таблице.
| Столбец | Description |
|---|---|
r/s |
Операции чтения в секунду (операции ввода-вывода в секунду) |
w/s |
Операции записи в секунду (операции ввода-вывода в секунду) |
rMB/s |
Чтение мегабайт в секунду (пропускная способность) |
wMB/s |
Запись мегабайт в секунду (пропускная способность) |
avgrq-sz |
Средний размер ввода-вывода в секторах; умножьте это число на размер сектора, который обычно составляет 512 байт, чтобы получить размер ввода-вывода в байтах (размер ввода-вывода) |
avgqu-sz |
Средний размер очереди (количество операций ввода-вывода в очереди ожидания) |
await |
Среднее время в миллисекундах для ввода-вывода, обслуживаемого устройством (задержка) |
r_await |
Среднее время чтения в миллисекундах для ввода-вывода, обслуживаемого устройством (задержка) |
w_await |
Среднее время чтения в миллисекундах для ввода-вывода, обслуживаемого устройством (задержка) |
Данные, представленные информационными iostat , но наличие определенных данных в определенных столбцах не означает, что возникла проблема. Данные из iostat всегда должны быть записаны и проанализированы для возможных узких мест. Высокая задержка может указывать на то, что диск достигает точки насыщенности.
Примечание.
Вы можете использовать команду для просмотра статистики pidstat -d ввода-вывода для каждого процесса.
сетевой ресурс;
Сети могут столкнуться с двумя основными узкими местами: низкой пропускной способностью и высокой задержкой.
Сведения о пропускной способности в режиме реального времени можно использовать vnstat . vnstat Однако в всех дистрибутивах недоступен. Широкодоступное iptraf-ng средство — это еще один вариант просмотра трафика интерфейса в режиме реального времени.
Задержка в сети
Задержка сети в двух разных системах может быть определена с помощью простой ping команды в протоколе сообщений управления интернетом (ICMP):
[root@rhel78 ~]# ping 1.1.1.1
PING 1.1.1.1 (1.1.1.1) 56(84) bytes of data.
64 bytes from 1.1.1.1: icmp_seq=1 ttl=53 time=5.33 ms
64 bytes from 1.1.1.1: icmp_seq=2 ttl=53 time=5.29 ms
64 bytes from 1.1.1.1: icmp_seq=3 ttl=53 time=5.29 ms
64 bytes from 1.1.1.1: icmp_seq=4 ttl=53 time=5.24 ms
^C
--- 1.1.1.1 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3004ms
rtt min/avg/max/mdev = 5.240/5.291/5.339/0.035 ms
Чтобы остановить действие ping, нажмите клавиши CTRL+C.
Пропускная способность сети
Вы можете проверить пропускную способность сети с помощью таких средств, как iperf3. Средство iperf3 работает на сервере или клиентской модели, в которой запущено приложение, указав -s флаг на сервере. Затем клиенты подключаются к серверу, указав IP-адрес или полное доменное имя сервера в сочетании с флагом -c . В следующих фрагментах кода показано, как использовать iperf3 средство на сервере и клиенте.
Сервер
root@ubnt:~# iperf3 -s ----------------------------------------------------------- Server listening on 5201 -----------------------------------------------------------Клиент
root@ubnt2:~# iperf3 -c 10.1.0.4 Connecting to host 10.1.0.4, port 5201 [ 5] local 10.1.0.4 port 60134 connected to 10.1.0.4 port 5201 [ ID] Interval Transfer Bitrate Retr Cwnd [ 5] 0.00-1.00 sec 5.78 GBytes 49.6 Gbits/sec 0 1.25 MBytes [ 5] 1.00-2.00 sec 5.81 GBytes 49.9 Gbits/sec 0 1.25 MBytes [ 5] 2.00-3.00 sec 5.72 GBytes 49.1 Gbits/sec 0 1.25 MBytes [ 5] 3.00-4.00 sec 5.76 GBytes 49.5 Gbits/sec 0 1.25 MBytes [ 5] 4.00-5.00 sec 5.72 GBytes 49.1 Gbits/sec 0 1.25 MBytes [ 5] 5.00-6.00 sec 5.64 GBytes 48.5 Gbits/sec 0 1.25 MBytes [ 5] 6.00-7.00 sec 5.74 GBytes 49.3 Gbits/sec 0 1.31 MBytes [ 5] 7.00-8.00 sec 5.75 GBytes 49.4 Gbits/sec 0 1.31 MBytes [ 5] 8.00-9.00 sec 5.75 GBytes 49.4 Gbits/sec 0 1.31 MBytes [ 5] 9.00-10.00 sec 5.71 GBytes 49.1 Gbits/sec 0 1.31 MBytes - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bitrate Retr [ 5] 0.00-10.00 sec 57.4 GBytes 49.3 Gbits/sec 0 sender [ 5] 0.00-10.04 sec 57.4 GBytes 49.1 Gbits/sec receiver iperf Done.
Некоторые распространенные iperf3 параметры для клиента показаны в следующей таблице.
| Параметр | Описание |
|---|---|
-P |
Указывает количество выполняемых параллельных потоков клиента. |
-R |
Изменяет трафик. По умолчанию клиент отправляет данные на сервер. |
--bidir |
Проверяет как отправку, так и скачивание. |
Ресурс памяти
Память — это другой ресурс устранения неполадок для проверки, так как приложения могут или не могут использовать часть памяти. Вы можете использовать такие средства, как free и top для проверки общего использования памяти и определения объема памяти, используемого различными процессами:
[root@rhel78 ~]# free -m
total used free shared buff/cache available
Mem: 7802 435 5250 9 2117 7051
Swap: 0 0 0
В системах Linux обычно наблюдается 99 процентов использования памяти. В выходных free данных есть столбец, который называется buff/cache. Ядро Linux использует свободную (неиспользуемую) память для кэширования запросов ввода-вывода для повышения времени отклика. Этот процесс называется кэшем страниц. Во время давления на память (сценарии, в которых выполняется низкая память), ядро возвращает память, используемую для кэша страниц, чтобы приложения могли использовать такую память.
В выходных данных доступный free столбец указывает, сколько памяти доступно для использования процессами. Это значение вычисляется путем добавления объемов памяти buff/cache и свободной памяти.
Вы можете настроить top команду для сортировки процессов по использованию памяти. По умолчанию сортировка по проценту top ЦП (%). Чтобы отсортировать по использованию памяти (%) выберите shift+M при запуске.top В следующем тексте top показаны выходные данные команды:
[root@rhel78 ~]# top
top - 22:40:15 up 5:45, 2 users, load average: 0.08, 0.08, 0.06
Tasks: 194 total, 2 running, 192 sleeping, 0 stopped, 0 zombie
%Cpu(s): 12.3 us, 41.8 sy, 0.0 ni, 45.4 id, 0.0 wa, 0.0 hi, 0.5 si, 0.0 st
KiB Mem : 7990204 total, 155460 free, 5996980 used, 1837764 buff/cache
KiB Swap: 0 total, 0 free, 0 used. 1671420 avail Mem
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
45283 root 20 0 5655348 5.3g 512 R 99.7 69.4 0:03.71 tail
3124 omsagent 20 0 415316 54112 5556 S 0.0 0.7 0:30.16 omsagent
1680 root 20 0 413500 41552 5644 S 3.0 0.5 6:14.96 python
[...]
Столбец RES указывает резидентную память. Это представляет фактическое использование процесса. Средство top предоставляет аналогичные выходные данные free с точки зрения килобайтов (КБ).
Использование памяти может увеличиться больше, чем ожидалось, если приложение испытывает утечки памяти. В сценарии утечки памяти приложения не могут освободить страницы памяти, которые больше не используются.
Ниже приведена другая команда, используемая для просмотра основных процессов использования памяти:
ps -eo pid,comm,user,args,%cpu,%mem --sort=-%mem | head
В следующем тексте показан пример выходных данных из команды:
[root@rhel78 ~]# ps -eo pid,comm,user,args,%cpu,%mem --sort=-%mem | head
PID COMMAND USER COMMAND %CPU %MEM
45922 tail root tail -f /dev/zero 82.7 61.6
[...]
Вы можете определить нагрузку на память из событий, связанных с нехваткой памяти (OOM), как показано в следующем примере выходных данных:
Jun 19 22:42:14 rhel78 kernel: Out of memory: Kill process 45465 (tail) score 902 or sacrifice child
Jun 19 22:42:14 rhel78 kernel: Killed process 45465 (tail), UID 0, total-vm:7582132kB, anon-rss:7420324kB, file-rss:0kB, shmem-rss:0kB
OOM вызывается после использования ОЗУ (физической памяти) и БУФЕРа (диска).
Примечание.
Вы можете использовать pidstat -r команду для просмотра статистики памяти процесса.
Определение наличия ограничения ресурсов
Можно определить, существует ли ограничение с помощью предыдущих индикаторов и зная текущую конфигурацию. Ограничение можно сравнить с существующей конфигурацией.
Ниже приведен пример ограничения диска:
Виртуальная машина D2s_v3 поддерживает 48 МБ/с нечленной пропускной способности. К этой виртуальной машине подключен диск P30, способный 200 МБ/с. Для приложения требуется не менее 100 МБ/с.
В этом примере ограничение ресурса — это пропускная способность общей виртуальной машины. Требование приложения и то, что может предоставить конфигурация диска или виртуальной машины, указывает ресурс ограничения.
Если приложению требуется <ресурс> измерения1<>, а текущая конфигурация ресурса>< может предоставлять только< измерение2>, то это требование может быть ограничивающим фактором.
Определение ограничивающего ресурса
После определения ресурса, который должен быть ограничивающим фактором в текущей конфигурации, определите, как его можно изменить и как это влияет на рабочую нагрузку. Существуют ситуации, в которых ограничение ресурсов может существовать из-за меры экономии затрат, но приложение по-прежнему может справиться с узким местом без проблем.
Например:
Если приложению требуется 128 ГБ (измерение) ОЗУ (ресурс), а текущая конфигурация ОЗУ (ресурс) может предоставлять только 64 ГБ (измерение), то это требование может быть ограничивающим фактором.
Теперь можно определить ограничивающий ресурс и выполнить действия на основе этого ресурса. Та же концепция применяется к другим ресурсам.
Если эти ограничения ресурсов ожидаются как мера экономии затрат, приложение должно обойти узкие места. Однако если существуют те же меры экономии затрат, и приложение не может легко справиться с нехваткой ресурсов, эта конфигурация может вызвать проблемы.
Внесение изменений на основе полученных данных
Проектирование производительности не о решении проблем, а о понимании того, где может возникнуть следующее узкие места и как обойти его. Узкие места всегда существуют и могут быть перемещены только в другое расположение дизайна.
Например, если приложение ограничено производительностью диска, можно увеличить размер диска, чтобы обеспечить большую пропускную способность. Однако сеть затем становится следующим узким местом. Так как ресурсы ограничены, не существует идеальной конфигурации, и необходимо регулярно устранять проблемы.
Получив данные на предыдущих шагах, вы можете вносить изменения на основе фактических, измеримых данных. Вы также можете сравнить эти изменения с базовыми показателями, которые вы ранее измеряли, чтобы убедиться, что существует реальная разница.
Рассмотрим следующий пример:
Когда вы получили базовый план во время работы приложения, вы определили, что система имела постоянное использование ЦП на 100 процентов в конфигурации двух ЦП. Вы наблюдали загрузку в среднем 4. Это означало, что система выполняла запросы на очередь. Изменение на 8-ЦП сократило использование ЦП до 25 процентов, а средняя загрузка сократилась до 2 при применении той же нагрузки.
В этом примере существует измеримое различие при сравнении полученных результатов с измененным ресурсом. Перед изменением было четкое ограничение ресурсов. Но после изменения достаточно ресурсов, чтобы увеличить нагрузку.
Миграция из локальной среды в облако
Миграция из локальной установки в облачные вычисления может повлиять на несколько различий производительности.
ЦП
В зависимости от архитектуры локальная настройка может запускать ЦП с более высокими скоростями часов и большими кэшами. Результатом будет снижение времени обработки и более высокие инструкции на цикл (IPC). Важно понимать различия моделей ЦП и метрик при работе с миграцией. В этом случае связь между счетчиками ЦП может оказаться недостаточной.
Например:
В локальной системе с четырьмя ЦП, работающими в 3,7 ГГц, доступно в общей сложности 14,8 ГГц для обработки. Если эквивалент в количестве ЦП создается с помощью виртуальной машины D4s_v3, поддерживаемой процессорами 2,1 ГГц, переносимая виртуальная машина имеет 8,1 ГГц для обработки. Это составляет около 44 процентов снижения производительности.
Диск
Производительность диска в Azure определяется типом и размером диска (за исключением диска "Ультра", что обеспечивает гибкость в отношении размера, операций ввода-вывода в секунду и пропускной способности). Размер диска определяет ограничения операций ввода-вывода в секунду и пропускной способности.
Задержка — это метрика, зависящая от типа диска, а не размера диска. Большинство локальных решений хранилища — это массивы дисков с кэшами DRAM. Этот тип кэша обеспечивает задержку (около 200 микросекунд) и высокую пропускную способность чтения и записи (IOPS).
Средняя задержка Azure показана в следующей таблице.
| Тип диска | Задержка |
|---|---|
| Диск ценовой категории "Ультра" или SSD уровня "Премиум" версии 2 | Трехзначные μs (микросекунды) |
| SSD категории "Премиум" или SSD уровня "Стандартный" | Однозначная мс (миллисекунда) |
| HDD (цен. категория "Стандартный") | Двузначная мс (миллисекунда) |
Примечание.
Диск регулируется, если он достигает пределов операций ввода-вывода в секунду или пропускной способности, так как в противном случае задержка может повыситься до 100 миллисекунда или более.
Разница в задержке между локальным (часто меньше миллисекунда) и SSD класса Premium (однозначными миллисекундами) становится фактором ограничения. Обратите внимание на различия в задержке между предложениями хранилища и выберите предложение, которое лучше соответствует требованиям приложения.
Network
Большинство локальных сетевых настроек используют 10 Гбит/с. В Azure пропускная способность сети определяется непосредственно размером виртуальных машин (виртуальных машин). Некоторые пропускная способность сети может превышать 40 Гбит/с. Убедитесь, что выбран размер с достаточной пропускной способностью для приложений. В большинстве случаев ограничение является ограничением пропускной способности виртуальной машины или диска вместо сети.
Память
Выберите размер виртуальной машины с достаточной оперативной памятью для настроенных в данный момент данных.
Диагностика производительности (PerfInsights)
PerfInsights — это рекомендуемое средство из поддержка Azure для проблем с производительностью виртуальной машины. Она предназначена для работы с рекомендациями и выделенными вкладками анализа для ЦП, памяти и ввода-вывода. Его можно запустить через портал Azure или из виртуальной машины, а затем поделиться данными с командой поддержка Azure.
Запуск PerfInsights
PerfInsights доступен как для ОС Windows, так и для Linux. Убедитесь, что дистрибутив Linux находится в списке поддерживаемых дистрибутивов для диагностики производительности для Linux.
Выполнение и анализ отчетов с помощью портал Azure
При установке PerfInsights через портал Azure программное обеспечение устанавливает расширение на виртуальной машине. Пользователи также могут установить PerfInsights в качестве расширения, перейдя непосредственно в колонку "Расширения" в колонке виртуальной машины, а затем выбрав параметр производительности диагностика.
вариант портал Azure 1
Перейдите к колонке виртуальной машины и выберите параметр "Производительность диагностика". Вам будет предложено установить параметр (использует расширения) на выбранной виртуальной машине.
вариант портал Azure 2
Перейдите на вкладку "Диагностика и устранение проблем" в колонке виртуальной машины и найдите ссылку "Устранение неполадок" в разделе "Проблемы с производительностью виртуальной машины".
Что искать в отчете PerfInsights
После запуска отчета PerfInsights расположение содержимого зависит от того, был ли отчет запущен через портал Azure или как исполняемый файл. Для любого из вариантов перейдите к созданной папке журнала или (если в портал Azure) скачайте локально для анализа.
Выполнение портал Azure
Откройте отчет PerfInsights. Вкладка "Результаты" записывает все выбросы с точки зрения потребления ресурсов. Если есть экземпляры медленной производительности из-за конкретного использования ресурсов, вкладка "Результаты " классифицирует каждый поиск как высокий или средний .
Например, в следующем отчете мы видим, что обнаружены результаты среднего влияния, связанные с хранилищем, и мы видим соответствующие рекомендации. Если развернуть событие "Результаты" , вы увидите несколько ключевых сведений.
Дополнительные сведения о PerfInsights в ОС Linux см. в статье "Использование PerfInsights Linux в Microsoft Azure".
Дополнительная информация
Свяжитесь с нами для получения помощи
Если у вас есть вопросы или вам нужна помощь, создайте запрос в службу поддержки или обратитесь за поддержкой сообщества Azure. Вы также можете отправить отзыв о продукте в сообщество отзывов Azure.