우리는 isilon 클러스터에서 nfs를 실행하고 있으며 한 컴퓨터에서 디렉터리를 생성하고 다른 컴퓨터에서 읽을 때(약 30초) 간헐적으로 상당한 지연을 경험하고 있습니다.
이는 네트워크가 매우 바쁜 경우에만 발생하는 것으로 보이지만 새 디렉토리를 읽으려고 시도하기 전에 상위 디렉토리에서 'ls'를 실행하면 NFS가 다시 캐시되도록 하는 것이 제안되었습니다.
그 말이 맞는 것 같나요?
답변1
디렉토리 정보의 캐시 수명에 대한 상한 및 하한을 변경하려면 클라이언트에서 acdirmin/acdirmax 마운트 옵션을 조정해야 할 것 같습니다. 이 30초는 기본 acdirmin인 30초에 해당합니다. 즉, 클라이언트가 정보를 내보내고 새로 고치는 것을 고려하려면 최소한 30초 전에 정보가 캐시에 있어야 함을 의미합니다.
acdirmin을 15~10초로 조정하는 것이 도움이 되는지 확인하세요.
또한 'ls'가 도움이 될 수 있는 이유는 "."에서 stat()가 발생하기 때문입니다. 잠재적으로 해당 dentry에 대한 캐시를 무효화할 수 있습니다. 항목이 일부 NFS 항목에 있는지 확인하기 위해 open() 전에 파일이나 디렉터리를 stat()하도록 일부 도구를 수정해야 했던 기억이 납니다.
답변2
그렇다면 이것은 파일이 생성되었다는 것을 다른 클라이언트가 알아차리는 것입니까? (또는 파일에 포함된 데이터 양의 변경 사항이 포함됩니까?)
Isilon은 단일 디렉터리의 메타데이터 성능에 문제가 있으므로 작업이 모두 단일 디렉터리에 있습니까?
캐시를 수행하는 파일을 작성하는 서버가 아닌 것이 확실합니까? isilon에 로그인하고 "어플라이언스"에서 디렉터리를 보면 클라이언트가 말한 것과 동시에 서버에 나타나는 파일을 볼 수 있습니까? 그것을 썼다.
흥미로운 점은 두 대의 기계가 동일한 아이실론 벽돌을 장착하고 있다는 점입니다(중요하지는 않지만 흥미로울 것입니다).
어떤 마운트 옵션이 있습니까? ( nfs v2가 어떤 차이를 만들까요(더 궁금합니다. readir+가 없습니다))