async저는 NetApp NFS(v3 프로토콜) 서버가 fsync모드에서 클라이언트 요청을 올바르게 처리하고 있는지 확인하기 위해 몇 가지 자세한 테스트를 수행해 왔습니다 . Linux(RHEL 6, 커널 2.6.32-431.5.1)가 COMMIT 작업을 전혀 실행하지 않는다는 사실을 발견했을 때 문제가 발생했습니다! 이 nfsstat도구를 사용하여nfstrace 도구. 커밋이 없습니다.
이거 위반인거 같은데NFS 의미론:
버전 3 클라이언트는 close(2) 또는 fsync(2) 시스템 호출 중에 서버에 안전한 비동기 쓰기를 플러시할 때 또는 메모리 부족이 발생할 때 COMMIT 작업을 사용합니다.
무슨 일이야?
노트:
마운트 지점은 비동기 작업을 통해 마운트되어야 합니다(기본값).
fsync 요청을 생성하기 위해 Postgresql의 도구를 사용했습니다 test_fsync. 시스템에 가장 적합한 방법을 결정할 수 있도록 여러 가지 방법을 사용하여 기준 동기화 및 보고를 게시합니다.
타이밍 차이는 마운트 test_fsync에서보다 마운트에서 fsync 함수를 실행하는 데 시간이 더 오래 걸린다는 것을 나타냅니다. 아마도 마운트가 마운트되는 동안 데이터가 항상 새로 고쳐지고 호출될 때만 새로 고쳐지기 때문일 것입니다. 그러나 타이밍 차이가 매우 불안정하여 성능이 과도하게 나타나는 것일 수도 있습니다.asyncsyncsyncfsync
이 옵션을 사용하여 서버를 설치해도 sync아무 것도 변경되지 않습니다.
업데이트: 줄거리가 더욱 복잡해집니다.
Ubuntu/Mint 17, Linux 커널 3.13.0(nfs 버전: 1.2.8)에서 동기화 및 비동기 옵션을 모두 사용하여 루프백 마운트 지점을 설정하고 테스트를 다시 실행했습니다. 속도 차이는 확실히 동기와 비동기의 차이를 나타냅니다. nfsstat각 실행 후에 pg_fsync_test정확히1커밋이 발생했습니다.
도대체 뭐야?
답변1
동료가 가능한 답을 찾았습니다.
Netapp 기술 보고서 tr-3183(NFS를 통해 NetApp 스토리지와 함께 Red Hat 클라이언트 사용)에서는 다음과 같이 설명합니다.
Data ONTAP의 NFS 서버는 클라이언트가 UNSTABLE, DATA_SYNC 또는 FILE_SYNC 쓰기를 요청하는지 여부에 관계없이 모든 쓰기 요청을 FILE_SYNC로 승격합니다. 따라서 모든 쓰기가 NVRAM에 기록되고 클라이언트가 쓰기에 대한 즉시 승인을 받기 때문에 클라이언트는 NetApp 스토리지에 쓸 때 COMMIT 요청을 보낼 필요가 없습니다. 따라서 NetApp 스토리지에 대한 쓰기는 본질적으로 비동기식이며 훨씬 빠릅니다.