Configuramos un sistema Linux (está en Amazon AWS, un sistema similar a CentOS, aunque no estamos exactamente seguros de las personalizaciones realizadas en él) con almacenamiento de 4TB como un volumen XFS sobre LVM (en última instancia, se utilizará para servir sobre NFS4, pero es aún no está en uso), y estamos en el proceso de usar rsync para sincronizar archivos de un servidor NFS de producción con el volumen XFS (es decir, rsync de una fuente a través de NFS a un volumen LVM basado en XFS montado localmente). Sin embargo, observamos que en algún momento en el medio rsync comenzó a volverse cada vez más lento (el rendimiento se redujo drásticamente) y tanto el promedio de carga como el consumo de memoria aumentaron en gran medida (y la CPU tiene una proporción muy grande en iowait). Finalmente, reinicié el sistema XFS y el sistema aparentemente volvió a la normalidad, con un rendimiento rsync más normal desde, al menos durante las últimas 24 horas.
Verificamos los gráficos de monitoreo de munin y no notamos nada obvio, pero descubrimos que el "Tamaño de la tabla de Inode" y las métricas de "inodo abierto" (verificaron la implementación del complemento munin que señala que los valores se leen desde / proc / sys / fs / inode-nr) siguió disminuyendo con el tiempo. Poco antes de observar que rsync se atascaba, observamos que ambas métricas se redujeron al valor de unos pocos miles de varios cientos de miles (nuestros servidores que no son XFS permanecen en aproximadamente 500k la mayor parte del tiempo y no muestran ninguna tendencia decreciente monotónica durante períodos prolongados ), y observamos registros del núcleo como estos:
inicio de sesión ip-XX-XXX-XXX-XXX: [395850.680006] hrtimer: la interrupción tomó 20000573 ns 18 de septiembre 17:19:58 kernel ip-XX-XXX-XXX-XXX: [395850.680006] hrtimer: la interrupción tomó 20000573 ns [400921.660046] INFORMACIÓN: tarea rsync: 7919 bloqueado durante más de 120 segundos. [400921.660066] "echo 0> / proc / sys / kernel / hung_task_timeout_secs" deshabilita este mensaje. [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] Rastreo de llamadas: [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] [] abajo + 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
También observamos un aumento drástico en la operación de "búsqueda" como se ve en el NFS de origen cuando eso sucedió, que anteriormente permaneció estable antes de que comenzáramos a experimentar el problema de rsync.
No hemos observado un comportamiento similar en nuestros volúmenes de producción que están basados en ext3 y, de hecho, aquellos con tamaños de volumen aún mayores. Además de la diferencia del sistema de archivos, los servidores de archivos están en una clase de máquina similar y se configuran de manera similar. Como descubrimos que las métricas de la tabla de inodo en el servidor XFS en este momento todavía están en una tendencia decreciente similar a nuestra observación anterior a pesar de que acabamos de reiniciarlo ayer, me preocupa que el mismo problema nos atormentará nuevamente pronto y es probable que refleje algunos problemas con nuestra configuración, kernel o lo que sea.
Cuando experimentamos esto, estamos en volúmenes XFS montados en inode64 en máquinas de arquitectura x86_64. En este momento, hemos copiado aproximadamente 1.3TB de datos en el volumen XFS cuya capacidad es de aproximadamente 4TB y deberíamos tener alrededor de 3TB de datos en ese volumen si está completamente copiado. El volumen se creó nuevamente, por lo que se montó en inode64 desde el principio cuando no había datos en el interior, por lo que el sistema de archivos debe estar limpio y los inodos distribuidos de manera uniforme.
¿Alguna idea de cuál podría ser la causa?
(PD, de hecho, ¡comenzamos a ver esto nuevamente desde hace unas horas!)