Degradação de desempenho massiva em gravação seqüencial sustentada

Question

Estou no processo de migrar dados para partições LUKS. Agora que a unidade do sistema operacional está sendo executada no LUKS, tentei iniciar a migração das unidades de dados. Então o servidor parou de responder.

Este dispositivo LUKS foi aberto:

cryptsetup luksOpen /dev/sdc data1

E qualquer um desses comandos estrangulou o servidor:

pv /dev/zero > /dev/mapper/data1
pv /dev/zero > /dev/sdc

Não imediatamente, mas em segundos, o servidor ficou inutilmente lento. Tudo bloqueado na E / S:

root@node51 [~]# ps aux | awk '{if($8~"D"||$8=="STAT"){print $0}}' 
USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
root      1197  0.0  0.0      0     0 ?        D    06:39   0:00 [jbd2/dm-1-8]
root      1687  0.1  0.0      0     0 ?        D    11:15   0:12 [kworker/u96:5]
root     13057  2.0  0.0      0     0 ?        D    13:10   0:01 [dmcrypt_write]
root     13644 10.9  0.0   7452   784 pts/1    D+   13:10   0:08 pv /dev/zero
root     14159  0.0  0.0  98256  6836 ?        DNs  13:10   0:00 sshd: root [priv]
root     14772  0.0  0.0  29008    92 ?        D    13:11   0:00 /usr/sbin/CRON -f
root     14773  0.0  0.0  98256  6748 ?        DNs  13:11   0:00 sshd: root [priv]
root     15411  0.0  0.0  98256  6876 ?        DNs  13:11   0:00 sshd: root [priv]
root     16009  0.1  0.0  98256  6840 ?        DNs  13:11   0:00 sshd: root [priv]
root     16632  0.5  0.0  98256  6892 ?        DNs  13:11   0:00 sshd: root [priv]
root     16900  0.0  0.0   5448   356 pts/3    D+   13:11   0:00 awk {if($8~"D"||$8=="STAT"){print $0}}
root     28553  0.6  0.0      0     0 ?        D    12:12   0:21 [txg_sync]

Observe que, por cerca de dois segundos, pv informou que estava copiando dados com mais de 2GiB/s . Isso é o cache de write-back e o preenchimento de páginas sujas (encontrado pelo monitoramento de /proc/meminfo ).

Depois, pv registrou uma velocidade normal de gravação de 200MiB/s , mas ainda estava adiantado entre 2GiB e 3GiB no cache de write-back.

A média de carga do servidor saltou acima de 10,00 devido a todo o bloqueio de E / S ocorrendo.

Demora um tempo para abortar o teste de gravação pv porque o cache write-back precisa ser esvaziado, mas logo após o teste ter sido anulado, o desempenho do servidor voltou ao normal.

Curiosamente, esses comandos não causam atraso no servidor:

# Reads from dm-crypt block device
pv /dev/mapper/data1 > /dev/zero
# Reads from the raw block device
pv /dev/sdc > /dev/zero

# Writes to a control disk of a different model
pv /dev/zero > /dev/sdi
# Reads from a control disk
pv /dev/sdi > /dev/zero

# Writes to a file on a dm-crypt ext4 filesystem on a solid-state drive
pv /dev/zero > /tmp/empty
# Reads from that same solid-state drive
pv /dev/sda > /dev/zero

Eu tenho estas perguntas:

1. Por que as gravações sequenciais sustentadas nesse disco de dados diminuem tanto o servidor?
2. Como posso evitar ocupar os outros discos ao escrever para um ou alguns específicos?
3. Por que esse tipo de disco rígido está causando problemas de desempenho, mas outras unidades não o fazem?

Eu tenho seis discos do mesmo modelo ( /dev/sdc , /dev/sdd , /dev/sde , /dev/sdf , /dev/sdg e /dev/sdh ) para criptografar e eles terão cargas de trabalho de gravação sequenciais no futuro, então eu não quero que o servidor pare com esse problema.

Informações adicionais

