Installiamo un sistema Linux (è su Amazon AWS, un sistema simile a CentOS anche se non siamo esattamente sicuri delle personalizzazioni fatte su di esso) con un sistema di archiviazione da 4 TB come volume XFS su LVM (in definitiva da utilizzare per servire su NFS4, ma è non ancora in uso) e stiamo utilizzando rsync per sincronizzare i file da un nostro server NFS di produzione al volume XFS (ovvero eseguiamo la risincronizzazione da un'origine su NFS a un volume LVM basato su XFS montato localmente). Tuttavia, abbiamo osservato che a un certo punto nel mezzo la rsync ha iniziato a diventare sempre più lenta (throughput drasticamente ridotto) e sia il carico medio che il consumo di memoria sono aumentati di molto (e la CPU ha una proporzione molto grande di iowait). Alla fine ho riavviato il sistema XFS e il sistema apparentemente è tornato alla normalità, con prestazioni rsync più normali da almeno, nelle ultime 24 ore.
Abbiamo controllato i grafici di monitoraggio di Munin e non abbiamo notato nulla di ovvio, ma abbiamo scoperto che le metriche "Dimensione tabella Inode" e "Inode aperto" (controllato l'implementazione del plug-in Munin che indica i valori come letti da / proc / sys / fs / inode-nr) ha continuato a diminuire nel tempo. Poco prima di osservare che rsync si bloccava, abbiamo osservato che entrambe le metriche erano ridotte al valore di poche migliaia da diverse centinaia di migliaia (i nostri server non XFS rimangono a circa 500k per la maggior parte del tempo e non mostrano alcuna tendenza decrescente monotonica per periodi prolungati ) e abbiamo osservato i log del kernel come questi:
ip-XX-XXX-XXX-XXX login: [395850.680006] hrtimer: l'interrupt ha richiesto 20000573 ns 18 set 17:19:58 kernel ip-XX-XXX-XXX-XXX: [395850.680006] hrtimer: l'interrupt ha richiesto 20000573 ns [400921.660046] INFO: risincronizzazione attività: 7919 bloccato per più di 120 secondi. [400921.660066] "echo 0> / proc / sys / kernel / hung_task_timeout_secs" disabilita questo messaggio. [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] Traccia chiamata: [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] [] giù + 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
Abbiamo anche osservato un drastico aumento delle operazioni di "ricerca" come si è visto sul NFS di origine quando ciò è accaduto, che in precedenza era rimasto stabile prima di iniziare a sperimentare il problema rsync.
Non abbiamo osservato comportamenti simili sui nostri volumi di produzione basati su ext3 e in effetti quelli con dimensioni di volume ancora maggiori. A parte la differenza del file system, i file server si trovano su una classe macchina simile e si configurano in modo simile. Dato che abbiamo scoperto che le metriche della tabella di inode sul server XFS in questo momento sono ancora sulla tendenza decrescente simile alla nostra precedente osservazione anche se l'abbiamo appena riavviata ieri, sono preoccupato che lo stesso problema ci perseguiterà presto e potrebbe probabilmente riflettere alcuni problemi con il nostro setup, kernel o altro.
Siamo su volumi XFS montati su inode64 su macchine con architettura x86_64 quando abbiamo riscontrato questo. In questo momento abbiamo copiato circa 1,3 TB di dati nel volume XFS la cui capacità è di circa 4 TB e dovremmo avere circa 3 TB di dati in quel volume se completamente copiati. Il volume è stato creato di nuovo, quindi è stato montato inode64 fin dall'inizio quando non c'erano dati all'interno, quindi il filesystem dovrebbe essere pulito e gli inode distribuiti uniformemente.
Qualche idea su quale potrebbe essere la causa?
(ps in effetti abbiamo iniziato a vederlo di nuovo da qualche ora!)