Я использую 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
Я использую следующую схему ввода-вывода:
# 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) без -предел варианты, так что не могли бы вы помочь мне, почему нагрузка резко возрастает, когда я пытаюсь ограничить ресурс, используемый утилитой преобразования ImageMagick с помощью -предел вариант и как я могу исправить проблему.
Я запустил вашу точную командную строку (хотя я предполагаю, что с другой картинкой ;-)) с параметрами ограничения и без них. И я понял, в чем проблема: единицы ограничения указаны в байтах. Что это означает?
Вы устанавливаете 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
С помощью этой команды я получаю примерно то же время в реальном времени, что и без ограничения, и у меня более или менее те же операции ввода-вывода, что и без параметров ограничения.
Когда Q2Q становится высоким, это означает, что между последовательными запросами, поступающими в очередь устройства от приложения, есть промежуток времени. Приложение выдает ввод-вывод, оно не отправляет следующий ввод-вывод из следующего сектора диска, головка диска отправляется искать в другое место, и когда оно находит нужный сектор, приложение выдает следующий ввод-вывод. Этот тип ввода-вывода называется случайным вводом-выводом. Случайный ввод-вывод увеличивает время 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
Вы видите, что await - 119,61, svctm - 2,44, а% util - 100,20. Обратите внимание, что avrqu-sz большой, довольно большой - 141,31. Итак, операции ввода-вывода ожидают на блочном уровне, прежде чем будут обслуживаться, и мы видим высокое значение avgqu-sz, также означающее, что есть ожидающие операции ввода-вывода, также означающие переход на блочный уровень. Опять же, это признак того, что мы видим не последовательный поток операций ввода-вывода, а случайные фрагменты, и поэтому svctm отлично работает, в то время как await и avgqu-sz высокие.
Итак, все сводится к тому, как приложение выполняет ввод-вывод. Я не думаю, что ты можешь слишком много этого контролировать. Итак, попробуйте не ограничивать команду convert и посмотреть, сможете ли вы получить поток последовательного ввода-вывода.
Кроме того, не могли бы вы сказать, какова пропускная способность диска, по выражению производителя диска, IOPS. Так что я также могу сказать, насыщаете ли вы свои диски.
И, кстати, хорошая работа с выводом blktrace. Вы также можете пойти дальше и создать PDF-файл с помощью утилиты seekwatcher.
Высокая загрузка сервера - не всегда плохая новость, потому что средняя загрузка отражает объем работы, поставленный ЦП в очередь для выполнения. Если эти процессы, например, ожидают ввода-вывода диска, и диск оказывается довольно медленным, результатом будет высокая средняя нагрузка, но без какого-либо очевидного влияния на производительность.
Не только это, но и, глядя на использование вашего процессора, не похоже, что процессоры делают что-то еще, кроме запуска Image magik. Совершенно нормально, что процесс занимает большую часть времени ЦП, если это единственный важный выполняемый процесс.
Если вы действительно хотите убедиться, что он не загружает процессор, используйте команду nice, чтобы повысить ее удобство. Но, опять же, если это единственный процесс записи заметок, то шансы даже на то, что рецензия не будет иметь большого значения.
Вывод: если процесс преобразования не влияет отрицательно на производительность других программ, не беспокойтесь об этом!
Судя по аргументам, которые у вас есть для ImageMagick, вам кажется, что вам нужен файл TIFF размером 200x200 ... тем не менее, ваш вывод iotop показывает 70 МБ / с записи в ваш массив RAID и абсурдно большое количество транзакций ввода-вывода в секунду.
Вот мои подозрения относительно того, что происходит, хотя я недостаточно знаю об ImageMagick, чтобы подтвердить это. Ограничивая объем памяти до 512 байт, для обработки изображения ImageMagick вынужден использовать диск в качестве промежуточного метода хранения, поскольку он не может использовать память. В результате он потребляет огромную пропускную способность ввода-вывода, так как страницы загружаются и удаляются, что приводит к блокировке системы.
Почему вы устанавливаете такие низкие лимиты - собственно, зачем они вообще? Установка их выше уменьшит количество страниц, которые ImageMagick должен выполнять. значительно. Если вы не доверяете поступающим изображениям и пытаетесь не допустить, чтобы изображения потребляли слишком много ресурсов, установите ограничение на размер изображений, которые вы разрешаете преобразовывать, установите ограничение памяти, скажем, в 2-4 раза больше. cap, которое вы указываете, ограничьте количество одновременных преобразований, а для дополнительной паранойи ограничьте время выполнения команды, чтобы предотвратить вечное зацикливание намеренно искаженного изображения.