Fatos rápidos

Servidor: Dell PowerEdge T320

Kernel: Linux node51 4.4.0-22-generic #39-Ubuntu SMP Thu May 5 16:53:32 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux

Sistema operacional: Ubuntu Server 16.04 LTS Xenial Xerus 64 bits

Disco rígido problemático: Toshiba PH3500U-1I72

Eu tenho seis desses discos, todos conhecidos por serem saudáveis, e eu testei dois deles e experimentei uma queda de desempenho de I / O em todo o servidor com ambos. Eles lêem e escrevem em 200MiB/s perto do começo.

Disco rígido de controle (sem problemas): Samsung SP1614C

Este disco tem uma velocidade de gravação sustentada de 50MiB/s . Será que o disco problemático é muito rápido?

Controlador de disco: Dell PERC H310

Duas unidades de estado sólido e seis discos rígidos problemáticos são conectados a este controlador, todos os quais são passados diretamente como AHCI. O disco de controle está conectado a uma porta SATA embutida na placa-mãe.

Agendadores de E / S

root@node51 [/tmp]# tail -n +1 /sys/block/sd*/queue/scheduler 
==> /sys/block/sda/queue/scheduler <==
noop [deadline] cfq 

==> /sys/block/sdb/queue/scheduler <==
noop [deadline] cfq 

==> /sys/block/sdc/queue/scheduler <==
[noop] deadline cfq 

==> /sys/block/sdd/queue/scheduler <==
[noop] deadline cfq 

==> /sys/block/sde/queue/scheduler <==
[noop] deadline cfq 

==> /sys/block/sdf/queue/scheduler <==
[noop] deadline cfq 

==> /sys/block/sdg/queue/scheduler <==
[noop] deadline cfq 

==> /sys/block/sdh/queue/scheduler <==
[noop] deadline cfq 

==> /sys/block/sdi/queue/scheduler <==
noop [deadline] cfq

Alterar o agendador de /dev/sdc de noop para deadline não faz diferença perceptível. A alteração do agendador para cfq pareceu reduzir um pouco o atraso, mas as operações de E / S nos outros discos ainda sofreram.

vm.dirty* parâmetros do kernel

root@node51 [~]# sysctl -a | grep 'vm.dirty'
vm.dirty_background_bytes = 0
vm.dirty_background_ratio = 10
vm.dirty_bytes = 0
vm.dirty_expire_centisecs = 3000
vm.dirty_ratio = 20
vm.dirty_writeback_centisecs = 500
vm.dirtytime_expire_seconds = 43200

Exemplos de lentidão detectada e registrada em /var/log/syslog

Sincronização do grupo de transações do ZFS:

