Ativando O log atrasado do XFS ( delaylog mount option) pode ajudar (consulte link ). O CentOS é famoso por usar um kernel com patches, portanto, uma atualização do kernel pode ser necessária.
Nós configuramos um sistema Linux (no Amazon AWS, um sistema semelhante ao CentOS, embora não tenhamos certeza absoluta de que as customizações foram feitas nele) com armazenamento de 4TB como um volume XFS sobre o LVM (para ser usado no NFS4, mas ainda não está em uso), e estamos no processo de usar o rsync para sincronizar arquivos de um servidor NFS de produção para o volume XFS (ou seja, nós rsync de uma fonte sobre NFS para um volume LVM baseado em XFS montado localmente ). No entanto, observamos que, em algum momento no meio, o rsync começou a ficar cada vez mais lento (throughput drasticamente reduzido) e tanto a média de carga quanto o consumo de memória aumentaram em grande medida (e a CPU tem uma proporção muito grande no iowait). Eventualmente eu reiniciei o sistema XFS e o sistema aparentemente voltou ao normal, com um desempenho mais normal do rsync desde, pelo menos nas últimas 24 horas.
Verificamos os gráficos de monitoramento munin e não notamos nada óbvio, mas descobrimos que as métricas "Inode table size" e "open inode" (verificaram a implementação do plugin munin que aponta para os valores como sendo lidos de / proc / sys / fs / inode-nr) continuou diminuindo ao longo do tempo. Pouco antes de observarmos o rsync ficar preso, observamos que as duas métricas estavam no valor de alguns milhares de centenas de milhares (nossos servidores não-XFS ficam em torno de 500k na maior parte do tempo e não apresentam nenhuma tendência decrescente monotônica em períodos extensos ), e nós observamos logs do kernel como estes:
ip-XX-XXX-XXX-XXX login: [395850.680006] hrtimer: interrupt took 20000573 ns Sep 18 17:19:58 ip-XX-XXX-XXX-XXX kernel: [395850.680006] hrtimer: interrupt took 20000573 ns [400921.660046] INFO: task rsync:7919 blocked for more than 120 seconds. [400921.660066] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. [400921.660077] rsync D ffff880002fe4240 0 7919 7918 0x00000000 [400921.660093] ffff8800683e5638 0000000000000282 ffff880000000000 0000000000014240 [400921.660131] ffff8800683e5fd8 0000000000014240 ffff8800683e5fd8 ffff88000726da40 [400921.660153] 0000000000014240 0000000000014240 ffff8800683e5fd8 0000000000014240 [400921.660176] Call Trace: [400921.660202] [] schedule_timeout+0x1fd/0x270 [400921.660220] [] ? pvclock_clocksource_read+0x58/0xd0 [400921.660234] [] ? __raw_callee_save_xen_irq_enable+0x11/0x26 [400921.660247] [] __down+0x76/0xc0 [400921.660262] [] down+0x3b/0x50 [400921.660274] [] ? _raw_spin_unlock_irqrestore+0x19/0x20 [400921.660314] [] xfs_buf_lock+0x2b/0x80 [xfs] [400921.660338] [] _xfs_buf_find+0x139/0x230 [xfs] [400921.660360] [] xfs_buf_get+0x5b/0x160 [xfs] [400921.660378] [] xfs_buf_read+0x13/0xa0 [xfs] [400921.660401] [] xfs_trans_read_buf+0x197/0x2c0 [xfs] [400921.660422] [] xfs_read_agi+0x6f/0x100 [xfs] [400921.660443] [] xfs_ialloc_read_agi+0x29/0x90 [xfs] [400921.660467] [] xfs_ialloc_ag_select+0x12b/0x280 [xfs] [400921.660485] [] xfs_dialloc+0x3c7/0x870 [xfs] [400921.660500] [] ? pvclock_clocksource_read+0x58/0xd0 [400921.660509] [] ? __raw_callee_save_xen_restore_fl+0x11/0x1e [400921.660531] [] xfs_ialloc+0x60/0x6a0 [xfs] [400921.660550] [] ? xlog_grant_log_space+0x39c/0x3f0 [xfs] [400921.660566] [] ? xen_spin_lock+0xa5/0x110 [400921.660583] [] xfs_dir_ialloc+0x7d/0x2d0 [xfs] [400921.660606] [] ? xfs_log_reserve+0xe2/0xf0 [xfs] [400921.660623] [] xfs_create+0x3f7/0x600 [xfs] [400921.660638] [] ? __raw_callee_save_xen_restore_fl+0x11/0x1e [400921.660655] [] xfs_vn_mknod+0xa2/0x1b0 [xfs] [400921.660678] [] xfs_vn_create+0xb/0x10 [xfs] [400921.660689] [] vfs_create+0xa7/0xd0 [400921.660701] [] do_last+0x529/0x650 [400921.660714] [] ? get_empty_filp+0x75/0x170 [400921.660728] [] do_filp_open+0x213/0x670 [400921.660744] [] ? xen_spin_lock+0xa5/0x110 [400921.660753] [] ? __raw_callee_save_xen_restore_fl+0x11/0x1e [400921.660769] [] ? alloc_fd+0x102/0x150 [400921.660780] [] do_sys_open+0x64/0x130 [400921.660792] [] ? __raw_callee_save_xen_irq_disable+0x11/0x1e [400921.660804] [] sys_open+0x1b/0x20 [400921.660815] [] system_call_fastpath+0x16/0x1b
Também observamos um aumento drástico na operação de "pesquisa", como visto no NFS de origem quando isso aconteceu, que antes permanecia estável antes de começarmos a experimentar o problema de rsync.
Não observamos comportamento semelhante em nossos volumes de produção que são baseados em ext3 e, de fato, aqueles com tamanhos de volume ainda maiores. Diferente da diferença do sistema de arquivos, os servidores de arquivos estão em uma classe de máquina semelhante e são configurados de maneira semelhante. Como descobrimos que as métricas de tabela de inode no servidor XFS agora ainda estão na tendência decrescente semelhante à nossa observação anterior, embora tenhamos reinicializado o sistema ontem, estou preocupado que o mesmo problema nos assombrará novamente em breve e provavelmente reflita alguns problemas com nossa configuração, kernel ou qualquer outra coisa.
Estamos em volumes XFS montados com inode64 em máquinas de arquitetura x86_64 quando tivemos isso. No momento, copiamos cerca de 1,3 TB de dados para o volume do XFS, cuja capacidade é de aproximadamente 4 TB, e devemos ter cerca de 3 TB de dados nesse volume, se totalmente copiados. O volume foi criado de novo, então foi inode64-montado desde o início, quando não havia dados dentro, então o sistema de arquivos deve estar limpo e os inodes uniformemente distribuídos.
Alguma ideia sobre o que pode ser a causa?
(p. na verdade nós começamos a ver isso novamente desde algumas horas atrás!)
Ativando O log atrasado do XFS ( delaylog mount option) pode ajudar (consulte link ). O CentOS é famoso por usar um kernel com patches, portanto, uma atualização do kernel pode ser necessária.
polinomial e AndreasM disseram que o que naturalmente vem à mente: parece uma situação difícil, você não tem memória suficiente.
O rsync coleta a lista de arquivos para transferir em uma primeira passagem, e 1 / percorrendo uma grande hierarquia sobre NFS é lenta (local lstat() traduzido como NFS remoto getattr é lento e não é recuperável, já que você está percorrendo apenas uma vez ), 2 / este problema depende do número de inodes (use df -i ), não da quantidade total de dados a serem transferidos.
Note que usar rsync -H|--hard-links é ainda mais caro, o rsync deve construir uma tabela hash completa de todos os inodes para encontrar dupes.
Tente usar o rsync diretamente do sistema de arquivos exportado pelo servidor NFS, ignorando completamente o NFS. Dependendo da sua latência do NFS, isso pode ser um bom reforço.
Em alguns casos em que a travessia de uma grande coleção de inodes era realmente mais cara do que simplesmente copiar os dados, usei algo como ssh source 'tar -cC /path/to/src .' | tar -xC /path/to/dest , que é uma simples cópia de fluxo contínuo que possui um uso constante de memória. Dependendo da configuração da sua CPU + rede, adicionar compressão pode acelerar toda a operação - ou não (adicione -z em ambas as invocações de tar).