현재 스크립트는 NFS를 통해 여러 파일을 생성하고 삭제합니다. 이것이 문제라고 해서 스크립트가 실행된 디렉터리가 NFS용 단일 파일처럼 보이면 문제를 완화할 수 있지 않을까 생각했습니다.
수백 개의 스크립트가 자체 실행 디렉터리에서 작동하지만 NFS에서는 언제든지 실행되고 각 실행 디렉터리에 대해 수십 개의 파일이 생성 및 삭제되므로 병목 현상이 발생합니다.
나는 그 이후로 발견했다http://code.google.com/p/fuse-zip/내가 조사해 볼게요. 누구나 자신의 경험을 공유할 수 있나요?
답변1
글쎄, 댓글을 보면 다음 제안 중 하나에 해당하는 것 같습니다.
상대적으로 적은 디스크 공간을 차지하는 임시 파일 묶음을 생성 및 삭제하고 있습니다.
권장 사항: 로컬 컴퓨터 어딘가에 tmpfs를 설치하고 사용하세요. (어쨌든 이미 /tmp 아래에 하나가 있을 것입니다)
대부분은 임시 파일이지만 보관해야 할 파일도 몇 개 있습니다.
권장 사항: tmpfs를 다시 사용하세요. 하지만 최종적으로 tmpfs를 마운트 해제하기 전에(따라서 내용이 손실됨) 필요한 파일 몇 개를 복사하세요.
일시적이지만 사소하지는 않습니다.
권장 사항: 로컬 저장소.
동시에 여러 컴퓨터에서 이러한 작은 파일에 액세스해야 합니다.
권장 사항: 더 강력한 NFS 서버 및/또는 네트워크. 이 로드 전용 NFS 서버. 분산 파일 시스템.
귀하의 질문에 대한 접근 방식이 최선의 아이디어인 시나리오를 생각하는 데 어려움을 겪고 있습니다. 하지만 정말 하고 싶다면...
권장 사항: NFS 서버에 단일 파일을 생성하십시오. losstup을 사용하여 루프 장치에 매핑한 다음 mkfs를 사용하여 마운트합니다. (사용 중인 파일 시스템에 따라 파일을 직접 mkfs할 수 있습니다. 예를 들어 mke2fs에서 작동합니다.) 아마도 async 플래그(또는 유사한 플래그)를 사용하여 설치하십시오. 이것은 zip 파일보다 훨씬 더 나은 성능을 발휘합니다.
제가 주목해야 할 또 다른 점은 이러한 모든 임시 파일을 생성하고 삭제하는 목적에 따라 파일이 최선의 접근 방식이 아닐 수도 있다는 것입니다. 예를 들어, 일종의 데이터베이스의 행이어야 할 수도 있습니다.