May 11 19:28:44 node51 kernel: [ 4080.179688] INFO: task txg_sync:3179 blocked for more than 120 seconds.
May 11 19:28:44 node51 kernel: [ 4080.179905]       Tainted: P           O    4.4.0-22-generic #39-Ubuntu
May 11 19:28:44 node51 kernel: [ 4080.180110] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
May 11 19:28:44 node51 kernel: [ 4080.180357] txg_sync        D ffff88060b68baa8     0  3179      2 0x00000000
May 11 19:28:44 node51 kernel: [ 4080.180362]  ffff88060b68baa8 ffff880616a96d00 ffff8806133ea940 ffff880603dc2940
May 11 19:28:44 node51 kernel: [ 4080.180366]  ffff88060b68c000 ffff880616ad6d00 7fffffffffffffff ffff88056cb8c508
May 11 19:28:44 node51 kernel: [ 4080.180368]  0000000000000001 ffff88060b68bac0 ffffffff818211f5 0000000000000000
May 11 19:28:44 node51 kernel: [ 4080.180372] Call Trace:
May 11 19:28:44 node51 kernel: [ 4080.180381]  [<ffffffff818211f5>] schedule+0x35/0x80
May 11 19:28:44 node51 kernel: [ 4080.180385]  [<ffffffff81824315>] schedule_timeout+0x1b5/0x270
May 11 19:28:44 node51 kernel: [ 4080.180390]  [<ffffffff810abe52>] ? default_wake_function+0x12/0x20
May 11 19:28:44 node51 kernel: [ 4080.180395]  [<ffffffff810c33b2>] ? __wake_up_common+0x52/0x90
May 11 19:28:44 node51 kernel: [ 4080.180398]  [<ffffffff81820744>] io_schedule_timeout+0xa4/0x110
May 11 19:28:44 node51 kernel: [ 4080.180412]  [<ffffffffc05afbec>] cv_wait_common+0xbc/0x140 [spl]
May 11 19:28:44 node51 kernel: [ 4080.180416]  [<ffffffff810c3a70>] ? wake_atomic_t_function+0x60/0x60
May 11 19:28:44 node51 kernel: [ 4080.180423]  [<ffffffffc05afcc8>] __cv_wait_io+0x18/0x20 [spl]
May 11 19:28:44 node51 kernel: [ 4080.180487]  [<ffffffffc071320e>] zio_wait+0x10e/0x1f0 [zfs]
May 11 19:28:44 node51 kernel: [ 4080.180528]  [<ffffffffc069ce66>] dsl_pool_sync+0x2c6/0x430 [zfs]
May 11 19:28:44 node51 kernel: [ 4080.180573]  [<ffffffffc06b85b6>] spa_sync+0x366/0xb30 [zfs]
May 11 19:28:44 node51 kernel: [ 4080.180576]  [<ffffffff810abe52>] ? default_wake_function+0x12/0x20
May 11 19:28:44 node51 kernel: [ 4080.180623]  [<ffffffffc06c9a4a>] txg_sync_thread+0x3ba/0x630 [zfs]
May 11 19:28:44 node51 kernel: [ 4080.180669]  [<ffffffffc06c9690>] ? txg_delay+0x180/0x180 [zfs]
May 11 19:28:44 node51 kernel: [ 4080.180676]  [<ffffffffc05aae31>] thread_generic_wrapper+0x71/0x80 [spl]
May 11 19:28:44 node51 kernel: [ 4080.180682]  [<ffffffffc05aadc0>] ? __thread_exit+0x20/0x20 [spl]
May 11 19:28:44 node51 kernel: [ 4080.180686]  [<ffffffff810a0588>] kthread+0xd8/0xf0
May 11 19:28:44 node51 kernel: [ 4080.180688]  [<ffffffff810a04b0>] ? kthread_create_on_node+0x1e0/0x1e0
May 11 19:28:44 node51 kernel: [ 4080.180692]  [<ffffffff8182568f>] ret_from_fork+0x3f/0x70
May 11 19:28:44 node51 kernel: [ 4080.180694]  [<ffffffff810a04b0>] ? kthread_create_on_node+0x1e0/0x1e0

revista ext4:

