Таблицы Inode сжимаются со временем, вызывая проблемы с Rsync / Inode

Мы настраиваем систему Linux (она работает на Amazon AWS, CentOS-подобной системе, хотя мы не совсем уверены в том, что настройки выполнены на ней) с хранилищем объемом 4 ТБ в качестве тома XFS через LVM (в конечном счете, для обслуживания через NFS4, но это еще не используется), и мы находимся в процессе использования rsync для синхронизации файлов с нашего производственного NFS-сервера на том XFS (т. е. мы rsync из источника через NFS на локально смонтированный том LVM на основе XFS). Тем не менее, мы заметили, что в какой-то момент в середине rsync начал становиться все более вялым (пропускная способность резко снижалась), и средняя загрузка, и потребление памяти возросли в значительной степени (и у CPU очень большая доля в iowait). В конце концов я перезагрузил систему XFS, и система, по-видимому, вернулась к нормальной работе с более нормальной производительностью rsync, по крайней мере, в течение последних 24 часов.

Мы проверили графики мониторинга munin и не заметили ничего очевидного, но обнаружили, что метрики "Размер таблицы Inode" и "open 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] [] 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] [] вниз + 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 на самом деле мы начали видеть это еще несколько часов назад!)

Может помочь включение отложенной регистрации в XFS ( delaylogопция монтирования) (см. Http://en.wikipedia.org/wiki/XFS#Disadvantages ). CentOS славится тем, что использует исправленное ядро, поэтому может потребоваться обновление ядра.

polynomial и AndreasM сказали то, что естественно приходит на ум: похоже, это бьющая ситуация, вам не хватило памяти.

Rsync собирает список файлов для передачи в 1-й проход, и 1 / обход большой иерархии по NFS медленен (локальный lstat()перевод как удаленный NFS getattrмедленен и не кэшируется, поскольку вы проходите только один раз), 2 / эта проблема зависит от количество inode (использовать df -i), а не общее количество данных для передачи.

Обратите внимание, что использование rsync -H|--hard-linksеще дороже, rsync должен создать полные хеш-таблицы всех inode, чтобы найти дубликаты.

Попробуйте использовать rsync прямо из файловой системы, экспортируемой NFS-сервером, в обход NFS. В зависимости от вашей задержки NFS, это может быть хорошим стимулом.

В некоторых крайних случаях, когда обход большой коллекции inode на самом деле обходился дороже, чем простое копирование данных, я использовал что-то вроде ssh source 'tar -cC /path/to/src .' | tar -xC /path/to/destпростой потоковой копии с постоянным использованием памяти. В зависимости от настроек вашего ЦП + сети добавление сжатия может ускорить всю операцию - или нет (добавьте -zоба вызова tar).