Мы настраиваем систему Linux (она находится на Amazon AWS, системе, подобной CentOS, хотя мы не совсем уверены в том, какие настройки были сделаны на ней) с хранилищем 4 ТБ в качестве тома XFS через LVM (в конечном итоге для обслуживания через NFS4, но это еще не используется), и мы находимся в процессе использования rsync для синхронизации файлов с нашего производственного сервера NFS с томом XFS (т. е. мы выполняем rsync от источника через NFS к локально смонтированному тому LVM на основе XFS). Однако мы заметили, что в какой-то момент в середине rsync начал становиться все более вялым (резко снизилась пропускная способность), и как средняя нагрузка, так и потребление памяти выросли в значительной степени (а ЦП имеет очень большую долю в iowait). В конце концов я перезагрузил систему XFS, и система, очевидно, вернулась в нормальное состояние, с более нормальной производительностью rsync с тех пор, по крайней мере, в течение последних 24 часов.
Мы проверили графики мониторинга munin и не заметили ничего очевидного, но мы обнаружили, что метрики «Размер таблицы индексных дескрипторов» и «открытый индексный дескриптор» (проверили реализацию плагина munin, которая указывает на значения, считываемые из / proc / sys / fs / inode-nr) со временем уменьшалась. Незадолго до того, как мы заметили, что rsync зависает, мы заметили, что оба показателя упали до нескольких тысяч с нескольких сотен тысяч (наши серверы без XFS большую часть времени остаются примерно на 500 КБ и не демонстрируют какой-либо монотонной тенденции к снижению в течение длительных периодов времени. ), и мы наблюдали такие журналы из ядра:
ip-XX-XXX-XXX-XXX login: [395850.680006] hrtimer: interrupt took 20000573 ns Sep 18 17:19:58 ip-XX-XXX-XXX-XXX kernel: [395850.680006] hrtimer: interrupt took 20000573 ns [400921.660046] INFO: task rsync:7919 blocked for more than 120 seconds. [400921.660066] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. [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] Call Trace: [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
Когда это произошло, мы также наблюдали резкое увеличение числа операций «поиска» в исходной NFS, которые ранее оставались стабильными до того, как мы начали сталкиваться с указанной проблемой rsync.
Мы не наблюдали подобного поведения в наших объемах производства, основанных на ext3, а на самом деле это были еще большие объемы. Помимо разницы в файловой системе, файловые серверы относятся к аналогичному классу машин и настраиваются аналогичным образом. Поскольку мы обнаружили, что показатели таблицы индексных дескрипторов на сервере XFS только сейчас все еще имеют тенденцию к снижению, аналогичную нашим предыдущим наблюдениям, даже несмотря на то, что мы только что перезагрузили его вчера, я обеспокоен, что та же проблема вскоре снова будет преследовать нас и, вероятно, отразится некоторые проблемы с нашей установкой, ядром или чем-то еще.
Когда мы столкнулись с этим, мы работали с томами XFS, смонтированными в inode64, на машинах с архитектурой x86_64. Прямо сейчас мы скопировали около 1,3 ТБ данных на том XFS, емкость которого составляет примерно 4 ТБ, и у нас должно быть около 3 ТБ данных в этом томе при полном копировании. Том был создан заново, поэтому он был смонтирован с самого начала, когда внутри не было данных, поэтому файловая система должна быть чистой, а индексы распределены равномерно.
Есть идеи относительно того, что может быть причиной?
(p.s. на самом деле мы начали видеть это снова несколько часов назад!)
polynomial, и AndreasM сказал, что естественно приходит в голову: это похоже на сбой, у вас недостаточно памяти.
Rsync собирает список файлов для передачи на 1-м проходе, и 1 / переход по большой иерархии через NFS медленный (локальный lstat() переводится как удаленный NFS getattr медленные и не кэшируемые, поскольку вы проходите только один раз), 2 / эта проблема зависит от количества inodes (используйте df -i), а не от общего объема данных для передачи.
Обратите внимание, что использование rsync -H|--hard-links еще дороже, rsync должен построить полные хеш-таблицы всех inode, чтобы найти дубликаты.
Попробуйте использовать rsync прямо из файловой системы, экспортированной сервером NFS, в обход NFS. В зависимости от вашей задержки NFS это может быть хорошим приростом.
В некоторых крайних случаях, когда обход большой коллекции inodes на самом деле был дороже простого копирования данных, я использовал что-то вроде ssh source 'tar -cC /path/to/src .' | tar -xC /path/to/dest это простая потоковая копия с постоянным использованием памяти. В зависимости от настроек вашего процессора и сети добавление сжатия может ускорить всю операцию - или нет (добавить -z при обоих вызовах tar).
Включение XFS отложенное ведение журнала (delaylog опция mount) может помочь (см. http://en.wikipedia.org/wiki/XFS#Disadvantages). CentOS известен (не) тем, что использует исправленное ядро, поэтому может потребоваться обновление ядра.