May 11 20:46:46 node51 kernel: [ 6000.186474] INFO: task jbd2/dm-2-8:1148 blocked for more than 120 seconds.
May 11 20:46:46 node51 kernel: [ 6000.193164]       Tainted: P           O    4.4.0-22-generic #39-Ubuntu
May 11 20:46:46 node51 kernel: [ 6000.199950] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
May 11 20:46:46 node51 kernel: [ 6000.208323] jbd2/dm-2-8     D ffff88060a6e7c98     0  1148      2 0x00000000
May 11 20:46:46 node51 kernel: [ 6000.208330]  ffff88060a6e7c98 0000000000000246 ffff8806133eb700 ffff88060b561b80
May 11 20:46:46 node51 kernel: [ 6000.208333]  ffff88060a6e8000 ffff88060aeb68b8 ffff88060a6e7d88 ffff88060a6e7d70
May 11 20:46:46 node51 kernel: [ 6000.208336]  ffff88060b561b80 ffff88060a6e7cb0 ffffffff818211f5 ffff8805fd6af900
May 11 20:46:46 node51 kernel: [ 6000.208339] Call Trace:
May 11 20:46:46 node51 kernel: [ 6000.208355]  [<ffffffff818211f5>] schedule+0x35/0x80
May 11 20:46:46 node51 kernel: [ 6000.208361]  [<ffffffff812ea0e0>] jbd2_journal_commit_transaction+0x240/0x1870
May 11 20:46:46 node51 kernel: [ 6000.208365]  [<ffffffff810b6be1>] ? dequeue_entity+0x431/0xa80
May 11 20:46:46 node51 kernel: [ 6000.208368]  [<ffffffff810b774a>] ? dequeue_task_fair+0x51a/0x8a0
May 11 20:46:46 node51 kernel: [ 6000.208372]  [<ffffffff810c3a70>] ? wake_atomic_t_function+0x60/0x60
May 11 20:46:46 node51 kernel: [ 6000.208378]  [<ffffffff810ec5fe>] ? try_to_del_timer_sync+0x5e/0x90
May 11 20:46:46 node51 kernel: [ 6000.208381]  [<ffffffff812ef32a>] kjournald2+0xca/0x250
May 11 20:46:46 node51 kernel: [ 6000.208384]  [<ffffffff810c3a70>] ? wake_atomic_t_function+0x60/0x60
May 11 20:46:46 node51 kernel: [ 6000.208387]  [<ffffffff812ef260>] ? commit_timeout+0x10/0x10
May 11 20:46:46 node51 kernel: [ 6000.208391]  [<ffffffff810a0588>] kthread+0xd8/0xf0
May 11 20:46:46 node51 kernel: [ 6000.208394]  [<ffffffff810a04b0>] ? kthread_create_on_node+0x1e0/0x1e0
May 11 20:46:46 node51 kernel: [ 6000.208397]  [<ffffffff8182568f>] ret_from_fork+0x3f/0x70
May 11 20:46:46 node51 kernel: [ 6000.208399]  [<ffffffff810a04b0>] ? kthread_create_on_node+0x1e0/0x1e0
May 11 20:46:46 node51 kernel: [ 6292.776357] perf interrupt took too long (2539 > 2500), lowering kernel.perf_event_max_sample_rate to 50000

    

Answer 1

The control disk is connected to a SATA port built into the motherboard.

Como afirmado, os discos que experimentam os problemas de liberação de tempo do lançamento estão conectados ao PERC, o mesmo controlador ao qual os 'problemáticos' Toshibas estão conectados.

O PERC 310 é apenas uma placa básica de hardware. É CPU é provavelmente facilmente sobrecarregado, ou que existe um erro de firmware. AHCI direto não é um uso muito comum.

Gostaria de sugerir que o IO está bloqueando o PERC, e não o sistema operacional

    

Answer 2

Isso é muito para digerir.

Você está usando o ZFS, portanto, há uma boa chance de que isso seja um problema com os discos de 5 TB em seu pool e possivelmente com a configuração do seu pool.

Estes podem ser discos do setor 4k, portanto, algumas acomodações devem ser feitas em sua configuração do ZFS para que isso seja considerado.

Você pode fornecer sua df -h , fdisk -l , zpool list , zpool status -v e zfs list output?

    

Answer 3

Acho que seu cache de gravação é muito grande em comparação com as velocidades de dispositivos de bloco. Sugiro seguir:

vm.dirty_background_bytes = 50000000
vm.dirty_bytes = 200000000
vm.dirty_expire_centisecs = 500
vm.dirty_writeback_centisecs = 20

Nunca defina *_bytes e *_ratio porque o último que foi definido vencerá. Além disso, algumas versões do kernel do Linux podem ter um bug onde a configuração de *_ratio não funciona conforme o esperado. Sugiro usar *_bytes todas as vezes.

Infelizmente, as configurações do cache de gravação são globais, até onde eu sei. Como resultado, a taxa de transferência para seus dispositivos mais rápidos sofrerá um pouco quando você precisar reduzir o tamanho do cache de gravação global devido a algum dispositivo lento.