Estou no processo de migração de dados para partições LUKS. Agora que a unidade do sistema operacional está rodando no LUKS, tentei começar a migrar as 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]
Digno de nota, por cerca de dois segundos, pvrelatou que estava copiando dados em mais de 2GiB/s. Este é o cache de write-back e o preenchimento das páginas sujas (encontradas pelo monitoramento /proc/meminfo).
Depois, pvregistrou uma velocidade de gravação normal 200MiB/s, mas ainda estava à frente entre 2GiBe 3GiBno cache de write-back.
A média de carga do servidor saltou para além das 10h00 devido a todo o bloqueio de E/S em andamento.
Demora um pouco para abortar o pvteste de gravação porque o cache de write-back precisa ser esvaziado, mas logo após o teste ser abortado, 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:
- Por que as gravações sequenciais sustentadas neste disco de dados tornam o servidor tão lento?
- Como posso evitar atolar os outros discos ao gravar em um ou alguns discos específicos?
- Por que esse tipo de disco rígido causa problemas de desempenho, mas outras unidades não?
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 sequencial no futuro, portanto, não quero que o servidor pare devido a esse problema.
Informações adicionais
Fatos rápidos
Servidor: Dell PowerEdge T320
Núcleo: 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: Servidor Ubuntu 16.04 LTS Xenial Xerus 64 bits
Disco rígido problemático: Toshiba PH3500U-1I72
Eu tenho seis desses discos, todos conhecidos por serem íntegros, e testei dois deles e experimentei uma queda no desempenho de E/S em todo o servidor com ambos. Eles lêem e escrevem 200MiB/squase no início.
Controle o disco rígido (sem problemas): SamsungSP1614C
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 estão conectados a este controlador, todos transmitidos 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/sdcpara noopnão deadlinefaz diferença perceptível. Mudar o agendador para cfqpareceu 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/var/log/syslog
Sincronização do grupo de transações 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
diário 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
Responder1
O disco de controle está conectado a uma porta SATA embutida na placa-mãe.
Conforme declarado, os discos que apresentam problemas de tempo limite de liberação do diário estão conectados ao PERC, o mesmo controlador ao qual os Toshiba 'problemáticos' estão conectados.
O PERC 310 é apenas uma placa RAID de hardware básica. Sua CPU provavelmente fica sobrecarregada facilmente, ou há um bug de firmware. Direct AHCI não é um uso muito comum.
Eu sugeriria que o IO está travando no PERC, e não no sistema operacional
Responder2
Isso é muito para digerir.
Você está usando o ZFS, então há uma boa chance de que isso seja um problema com os discos de 5 TB do seu pool e, potencialmente, com a configuração do seu pool.
Esses podem ser discos do setor 4k, portanto, algumas acomodações devem ser feitas na configuração do ZFS para levar em conta isso.
Você pode fornecer sua df -h,,, e saída ?fdisk -lzpool listzpool status -vzfs list
Responder3
Acho que seu cache de gravação é muito grande em comparação com a velocidade do dispositivo de bloco. Eu sugeriria o seguinte:
vm.dirty_background_bytes = 50000000
vm.dirty_bytes = 200000000
vm.dirty_expire_centisecs = 500
vm.dirty_writeback_centisecs = 20
Nunca defina ambos *_bytese *_ratioporque o último a definir vencerá. Além disso, algumas versões do kernel Linux podem ter um bug em que a configuração *_rationão funciona conforme o esperado. Eu sugeriria usar *_bytessempre.
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.