Configuramos um sistema Linux (no Amazon AWS, um sistema semelhante ao CentOS, embora não tenhamos certeza de que as personalizações foram feitas) com armazenamento de 4 TB como um volume XFS sobre 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 sincronizamos de uma fonte no NFS para um volume LVM baseado no XFS montado localmente). No entanto, observamos que, em algum momento no meio, o rsync começou a ficar cada vez mais lento (taxa de transferência bastante reduzida) e a média de carga e o consumo de memória aumentaram em grande parte (e a CPU tem uma proporção muito grande no iowait). Eventualmente, reiniciei o sistema XFS e o sistema aparentemente voltou ao normal, com desempenho rsync mais normal desde, pelo menos nas últimas 24 horas.
Verificamos os gráficos de monitoramento da munin e não notamos nada óbvio, mas descobrimos que as métricas "tamanho da tabela de inode" e "open inode" (verificamos a implementação do plug-in munin que aponta os valores como lidos em / proc / sys / fs / inode-nr) continuou diminuindo ao longo do tempo. Pouco antes de observarmos o rsync travando, observamos que ambas as métricas atingiram o valor de alguns milhares a várias centenas de milhares (nossos servidores não XFS ficam aproximadamente 500k na maior parte do tempo e não mostram nenhuma tendência decrescente monotônica por longos períodos ), e observamos logs do kernel como estes:
login ip-XX-XXX-XXX-XXX: [395850.680006] hrtimer: interrupção demorada 20000573 ns 18 de setembro 17:19:58 Kernel ip-XX-XXX-XXX-XXX: [395850.680006] hrtimer: interrupção demorada 20000573 ns [400921.660046] INFO: rsync da tarefa: 7919 bloqueado por mais de 120 segundos. [400921.660066] "eco 0> / proc / sys / kernel / hung_task_timeout_secs" desativa esta mensagem. [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] Rastreamento de chamada: [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] [] inativo + 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] []? alocação_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", conforme observado no NFS de origem quando isso aconteceu, que anteriormente permanecia estável antes de começarmos a enfrentar o referido problema de rsync.
Não observamos comportamento semelhante em nossos volumes de produção baseados em ext3 e, na verdade, aqueles com tamanhos de volume ainda maiores. Além da diferença do sistema de arquivos, os servidores de arquivos estão em uma classe de máquina semelhante e configurados de maneira semelhante. Como descobrimos que as métricas da tabela de inodes no servidor XFS agora ainda estão em tendência decrescente, semelhante à nossa observação anterior, mesmo que a tenhamos reiniciado ontem ontem, estou preocupado que o mesmo problema nos assombrará novamente em breve e provavelmente reflita alguns problemas com nossa configuração, kernel ou o que quer que seja.
Estamos em volumes XFS montados em inode64 em máquinas de arquitetura x86_64 quando experimentamos isso. No momento, copiamos cerca de 1,3 TB de dados para o volume 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 novamente, e foi montado no inode64 desde o início, quando não havia dados, o sistema de arquivos deve estar limpo e os inodes distribuídos uniformemente.
Alguma idéia sobre qual pode ser a causa?
(ps na verdade, começamos a ver isso novamente desde algumas horas atrás!)