Alta carga do Linux com o utilitário de conversão do ImageMagick e congelamentos do servidor (saída blktrack anexada)

Question

Estou usando o ImageMagick para converter um JPG em um arquivo TIF e estou usando as opções de limite do Imagemagick, conforme abaixo:

/usr/bin/convert -limit memory 256 -limit map 512 subjectfile.jpg -colorspace Gray -depth 8 -resample 200x200 output.tif

Quando eu executo o comando acima, a carga no servidor repentinamente fica muito alta e as CPUs ficam em estado de espera a maior parte do tempo, conforme abaixo:

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

O iostat durante isso mostra o seguinte:

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

Eu não estou muito familiarizado com o desempenho do Linux I / O, mas lendo na internet eu consegui algumas estatísticas do blktrace enquanto isso acontecia, o que mostra como:

==================== 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)

Usando o btt com as opções -A mostra isso:

==================== 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

Estou usando o seguinte I / O Schedular:

# cat /sys/block/sd*/queue/scheduler 
noop anticipatory deadline [cfq] 
noop anticipatory deadline [cfq]

Portanto, minha pergunta é por que o valor médio (AVG) Q2Q é tão alto para o utilitário convert (ImageMagick) quando eu o uso com limite opções:

convert           0.085368267   9.765798951  24.050329666           3

Eu não vejo o problema de carga indo em altura quando eu uso converter (ImageMagick) sem -limit opções, então você pode por favor me ajude por que o carregamento dispara alto quando tento limitar o recurso usado pelo utilitário de conversão do ImageMagick com a opção -limit e como posso corrigir o problema.

    

Answer 1

Eu executei sua linha de comando exata (embora com uma imagem diferente, presumo ;-)) com e sem as opções de limite. E eu entendi o problema: a unidade de opções de limite está em bytes. O que significa isso?

Você define 256B para o máximo de memória e 512B para o mapeamento de arquivos na memória. Assim, em vez de ter um grande pedaço de buffer de leitura, você lê o tamanho do bloco FS (ou até menos se você tiver um disco rígido de 4K). Isso é algo que geraria muitas IOs desnecessárias.

O que você quer fazer é definir 256MiB e 512MiB (cuidado para respeitar o caso MiB e não o mib ou MIB!):

/usr/bin/convert -limit memory 256MiB -limit map 512MiB subjectfile.jpg -colorspace Gray -depth 8 -resample 200x200 output.tif

Com este comando, recebo aproximadamente o mesmo tempo real que quando não estou usando o limite e tenho mais ou menos as mesmas atividades de IO do que sem as opções de limite.

    

Answer 2

A alta carga de servidor nem sempre é uma má notícia, porque a média de carga é um reflexo de quanto trabalho a CPU enfileirou para fazer. Se esses processos estiverem esperando no Disk IO, por exemplo, e o disco for muito lento, resultarão médias de carga alta, mas sem qualquer impacto óbvio no desempenho.

Não apenas isso, mas olhando para o uso da CPU, não parece que as CPUs estão fazendo muito mais do que executar o Image magik. É perfeitamente normal que um processo tome a maior parte do tempo da CPU se for o único processo significativo em execução.

Se você realmente quiser ter certeza de que ele não está sobrecarregando a CPU, use o comando nice para aumentar sua simpatia. Mas, novamente, se é o único processo de observação em execução, então as chances são que mesmo um reconhecimento não fará muita diferença.

Upshot: Se o processo de conversão não estiver afetando negativamente o desempenho de outros programas, não se preocupe com isso!

    

Answer 3

Quando o Q2Q fica alto, significa que há intervalo de tempo entre as solicitações sucessivas que chegam à fila de dispositivos a partir do aplicativo. O aplicativo emite um IO, ele não emite o próximo IO do próximo setor do disco, o cabeçote do disco vai procurar outro lugar e, quando encontra o setor apropriado, o aplicativo emite o próximo IO. Esse tipo de IO é chamado de IO aleatório. O IO aleatório aumenta o tempo ou tempo de Q2Q entre os pedidos enviados para a camada de bloco.

Você não mostrou um blktrace comparativo sem a opção --limit, mas eu diria que quando usado com limite, o comando convert não está fazendo IO aleatório ou, pelo menos, a aleatoriedade é reduzida até certo ponto.

Veja esta linha do iostat. sdb3 0,00 1138,00 0,00 410,00 0,00 87,00,00 42,44 141,31 119,61 2,44 100,20

Você vê que esperar é 119.61 enquanto svctm é 2.44 e% util é 100.20. Note que o avrqu-sz é grande, muito grande em 141.31. Assim, os IOs estão esperando na camada de bloco antes de serem atendidos e vemos um valor alto de avgqu-sz também significando que existem IOs pendentes que também significam ir para a camada de bloqueio. Novamente, uma indicação de que não estamos vendo um fluxo seqüencial de IOs, mas pedaços aleatórios e é por isso que, svctm está perfeitamente bem enquanto await e avgqu-sz são altos.

Então, resume-se a como o aplicativo está emitindo o pedido de veiculação. Eu não acho que você pode controlar muito sobre isso. Então, tente sem limitar o comando convert e veja se você pode obter um fluxo de IO seqüencial.

Além disso, você pode dizer qual é a taxa de transferência do disco, no termo do fornecedor do disco, IOPS. Então eu também posso dizer se você está saturando seus discos.

E, btw, bom trabalho com a saída blktrace. Você também pode querer ir em frente e fazer um pdf usando o utilitário seekwatcher.

    

Answer 4

A partir dos argumentos que você tem para o ImageMagick, você parece estar desejando um arquivo TIFF 200x200 ... mas sua saída iotop mostra uma gravação de 70MB / s para sua matriz RAID e um número absurdamente alto de transações de E / S por segundo .

Aqui está minha suspeita sobre o que está acontecendo, embora eu não saiba o suficiente sobre o ImageMagick para confirmá-lo. Ao limitar a quantidade de memória a 512 bytes, a fim de processar a imagem, o ImageMagick é forçado a usar o disco como um método de armazenamento intermediário, uma vez que não pode usar a memória. Como resultado, ele acaba consumindo uma quantidade enorme de taxa de transferência de E / S à medida que entra e sai das páginas, fazendo com que o sistema trave.

Por que você está definindo os limites tão baixos - na verdade, por que você os tem? Configurá-los mais alto reduzirá a quantidade de paginação que o ImageMagick precisa fazer significativamente . Se você não confiar nas imagens que estão chegando e tentar evitar que as imagens consumam muitos recursos, coloque um limite no tamanho das imagens que você permite a conversão, defina o limite de memória para, digamos, 2-4X a limite que você especificar, limite o número de conversões simultâneas e, para paranoia extra, limite o tempo de execução do comando para evitar que uma imagem intencionalmente mal formada seja ativada para sempre.