저는 모든 엔지니어링 사용자가 사용하는 중대형 서버를 보유하고 있습니다. 이는 19개의 Xvnc 세션을 호스팅하는 32코어, 256GB 시스템이며 사용자 기반에는 수많은 도구, 로그인 세션 등이 포함됩니다. 모든 사용자는 NIS를 통해 구성되며 NFS에 홈 디렉터리가 있습니다. 또한 다양한 자동화 프로세스에서는 NIS 정의 사용자와 NFS 마운트 파일 시스템을 사용합니다.
컴퓨터는 CentOS 6.5를 실행 중이고 문제의 파일 서버는 NetApp입니다.
때때로 사람들은 컴퓨터를 한동안 실행한 후 특정 콘텐츠를 삭제하는 문제에 간헐적으로 직면합니다. 이 오류는 "장치/리소스 사용 중"과 유사합니다. lsof는 문제가 되는 항목(파일 또는 디렉터리)을 표시하지 않습니다. 일정 시간이 지나면(일반적으로 관리자를 찾아 문제를 확인하는 데 걸리는 시간보다 짧음) 문제가 사라지고 항목을 삭제할 수 있습니다.
같은 시기에 SVN을 사용하는 자동화된 프로세스 중 하나에서 다음 오류가 발생했습니다.
svn: E155009: Failed to run the WC DB work queue associated with '/home/local-user/tartarus/project8/doc/verif/verification_environment/learning/images', work item 930 (file-install doc/verif/verification_environment/learning/images/my-sequence.uml 1 0 1 1)
svn: E000018: Can't move '/home/local-user/tartarus/project8/.svn/tmp/svn-j3XrNq' to '/home/local-user/tartarus/project8/doc/verif/verification_environment/learning/images/my-sequence.uml': Invalid cross-device link
문제의 파일을 삭제하려고 하면 다음과 같은 결과가 나타납니다.
rm: cannot remove `project8/doc/verif/verification_environment/learning': Device or resource busy
"잘못된 교차 장치 링크"를 검색하면 svn 버전에 대해 많은 논의가 이루어지고 다른 장치에서 쓰기를 지원하지 않습니다. 이는 일반적으로 작동하고 버전 간 svn 저장소를 실행하지 않기 때문에 우리와 관련이 없습니다. 또는 .svn 디렉토리가 작업 복사본과 동일한 장치에 있기 때문에 장치 간 저장소입니다(nfs가 마운트됨).
컴퓨터를 다시 시작하면 몇 주 또는 몇 달 안에 문제가 사라질 수 있습니다. 제 경우에는 컴퓨터 가동 시간이 185일에 불과했습니다. 그러나 엔지니어들은 필요 이상으로 자주 세상을 다시 시작하는 데 열중하지 않습니다.
메인 시스템에서 문제가 발생하지 않는 한 다른 컴퓨터에서는 동일한 문제가 발생하지 않으므로 파일 서버를 원인으로 배제했습니다. 즉, 기본 시스템이 파일을 이동하거나 이름을 바꿀 수 없으면 파일을 이동하거나 이름을 바꿀 수 없다는 사실을 반복할 수 있지만 다른 컴퓨터에서는 이 동작을 독립적으로 나타내지 않습니다.
NFS 파일 시스템의 마운트 옵션은 다음과 같습니다.rw,intr,sloppy,addr=10.17.0.199
내 생각에 이것은 엔지니어가 실행 중인 누출로 인한 부작용이거나 임시 로드로 인한 버스트 등 어딘가에서 커널 값이 과도하게 채워진 것 같습니다.
한도는 25M 파일이고 이 컴퓨터의 최고 파일 수는 200K 미만이므로 열린 총 파일 수가 아닙니다.
내가 무엇을 찾고/찾아야 하는지 아는 사람 있나요?
답변1
짧은 대답: 로컬 NFS는 파일이나 디렉터리가 존재하지 않는다고 생각합니다. (네, 조금 회의적이었어요)
NFS는 오래된 기술입니다. 트래픽이 많고 빠르게 변화하는 파일에는 적합하지 않습니다. 동적 공유 파일 시스템의 경우 OCFS2(제가 가장 좋아하는) 또는 Gluster(음, Dark Side)와 같은 클러스터 솔루션을 사용해 보세요.
몇 년 전에 우리는 공통 NFS 설치를 갖춘 4개의 서버를 가지고 있었고, 서버 중 하나가 다른 서버가 볼 수 없는 파일을 생성한다는 것을 반복적으로 발견했습니다. 이 4개의 서버는 웹 애플리케이션 서버입니다. 사용자는 서버에서 패키지를 생성하고 완료 시 파일에 대한 NFS 경로를 사용하여 데이터베이스의 행을 업데이트하도록 하는 작업을 시작합니다. 사용자의 브라우저는 작업이 완료되었는지, 파일을 다운로드해야 하는지 확인하기 위해 10초마다 확인합니다. 문제가 발생하는 것을 볼 수 있습니다. 서버는 파일이 있는 데이터베이스의 행을 업데이트하지만 다른 서버는 사용자의 브라우저에서 요청을 받습니다. 즉, 파일을 읽고 "파일을 찾을 수 없음" 오류가 발생합니다.
말씀하신 대로 파일은 관리자가 볼 때 거기에 있습니다. 여러 엔지니어가 문제를 찾는 데 몇 주가 걸렸습니다. 기본적으로 데이터베이스에 표시된 마지막 생성된 파일 경로를 가져오고 해당 파일을 로그에 기록하는 10초 절전 루프를 실행합니다. 파일은 해당 파일을 생성한 시스템에서 항상 볼 수 있지만 다른 시스템에서는 일정 기간 동안 해당 파일을 볼 수 없습니다. 서버 부하가 증가하면 시간 간격이 길어집니다.
뾰족한 상사는 기본 NFS를 클러스터 파일 시스템으로 변경하는 것을 원하지 않았기 때문에 작업자 서버에 "그"가 데이터베이스에 파일을 생성한 사람이라는 것을 저장하도록 했습니다. 사용자의 요청은 작업이 완료되고 파일을 생성한 서버에 요청이 도달할 때까지 계속해서 재시도되므로 파일을 항상 읽을 수 있습니다. 네, 알아요. 결정적 시기. 그러나 그것은 오래된 기술을 유지하기로 결정했을 때 얻을 수 있는 것입니다. 일이 작동하려면 함께 뭉쳐야 합니다. 오래된 기술은 최초의 패치워크였고, 그에 관련된 모든 작업은 그저 패치워크에 불과했습니다. Max Headroom의 FS 선택으로 80년대로 돌아온 것을 환영합니다.
NFS에서는 모든 클라이언트가 모든 변경 사항을 실시간으로 동기화하는 것을 허용하지 않습니다. 따라서 한 클라이언트가 파일/디렉토리를 생성했는데 다른 클라이언트가 이를 볼 수 없거나, 한 클라이언트가 파일/디렉토리를 삭제했는데 다른 클라이언트가 그것이 여전히 거기에 있다고 생각하는 상황이 계속 발생합니다(사용을 시도할 때까지 - 죄송합니다).
우리는 파일 읽기를 시도하기 전에 시스템이 클라이언트 캐시를 재동기화하도록 다양한 트릭을 시도했습니다. 일어나지 않았습니다.
나의 조언: 당신의 FS를 금세기로 가져오십시오. (자속 커패시터 @88mph를 사용해 보십시오)
답변2
그냥 코멘트:
오류 E155009/ E000018기본 장치 간 이동에도 작동합니다.
svn: E155009: Failed to run the WC DB work queue associated with '/first-device/mounted-device', work item 1219 (file-install /first-device/mounted-device/file-to-move-to 1 0 1 1)
svn: E000018: Can't move '/first-device/.svn/tmp/svn-v2KRIt' to '/first-device/mounted-device/file-to-move-to': Invalid cross-device link
따라서 이는 NFS에만 국한되지 않습니다.