Le tabelle Inode si restringono notevolmente nel tempo causando problemi di rsync / inode

Abbiamo installato un Linux (è su Amazon AWS, un sistema simile a CentOS, anche se non siamo esattamente sicuri delle personalizzazioni fatte su di esso) con 4TB di archiviazione come un volume XFS su LVM (in ultima analisi per essere utilizzato per la pubblicazione su NFS4 ma è non ancora in uso) e siamo in fase di utilizzo di rsync per sincronizzare i file da un server NFS di produzione al nostro volume XFS (vale a dire rsync da una sorgente su NFS a un volume LVM basato su XFS a livello locale). Tuttavia, abbiamo osservato che ad un certo punto nel mezzo la rsync ha cominciato a diventare sempre più lento (il passaggio è stato fortemente ridotto) e sia il carico medio sia il consumo di memory sono aumentati in larga misura (e la CPU ha una percentuale molto elevata in iowait). Alla fine ho riavviato il sistema XFS e il sistema apparentemente ripreso alla normalità, con performance normali più rsync da, alless per le ultime 24 ore.

Abbiamo controllato i grafici di monitoraggio munin e non abbiamo notato nulla di evidente, ma abbiamo scoperto che le metriche "Inode table size" e "open inode" (controllato l'implementazione plugin munin che indica i valori da leggere da / proc / sys / fs / inode-nr) continuano a diminuire nel tempo. Poco prima di osservare che il rsync si è bloccato, abbiamo osservato che entrambe le metriche sono state scese al valore di poche migliaia di centinaia di migliaia di persone (i nostri non-XFS server rimangono a circa 500k la maggior parte del tempo e non mostrano una tendenza monotonica in diminuzione nei periodi prolungati ) e abbiamo osservato i log del kernel come questi:

 ip-XX-XXX-XXX-XXX login: [395850.680006] hrtimer: interrupt ha preso 20000573 ns
 Sep 18 17:19:58 kernel ip-XX-XXX-XXX-XXX: [395850.680006] hrtimer: interrupt ha preso 20000573 ns
 [400921.660046] INFO: task rsync: 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 di 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] [] 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

Abbiamo anche osservato un drastico aumento dell'operazione di "lookup" come visto sulla sorgente NFS quando ciò è accaduto, precedentemente stabile prima di iniziare a sperimentare il detto problema rsync.

Non abbiamo osservato simili comportmenti sui nostri volumi di produzione che sono ext3-based e infatti quelli con size ancora maggiori. Oltre alla differenza dei filesystem, i file server si trovano in una class di macchine simili e in un modo simile. Come abbiamo scoperto che le metriche della tabella inode sul server XFS sono ancora in calo tendenzialmente simile alla nostra precedente osservazione, anche se l'abbiamo appena riavviata ieri, sono interessato che la stessa questione ci rinnigherà presto e probabilmente rifletterà alcuni problemi con il nostro setup, il kernel o qualsiasi altra cosa.

Siamo su volumi XFS montati inode64 sulle macchine di architettura x86_64 quando abbiamo sperimentato questo. Al 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 nuovamente così è stato montato inode64 fin dall'inizio, quando non c'erano dati all'interno, quindi il filesystem dovrebbe essere pulito e inodes distribuiti in modo uniforms.

Quali intuizioni su come potrebbe essere la causa?

(in realtà abbiamo cominciato a vedere questo nuovamente da poche ore fa!)

  • XFS I / O Errore di accesso al block logico 0 di un'istantanea LVM: è l'unità o l'istantanea ctriggers?
  • Come correggere un file system
  • cambiando il formato dei file system da xfs a ext4 senza perdere i dati
  • Filesystem pronti alla produzione e altamente affidabili su Linux: ext4 ext3 XFS o JFS (o ZFS)?
  • Memorizza e salva 200 milioni di file di size ridotte
  • Aggiunta di archiviazione da 60 TB a un server SLES 10
  • Modo più veloce per chown un integer dispositivo (xfs)
  • Utilizzo dello spazio grezzo CEPH
  • 2 Solutions collect form web for “Le tabelle Inode si restringono notevolmente nel tempo causando problemi di rsync / inode”

    L'triggerszione della logging ritardata di XFS (opzione di ritardo di delaylog ) potrebbe aiutare (vedere http://en.wikipedia.org/wiki/XFS#Disadvantages ). CentOS è (in) famoso per l'utilizzo di un kernel patchato in modo da poter essere necessario un aggiornamento del kernel.

    polinomiale e AndreasM ha detto ciò che naturalmente mi viene in mente: sembra una situazione sconvolgente, non hai avuto abbastanza memory.

    Rsync raccoglie l'elenco dei file da trasferire in un primo passaggio e 1 / che attraversa una grande gerarchia su NFS è lento (il locale lstat() tradotto come il NFS getattr remoto è lento e non è cachable poiché si è solo attraversati una volta), 2 / this il problema dipende dal numero di inode (usa df -i ), non sulla quantità totale di dati da trasferire.

    Si noti che l'utilizzo di rsync -H|--hard-links è ancora più costoso, rsync deve build una tabella hash completa di tutti gli inodes per trovare dupes.

    Provare ad usare rsync direttamente dal file system esportto dal server NFS, escludendo totalmente NFS. A seconda della latenza NFS, questa potrebbe essere una bella spinta.

    In alcuni casi in cui attraversare una grande collezione di inodes è stato in realtà più costoso che semplicemente copiando i dati, ho usato qualcosa come ssh source 'tar -cC /path/to/src .' | tar -xC /path/to/dest ssh source 'tar -cC /path/to/src .' | tar -xC /path/to/dest ssh source 'tar -cC /path/to/src .' | tar -xC /path/to/dest che è una semplice copia di streaming che ha un utilizzo costante della memory. A seconda della configuration della CPU + della networking, aggiungere la compressione potrebbe accelerare l'intera operazione o no (aggiungere -z in entrambe le richieste di tar).

    Suggerimenti per Linux e Windows Server, quali Ubuntu, Centos, Apache, Nginx, Debian e argomenti di rete.