LVM을 통한 XFS 볼륨으로 4TB 스토리지를 갖춘 Linux (CentOS와 유사한 시스템 인 Amazon AWS, CentOS와 유사한 시스템)에 Linux를 설정했습니다 (최종 NFS4를 지원하는 데 사용됨). rsync를 사용하여 파일을 프로덕션 NFS 서버에서 XFS 볼륨으로 동기화하는 과정에 있습니다 (즉, NFS를 통한 소스에서 로컬로 마운트 된 XFS 기반 LVM 볼륨으로 rsync). 그러나 중간 rsync의 어느 시점에서 점점 더 느려지기 시작하고 (처리량이 급격히 감소 함)로드 평균과 메모리 소비가 크게 증가했습니다 (그리고 CPU는 iowait에서 매우 큰 비중을 차지함). 결국 나는 XFS 시스템을 재부팅했고 적어도 지난 24 시간 동안보다 정상적인 rsync 성능으로 시스템이 정상으로 재개되었습니다.
우리는 munin 모니터링 그래프를 점검했지만 분명한 것을 발견하지 못했지만 "Inode table size"및 "open inode"메트릭 (/ proc / sys /에서 읽은 값을 가리키는 munin 플러그인 구현을 확인 함)을 발견했습니다. fs / inode-nr)은 시간이 지남에 따라 계속 감소합니다. rsync가 중단되는 것을 관찰하기 직전에 두 메트릭이 수십만에서 수천에 달하는 것으로 나타났습니다 (XFS 이외의 서버는 대부분 약 500k를 유지하며 장기간에 걸쳐 단조로운 감소 추세를 보이지 않습니다) ), 커널에서 다음과 같은 로그를 관찰했습니다.
ip-XX-XXX-XXX-XXX 로그인 : [395850.680006] hrtimer : 인터럽트 소요 20000573 ns 9 월 18 일 17:19:58 ip-XX-XXX-XXX-XXX 커널 : [395850.680006] hrtimer : 인터럽트에 20000573ns 소요 [400921.660046] 정보 : 작업 rsync : 7919가 120 초 이상 차단되었습니다. [400921.660066] "echo 0> / proc / sys / kernel / hung_task_timeout_secs"는이 메시지를 비활성화합니다. [400921.660077] rsync D ffff880002fe4240 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 기반의 프로덕션 볼륨에서 비슷한 동작을 관찰하지 않았으며 실제로는 더 큰 볼륨 크기를 사용했습니다. 파일 시스템 차이점 외에 파일 서버는 유사한 시스템 클래스에 있으며 유사한 방식으로 설정됩니다. 어제 재부팅 한 경우에도 XFS 서버의 inode 테이블 메트릭이 이전 관측치와 비슷한 추세로 여전히 감소하고 있음을 알았으므로 동일한 문제로 인해 곧 다시 문제가 발생할 수 있습니다. 설정, 커널 또는 기타 문제가 있습니다.
우리는 이것을 경험했을 때 x86_64 아키텍처 시스템에서 inode64 마운트 XFS 볼륨을 사용하고 있습니다. 현재 용량이 약 4TB 인 XFS 볼륨에 약 1.3TB의 데이터를 복사했으며 완전히 복사 된 경우 해당 볼륨에 약 3TB의 데이터가 있어야합니다. 볼륨이 새로 생성되었으므로 내부에 데이터가 없을 때 처음부터 inode64로 마운트되었으므로 파일 시스템이 깨끗하고 inode가 고르게 분산되어야합니다.
원인이 무엇인지에 대한 통찰력이 있습니까?
(실제로 우리는 몇 시간 전부터 이것을 다시보기 시작했습니다!)