Ми встановлюємо Linux (це на Amazon AWS, CentOS-подібній системі, хоча ми точно не впевнені, що налаштування зроблено на ній), система з 4TB-накопичувачем як обсяг XFS над LVM (зрештою, використовується для обслуговування над NFS4, але це ще не використовується), і ми перебуваємо в процесі використання rsync для синхронізації файлів з нашого виробничого NFS-сервера до тома XFS (тобто ми rsync від джерела через NFS до локально встановленого тома LVM на основі XFS). Однак ми помітили, що в якийсь момент в середині rsync починає ставати все більш млявим (пропускна здатність різко зменшується), і середнє навантаження, і споживання пам’яті значно зросли (і процесор має дуже велику частку в iowait). Врешті-решт я перезавантажив систему XFS, і система, мабуть, відновилася до нормального, з більш нормальною роботою rsync з, принаймні, протягом останніх 24 годин.
Ми перевірили графіки моніторування munin і не помітили нічого очевидного, але виявили, що показники "розмір таблиці Inode" і "відкритий inode" (перевірили реалізацію плагіна munin, який вказує на значення, як прочитані з / proc / sys / fs / inode-nr) з часом зменшувався. Незадовго до того, як ми спостерігали затримку rsync, ми помітили, що обидві показники знизилися до кількох тисяч від декількох сотень тисяч (наші не-XFS-сервери залишаються приблизно в 500 кл. Більшу частину часу і не демонструють монотонного зниження тенденції протягом тривалих періодів ), і ми спостерігали журнали з ядра, такі:
ip-XX-XXX-XXX-XXX вхід: [395850.680006] hrtimer: перерва зайняла 20000573 нс 18 вересня 17:19:58 ip-XX-XXX-XXX-XXX ядро: [395850.680006] hrtimer: перерва зайняла 20000573 нс [400921.660046] ІНФОРМАЦІЯ: rsync завдання: 7919 заблоковано більше 120 секунд. [400921.660066] "echo 0> / proc / sys / kernel / hung_task_timeout_secs" відключає це повідомлення. [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] Слід дзвінків: [400921.660202] [] графік_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] [] вниз + 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
Ми також спостерігали різке збільшення операції "пошуку", як це спостерігалось у джерелі NFS, коли це сталося, яке раніше залишалося стабільним до того, як ми почали відчувати зазначену проблему rsync.
Ми не спостерігали подібної поведінки на наших обсягах виробництва, що базуються на ext3, і фактично вони мали ще більші обсяги. Окрім різниці файлової системи, файлові сервери знаходяться на подібному машинному класі та налаштовуються аналогічно. Оскільки ми з'ясували, що показники таблиці inode на сервері XFS лише зараз продовжують зменшуватись, як і раніше, але навіть коли ми перезавантажили її вчора, я переживаю, що ця ж проблема скоро переслідує нас і, можливо, може відображатись деякі проблеми з нашим налаштуванням, ядром чи будь-яким іншим.
Коли ми пережили це, ми знаходимось на томах XFS, встановлених inode64, на архітектурних машинах x86_64. Зараз ми скопіювали близько 1,3 ТБ даних в об'єм XFS, ємність якого приблизно 4 ТБ, і ми повинні мати близько 3 ТБ даних у цьому томі, якщо повністю скопійовано. Об'єм створений заново, тому він був встановлений inode64 з самого початку, коли всередині даних не було, тому файлова система повинна бути чистою та рівномірно розподіленими.
Будь-які уявлення про те, що може бути причиною?
(ps насправді ми почали бачити це знову з кількох годин тому!)