☰

COMMIT 절차에 결함이 있는 경우 NFS 쓰기 속도 저하

tag-icon • tag-icon nfs
COMMIT 절차에 결함이 있는 경우 NFS 쓰기 속도 저하

우선 뻔한 공부 질문을 올려서 죄송합니다. 이것이 나쁜 습관이라는 것은 알지만, 여기서도 도움을 받을 수 있기를 바랍니다. 엄청나게 조사했지만 이에 대한 답을 찾을 수 없었기 때문입니다.

그만큼대본NFS-클라이언트는 NFS-서버에 50GB의 단일 파일을 씁니다. 평균 속도 125MByte/s로 4GB를 쓴 후에는 12MByte/s로 떨어집니다.

질문: 그걸 어떻게 설명할 수 있나요?

그만큼주어진답변질문은 다음과 같습니다. 4GB 쓰기 후 서버는 COMMIT에 응답하지 않으며 클라이언트는 캐시를 비우기를 원하기 때문에 서버가 응답할 때까지 주기적으로 COMMIT를 보냅니다. 해당 기간 동안 데이터 속도는 가장 느린 요소 수준으로 떨어집니다.

COMMIT 프로세스에 대해 내가 찾을 수 있는 것은 다음과 같은 설명뿐입니다.

클라이언트는 데이터를 쓰고 데이터가 서버로 전송되면 COMMIT를 보냅니다. 서버는 안정적인 저장소에 데이터를 쓰고 verf-Cookie를 사용하여 COMMIT에 응답합니다. 쿠키가 클라이언트 쿠키와 다르지 않으면 클라이언트는 캐시를 비울 수 있습니다.

그래서 여기 있습니다내 질문: 서버가 verf-cookie를 전송하여 COMMIT-Procedure에 응답하지 않으면 클라이언트가 주기적으로 COMMIT를 전송하고 데이터 속도가 크게 떨어진다는 것이 사실입니까? 그렇다면 데이터 속도는 어느 수준까지 떨어지나요? 데이터 속도가 어느 정도 떨어지는지에 대한 답변으로는 결론을 내릴 수 없습니다.

답변1

나는 다음과 같은 일이 일어나고 있다고 생각합니다.

클라이언트가 보낸 데이터는 서버 측의 FS 캐시에 기록됩니다. COMMIT 요청이 전송되면 이 데이터는 영구 저장소(DISK)로 플러시되기 시작합니다. 서버의 디스크 성능에 따라 시간이 걸릴 수 있습니다. 디스크 성능이 300MB/s라고 가정해 보겠습니다. 4GB를 플러시하는 데 13초가 걸립니다. 이 시간이 NFS 시간 초과보다 길면 클라이언트는 첫 번째 COMMIT 요청이 손실되었다고 가정하여 또 다른 COMMIT 요청을 보낼 수 있습니다. COMMIT/WRITE 검증자는 이 작업 사이에 서버가 재부팅되지 않도록 하는 데 사용됩니다.

이러한 시나리오에서는 다음을 수행할 수 있습니다.

  • 다음을 지정하여 클라이언트의 NFS 시간 초과를 늘립니다.시간=마운트 옵션. 비록 이것이고치다COMMIT를 재시도했습니다.
  • 데이터 플러시를 충분히 일찍 시작하고 로그 지연을 방지하도록 서버에 지시합니다.

사용

sysctl -w vm.dirty_background_ratio=0
sysctl -w vm.dirty_ratio=0
sysctl -w vm.dirty_background_bytes=67108864
sysctl -w vm.dirty_bytes=536870912

크기는 서버 IO 성능 및 전체 네트워크에 따라 조정되어야 합니다.

커널이 서버의 디스크에 데이터를 플러시하기 시작하고 클라이언트 측의 서버로 보내는 시기를 제어합니다.

참고: 이 옵션은 전역적이며 모든 파일 시스템에 영향을 미칩니다.

관련 정보