Wir richten ein Linux-System (das auf Amazon AWS, einem CentOS-ähnlichen System, obwohl wir nicht genau sicher sind, ob die Anpassungen vorgenommen wurden) mit 4 TB Speicher als XFS-Volume über LVM ein (das letztendlich für die Bereitstellung über NFS4 verwendet wird) noch nicht in Verwendung) und wir sind dabei, mit rsync Dateien von einem unserer Produktions-NFS-Server auf das XFS-Volume zu synchronisieren (dh wir synchronisieren von einer Quelle über NFS auf ein lokal bereitgestelltes XFS-basiertes LVM-Volume). Wir beobachteten jedoch, dass rsync ab einem bestimmten Zeitpunkt zunehmend träge wurde (Durchsatz stark reduziert) und sowohl der Lastdurchschnitt als auch der Speicherverbrauch stark anstiegen (und die CPU hat einen sehr hohen Anteil an iowait). Irgendwann habe ich das XFS-System neu gestartet und das System ist offenbar wieder normal, mit einer normaleren Rsync-Leistung, zumindest in den letzten 24 Stunden.
Wir haben die Munin-Überwachungsgraphen überprüft und nichts Offensichtliches bemerkt, aber wir haben festgestellt, dass die Metriken "Inode table size" und "open inode" (überprüfte die Implementierung des Munin-Plugins, die darauf hinweist, dass die Werte aus / proc / sys / gelesen werden) fs / inode-nr) nahm mit der Zeit ab. Kurz bevor wir beobachteten, dass rsync stecken bleibt, beobachteten wir, dass beide Metriken von mehreren Hunderttausend auf einige Tausend gesunken waren (unsere Nicht-XFS-Server bleiben die meiste Zeit bei ungefähr 500.000 und zeigen über längere Zeiträume keinen monotonen Abnahme-Trend ) und wir beobachteten Protokolle vom Kernel wie diese:
ip-XX-XXX-XXX-XXX Anmeldung: [395850.680006] hrtimer: Interrupt dauerte 20000573 ns 18. September 17:19:58 ip-XX-XXX-XXX-XXX Kernel: [395850.680006] hrtimer: Interrupt dauerte 20000573 ns [400921.660046] INFO: Task rsync: 7919 wurde für mehr als 120 Sekunden blockiert. [400921.660066] "echo 0> / proc / sys / kernel / hung_task_timeout_secs" deaktiviert diese Nachricht. [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] Trace aufrufen: [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
Wir haben auch einen drastischen Anstieg der "Lookup" -Operation beobachtet, wie dies auf dem Quell-NFS zu beobachten war, das zuvor stabil blieb, bevor das genannte Rsync-Problem auftrat.
Wir haben kein ähnliches Verhalten bei unseren Produktionsmengen beobachtet, die auf ext3 basieren, und zwar mit noch größeren Mengen. Abgesehen vom Unterschied zum Dateisystem befinden sich die Dateiserver auf einer ähnlichen Computerklasse und werden auf ähnliche Weise eingerichtet. Da wir festgestellt haben, dass die Metriken für die Inode-Tabelle auf dem XFS-Server gerade jetzt immer noch im Abwärtstrend sind, ähnlich wie bei unserer früheren Beobachtung, obwohl wir ihn gestern gerade neu gestartet haben, befürchte ich, dass das gleiche Problem uns bald wieder heimsuchen und möglicherweise widerspiegeln wird Einige Probleme mit unserem Setup, Kernel oder was auch immer.
Als wir dies erlebten, befanden wir uns auf inode64-gemounteten XFS-Volumes auf x86_64-Architekturcomputern. Derzeit haben wir ungefähr 1,3 TB Daten auf das XFS-Volume kopiert, dessen Kapazität ungefähr 4 TB beträgt, und wir sollten ungefähr 3 TB Daten in diesem Volume haben, wenn es vollständig kopiert ist. Das Volume wurde neu erstellt und wurde von Anfang an inode64-gemountet, als sich keine Daten darin befanden. Daher sollte das Dateisystem sauber und die Inodes gleichmäßig verteilt sein.
Irgendwelche Einsichten, was die Ursache sein könnte?
(ps in der Tat haben wir das seit ein paar Stunden wieder gesehen!)