Высокая загрузка Linux с помощью утилиты ImageMagick convert и зависаний сервера (вывод blktrack прилагается)
Я использую ImageMagick для преобразования файла JPG в TIF, и я использую параметры ограничения для Imagemagick, как показано ниже:
/usr/bin/convert -limit memory 256 -limit map 512 subjectfile.jpg -colorspace Gray -depth 8 -resample 200x200 output.tif
Когда я запускаю вышеупомянутую команду, нагрузка на сервер внезапно становится очень высокой, и процессоры переходят в состояние ожидания в течение большей части времени, как показано ниже:
Tasks: 245 total, 3 running, 241 sleeping, 0 stopped, 1 zombie
Cpu0 : 0.0%us, 0.0%sy, 0.0%ni, 0.0%id,100.0%wa, 0.0%hi, 0.0%si, 0.0%st
Cpu1 :100.0%us, 0.0%sy, 0.0%ni, 0.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
Cpu2 : 1.0%us, 1.0%sy, 0.0%ni, 0.0%id, 93.1%wa, 0.0%hi, 5.0%si, 0.0%st
Cpu3 : 6.9%us, 1.0%sy, 0.0%ni, 90.1%id, 0.0%wa, 1.0%hi, 1.0%si, 0.0%st
Mem: 4148160k total, 3980380k used, 167780k free, 18012k buffers
Swap: 4096552k total, 96k used, 4096456k free, 3339884k cached
Во время этого iostat показано следующее:
Device: rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await svctm %util
sda 0.00 7361.00 62.00 137.00 3712.00 37180.00 410.97 128.13 120.48 5.04 100.20
sda1 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
sda2 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
sda3 0.00 7361.00 62.00 137.00 3712.00 37180.00 410.97 128.13 120.48 5.04 100.20
sdb 0.00 7368.00 0.00 144.00 0.00 33136.00 460.22 133.84 203.48 6.96 100.20
sdb1 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
sdb2 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
sdb3 0.00 7368.00 0.00 144.00 0.00 33136.00 460.22 133.84 203.48 6.96 100.20
md1 0.00 0.00 61.00 17711.00 3648.00 70844.00 8.38 0.00 0.00 0.00 0.00
md0 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
Device: rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await svctm %util
sda 0.00 1193.00 0.00 470.00 0.00 14200.00 60.43 91.07 216.34 2.02 95.00
sda1 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
sda2 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
sda3 0.00 1193.00 0.00 470.00 0.00 14200.00 60.43 91.07 216.34 2.02 95.00
sdb 0.00 1138.00 0.00 410.00 0.00 8700.00 42.44 141.31 119.61 2.44 100.20
sdb1 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
sdb2 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
sdb3 0.00 1138.00 0.00 410.00 0.00 8700.00 42.44 141.31 119.61 2.44 100.20
md1 0.00 0.00 0.00 5226.00 0.00 20904.00 8.00 0.00 0.00 0.00 0.00
md0 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
Device: rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await svctm %util
sda 0.00 1472.28 0.00 483.17 0.00 7821.78 32.38 5.52 11.43 0.52 25.05
sda1 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
sda2 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
sda3 0.00 1472.28 0.00 483.17 0.00 7821.78 32.38 5.52 11.43 0.52 25.05
sdb 0.00 1511.88 0.00 410.89 0.00 10047.52 48.91 143.60 171.46 2.42 99.31
sdb1 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
sdb2 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
sdb3 0.00 1511.88 0.00 410.89 0.00 10047.52 48.91 143.60 171.46 2.42 99.31
md1 0.00 0.00 0.00 778.22 0.00 3112.87 8.00 0.00 0.00 0.00 0.00
md0 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
Я не очень хорошо знаком с производительностью ввода-вывода в Linux, но, читая в Интернете, мне удалось получить некоторые статистические данные из blktrace, когда это произошло, которые выглядят так:
==================== All Devices ====================
ALL MIN AVG MAX N
--------------- ------------- ------------- ------------- -----------
Q2Q 0.000000499 0.000486353 1.158217913 172004
Q2G 0.000000258 0.000059510 0.198865402 343500
S2G 0.000128922 0.010945336 0.198863747 1840
G2I 0.000000214 0.000000517 0.000168407 343504
Q2M 0.000000190 0.000000519 0.000122999 344516
I2D 0.000000879 0.016310824 0.305521347 342948
M2D 0.000000951 0.007473560 0.205691209 344492
D2C 0.000083899 0.002041770 0.160452919 171859
Q2C 0.000092851 0.013953825 0.317186332 171859
==================== Device Overhead ====================
DEV | Q2G G2I Q2M I2D D2C
---------- | --------- --------- --------- --------- ---------
( 8, 0) | 0.8524% 0.0074% 0.0075% 233.2591% 14.6323%
---------- | --------- --------- --------- --------- ---------
Overall | 0.8524% 0.0074% 0.0075% 233.2591% 14.6323%
==================== Device Merge Information ====================
DEV | #Q #D Ratio | BLKmin BLKavg BLKmax Total
---------- | -------- -------- ------- | -------- -------- -------- --------
( 8, 0) | 343516 343516 1.0 | 8 16 1024 5650976
==================== Device Q2Q Seek Information ====================
DEV | NSEEKS MEAN MEDIAN | MODE
---------- | --------------- --------------- --------------- | ---------------
( 8, 0) | 172005 27058614.9 0 | 0(123703)
---------- | --------------- --------------- --------------- | ---------------
Overall | NSEEKS MEAN MEDIAN | MODE
Average | 172005 27058614.9 0 | 0(123703)
==================== Device D2D Seek Information ====================
DEV | NSEEKS MEAN MEDIAN | MODE
---------- | --------------- --------------- --------------- | ---------------
( 8, 0) | 343516 9204796.3 0 | 0(310240)
---------- | --------------- --------------- --------------- | ---------------
Overall | NSEEKS MEAN MEDIAN | MODE
Average | 343516 9204796.3 0 | 0(310240)
Использование btt с параметрами -A показывает, что это:
==================== Per Process ====================
Q2Qdm MIN AVG MAX N
--------------- ------------- ------------- ------------- -----------
Q2Adm MIN AVG MAX N
--------------- ------------- ------------- ------------- -----------
Q2Cdm MIN AVG MAX N
--------------- ------------- ------------- ------------- -----------
Q2Q MIN AVG MAX N
--------------- ------------- ------------- ------------- -----------
convert 0.085368267 9.765798951 24.050329666 3
md1_raid1 0.000000730 0.000493657 1.158217913 169459
mysqld 0.000001386 0.018154085 14.221072636 2146
sh 0.005889458 0.322064972 1.423632298 5
Q2A MIN AVG MAX N
--------------- ------------- ------------- ------------- -----------
Q2G MIN AVG MAX N
--------------- ------------- ------------- ------------- -----------
convert 0.000000539 0.000003194 0.000005260 16
md1_raid1 0.000000258 0.000060580 0.198865402 333440
mysqld 0.000000270 0.000028381 0.058359194 8476
sh 0.000000506 0.000000827 0.000001610 24
S2G MIN AVG MAX N
--------------- ------------- ------------- ------------- -----------
md1_raid1 0.000128922 0.010842039 0.198863747 1836
mysqld 0.058358625 0.058358625 0.058358625 4
Я использую следующий I/O Schedular:
# cat /sys/block/sd*/queue/scheduler
noop anticipatory deadline [cfq]
noop anticipatory deadline [cfq]
Поэтому мой вопрос заключается в том, почему среднее (AVG) значение Q2Q настолько высоко для утилиты конвертации (ImageMagick), когда я использую его с параметрами предела:
convert 0.085368267 9.765798951 24.050329666 3
Я не вижу проблемы с загрузкой, когда я использую конвертирование (ImageMagick) без опций -limit, поэтому не могли бы вы мне помочь, почему нагрузка сильно увеличивается, когда я пытаюсь ограничить ресурс, используемый утилитой конвертации ImageMagick с опцией -limit и как я могу решить проблему.
4 ответа
Я запустил вашу точную командную строку (хотя с другой картиной, я полагаю;-)) с параметрами лимита и без них. И я понял проблему: предельные параметры блока в байтах. Что это значит?
Вы устанавливаете 256B для максимальной памяти и 512B для отображения файла в памяти. Таким образом, вместо того, чтобы иметь хороший большой объем чтения буфера, вы читаете размер блока FS (или даже меньше, если у вас жесткий диск 4K). Это то, что будет генерировать много ненужных операций ввода-вывода.
То, что вы хотите сделать, это установить 256MiB и 512MiB (будьте осторожны, чтобы учитывать случай MiB, а не MIB или MIB!):
/usr/bin/convert -limit memory 256MiB -limit map 512MiB subjectfile.jpg -colorspace Gray -depth 8 -resample 200x200 output.tif
С помощью этой команды я получаю примерно то же самое реальное время, что и при отсутствии лимита, и у меня более или менее те же операции ввода-вывода, что и без параметров лимита.
Высокая нагрузка на сервер не всегда плохая новость, потому что средняя загрузка отражает, сколько работы ЦП поставило в очередь. Если эти процессы ожидают, например, на дисковом вводе-выводе, и диск оказывается довольно медленным, то это приведет к высокой средней загрузке, но без какого-либо очевидного влияния на производительность.
Не только это, но, глядя на использование вашего процессора, не похоже, что процессоры делают что-то еще, кроме запуска Image Magik. Совершенно нормально, что процесс занимает большую часть процессорного времени, если выполняется единственный значимый процесс.
Если вы действительно хотите убедиться, что процессор не перегружен, используйте команду nice, чтобы увеличить его полезность. Но, опять же, если это единственный процесс запуска банкнот, то шансы даже на отдых не будут иметь большого значения.
Апшот: Если процесс конвертирования не оказывает негативного влияния на производительность других программ, не беспокойтесь об этом!
Когда Q2Q становится высоким, это означает, что существует промежуток времени между последовательными запросами, поступающими в очередь устройства из приложения. Приложение выдает IO, оно не выдает следующий IO из следующего сектора диска, головка диска отправляется на поиск в другом месте, а когда находит соответствующий сектор, приложение выдает следующий IO. Этот вид IO называется случайным IO. Случайный ввод-вывод увеличивает время Q2Q или время между запросами, посылаемыми на уровень блока.
Вы не показали сравнительную blktrace без опции --limit, но я предполагаю, что при использовании с limit команда convert не выполняет случайный ввод-вывод или, по крайней мере, случайность уменьшается до некоторой степени.
Смотрите эту строку от iostat. SDB3 0,00 1138,00 0,00 410,00 0,00 8700,00 42,44 141,31 119,61 2,44 100,20
Вы видите, что ожидание равно 119,61, а svctm - 2,44, а% util - 100,20. Обратите внимание, что avrqu-sz большой, довольно большой в 141.31. Итак, IO ожидают на уровне блоков, прежде чем будут обслуживаться, и мы видим высокое значение avgqu-sz, также означающее, что существуют ожидающие IO, также означающие переход на уровень блоков. Опять же, признак того, что мы видим не последовательный поток операций ввода-вывода, а случайные порции, и поэтому svctm прекрасно работает, в то время как await и avgqu-sz высоки.
Итак, все сводится к тому, как приложение выдает IO. Я не думаю, что вы можете контролировать это слишком много. Итак, попробуйте без ограничения команды convert и посмотрите, можете ли вы получить поток последовательного ввода-вывода.
Кроме того, не могли бы вы сказать, какова пропускная способность диска, с точки зрения поставщика диска, IOPS. Так что я также могу сказать, насыщаете ли вы свои диски.
И кстати, хорошая работа с выводом blktrace. Возможно, вы также захотите сделать PDF-файл с помощью утилиты seekwatcher.
Исходя из аргументов, которые вы используете для ImageMagick, вы, похоже, хотите получить файл TIFF 200x200... но ваш вывод iotop показывает 70 МБ / с записи в ваш RAID-массив и абсурдно большое количество транзакций ввода-вывода в секунду.
Вот мое подозрение о том, что происходит, хотя я не знаю достаточно о ImageMagick, чтобы подтвердить это. Ограничивая объем памяти до 512 байт, для обработки изображения ImageMagick вынужден использовать диск в качестве промежуточного метода хранения, поскольку он не может использовать память. В результате он в итоге потребляет огромную пропускную способность ввода-вывода, так как блокирует входы и выходы, вызывая блокировку системы.
Почему вы устанавливаете ограничения настолько низкими - на самом деле, почему они у вас вообще есть? Установка их выше уменьшит объем подкачки, который ImageMagick должен сделать значительно. Если вы не доверяете поступающим изображениям и пытаетесь не допустить, чтобы изображения потребляли слишком много ресурсов, ограничьте размер изображений, которые вы разрешаете преобразовывать, установите ограничение памяти, скажем, в 2-4 раза. Ограничение, которое вы указываете, ограничивает количество одновременных преобразований, и для дополнительной паранойи, ограничивает время выполнения команды, чтобы предотвратить намеренно искаженное изображение от зацикливания навсегда.