LVM üzerinde XFS birimi olarak (sonuçta NFS4 üzerinden hizmet için kullanılacak) 4 TB depolama alanlı bir Linux (bu, üzerinde yapılan özelleştirmelerden tam olarak emin olmadığımız bir CentOS benzeri sistem olan Amazon AWS'de) kurduk, ancak henüz kullanımda değil) ve biz, üretim NFS sunucumuzdaki dosyaları XFS birimine senkronize etmek için rsync kullanma sürecindeyiz (yani NFS üzerindeki bir kaynaktan yerel olarak monte edilmiş bir XFS tabanlı LVM birimine rsync). Bununla birlikte, orta rsync'in bir noktasında giderek durgunlaşmaya başladığını (verim keskin bir şekilde azaldı) ve hem yük ortalaması hem de bellek tüketiminin büyük ölçüde arttığını (ve CPU'nun iowait'te çok büyük bir orana sahip olduğunu) gözlemledik. Sonunda XFS sistemini yeniden başlattım ve sistem en azından son 24 saat boyunca daha normal rsync performansıyla normale döndü.
Munin izleme grafiklerini kontrol ettik ve belirgin bir şey fark etmedik, ancak "Inode tablo boyutu" ve "açık inode" metriklerinin (/ proc / sys / 'den okunan değerlere işaret eden munin eklenti uygulamasını kontrol ettik. fs / inode-nr) zaman içinde azalmaya devam etti. Rsync'in takıldığını gözlemlemeden kısa bir süre önce, her iki metriğin de birkaç yüz binden birkaç bin değerine düştüğünü gözlemledik (XFS olmayan sunucularımız çoğu zaman yaklaşık 500 bin kalır ve uzun süreler boyunca herhangi bir monotonik azalma eğilimi göstermez ), ve çekirdekten günlükleri şöyle gözlemledik:
ip-XX-XXX-XXX-XXX giriş: [395850.680006] hrtimer: kesinti 20000573 ns aldı Eyl 18 17:19:58 ip-XX-XXX-XXX-XXX çekirdek: [395850.680006] hrtimer: kesinti 20000573 ns aldı [400921.660046] BİLGİ: görev rsync: 7919 120 saniyeden fazla engellendi. [400921.660066] "echo 0> / proc / sys / kernel / hung_task_timeout_secs" bu mesajı devre dışı bırakır. [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] Çağrı İzleme: [400921.660202] [] program_zaman aşımı + 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] [] aşağı + 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
Ayrıca, söz konusu rsync sorununu yaşamaya başlamadan önce daha önce sabit kalan, kaynak NFS'de görüldüğü gibi "arama" operasyonunda ciddi bir artış gözlemledik.
Üretim hacimlerimizde ext3 tabanlı ve aslında daha büyük hacim boyutlarında olan benzer davranışlar gözlemlemedik. Dosya sistemi farkı dışında, dosya sunucuları benzer makine sınıfındadır ve benzer şekilde kurulur. XFS sunucusundaki inode tablo metriklerinin, dün yeniden başlatmış olsak da, önceki gözlemimize benzer şekilde hala azalan trendde olduğunu tespit ettiğimiz gibi, aynı sorunun yakında bizi tekrar rahatsız edeceğinden endişe ediyorum ve muhtemelen yansıtabilir kurulumumuz, çekirdeğimiz veya her neyse bazı sorunlar.
Bunu deneyimlediğimizde, x86_64 mimari makinelerde inode64 monteli XFS birimlerindeyiz. Şu anda kapasitesi yaklaşık 4 TB olan XFS birimine yaklaşık 1.3 TB veri kopyaladık ve tam olarak kopyalandıysa bu birimde yaklaşık 3 TB veriye sahip olmalıyız. Birim yeniden oluşturuldu, bu nedenle içeride veri olmadığı zamandan beri inode64'e monte edildi, bu nedenle dosya sistemi temiz olmalı ve inodelar eşit olarak dağıtılmalıdır.
Sebebin ne olduğuna dair herhangi bir görüş var mı?
(ps aslında birkaç saat önce bunu tekrar görmeye başladık!)