NFS 서버가 클라이언트에 응답하지 않음 - 프로세스 'migration' 및 'xfssyncd'가 비정상적인 CPU를 소비함

NFS 서버가 클라이언트에 응답하지 않음 - 프로세스 'migration' 및 'xfssyncd'가 비정상적인 CPU를 소비함

저는 몇 가지 XFS 파일 시스템을 제공하는 NFS 4를 실행하는 CentOS 6.4 파일 서버를 가지고 있습니다. 수십 개의 클라이언트가 연결되어 있습니다. 오늘은 클라이언트에 대한 크롤링 속도가 느려졌습니다. 클라이언트는 서버에서 마운트된 NFS 공유에 액세스할 때 몇 분 후에 응답하거나 응답합니다. 서버 자체에서는 문제 없이 공유 파일 시스템에 액세스할 수 있었습니다. 문제는 약 4시간 후에 사라졌지만 이유는 모르겠습니다. 아래를 참조하세요.

top몇 초마다 0%에서 최대 100%까지 점프하면서 비정상적인 양의 CPU를 소비하는 여러 migration프로세스와 프로세스를 보여주었습니다. xfssyncd다른 프로세스는 눈에 띄게 활성화되지 않았습니다. top에서 보고한 전체 CPU 사용량은 다음과 같이 낮았습니다.

Cpu(s): 0.0%us, 4.2%sy, 0.0%ni, 95.8%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st

특히 구독자 전용 섹션에 있는 RHEL 지원 항목을 제외하고는 온라인에서 이에 대해 이야기하는 내용을 찾을 수 없었습니다.

나는 달렸다 service nfs restart. 그런 service nfs status다음 nfsd dead but subsys locked. 다시 시작한 후에는 이 문제가 사라지고 nfsd가 실행 중이었지만 클라이언트는 여전히 중단되었습니다.

xfssyncd 관련 문제에 대해 제안된 몇 가지 작업을 시도했습니다.

1) mount –o remount /mnt/data내 보낸 fs에서. 흥미롭게도 이 명령을 실행하는 데 약 1분이 걸렸으며 이 시간 동안 '야생' 프로세스가 안정되었습니다. 그러나 명령 실행이 완료되면 프로세스의 CPU 사용량이 다시 높아졌습니다.

2) echo 720000 > /proc/sys/fs/xfs/xfssyncd_centisecsxfssyncd의 동기화 간격을 변경하기 위해. 이것은 눈에 띄는 차이를 만들지 않았습니다. fs가 NFS 클라이언트로 바쁘고 문제가 다른 것일 것이기 때문에 그리 놀라운 것은 아닙니다.

3주 전에 이 서버에 문제가 있었습니다. .nfsNNN 파일(제거된 파일의 경우 여전히 열려 있고 액세스 중임)이 클라이언트에 반복 오류 메시지와 함께 빠르게 채워지는 문제가 있었습니다. 문제 프로세스를 종료하면 NFS 속도 저하가 해결되었습니다. [그러나 그런 .nfsNNN 파일 문제 없이 며칠 후 파일 서버가 다시 느려지기 시작했고 결국 재부팅해야 했습니다. 당시 CPU 수준이 비정상적인 일부 프로세스를 보았지만 그것이 무엇인지 기록하지 않았으며 현재 문제와 동일한지 지금은 기억할 수 없습니다.]

오늘 문제가 될 수 있는 열린 .nfsNNN 파일을 다시 검색했지만 아무 것도 발견하지 못했습니다. 몇 달 전에 일부를 삭제했지만 현재는 수정되지 않아서 문제가 아닌 것으로 생각했습니다. 이 파일을 삭제한 후에도 아무런 차이가 없습니다.

위의 다양한 작업을 시도한 후 약 한 시간 후에 서버가 정상으로 돌아왔고 및 migration프로세스 xfssyncd의 CPU 사용량이 더 이상 높지 않았습니다. 무엇이 바뀌었는지는 모르겠지만, 이런 일이 다시 일어날 수 있을 것 같으니 미리 알아내려고 노력하고 싶습니다.

어떤 제안이라도 보내주셔서 감사합니다.

-중

답변1

비슷한 문제가 있는 RHEL 6.10이 있습니다. 도움이 되는 유일한 방법은 NFS 클라이언트에서 오랫동안 실행되는 사용자 sftp 프로세스를 종료하는 것입니다. 이는 GUI 기반 SFTP 클라이언트(예: WinSCP, Nimble Commander)에 의해 여러 시간(> 10시간) 동안 열려 있는 프로세스였습니다.

모니터링에는 문제와 일치하는 일부 NFSv3 클라이언트 활동이 표시되지만 실제로 활동은 문제를 일으키지 않는 다른 클라이언트(100개 이상의 클라이언트가 있음)의 다른 일반적인 활동보다 낮습니다.

실제로 I/O도 많이 수행되지 않습니다.

업데이트 2019-12-10: 근본 원인은 NFS 서버의 XFS 할당량인 것 같습니다. 사용자 홈 디렉터리에는 하드 제한보다 2GB 낮은 소프트 제한이 적용되는 할당량이 있습니다. 일부 사용자는 소프트 제한을 초과하여 전체 Anaconda Python을 설치하려고 했습니다. Anaconda 설치 프로그램은 경고를 가로챌 수 있는 방법이 없는 것 같았고 소프트 제한을 초과하여 계속 파일을 다운로드했습니다. 이로 인해 엄청난 양의 할당량 경고가 발생하여 시스템이 완전히 중단되고 응답하지 않게 되었습니다.

제가 "~인 것 같다"고 말한 이유는 증거가 정황에 근거하기 때문입니다. 사용자가 할당량 없이 디렉터리에 설치를 시도했을 때 모든 것이 잘 진행되었습니다.

관련 정보