10Gb 네트워크에서 NFS v4.2를 통해 서버에 최종적으로 복사되는 데이터(100GB 파일)를 생성하고 있습니다. 이러한 파일은 XFS 형식으로 여러 HDD에 저장됩니다(대상 드라이브당 복사본 1개).
복사 작업이 실행 중일 때:
- 클라이언트의 메모리 사용량이 엄청납니다.(64GB 이상일 수 있으며 가능한 많은 메모리를 차지합니다.)
- 그러나 서버에서는 RAM이 거의 사용되지 않습니다.
클라이언트가 지속적으로 데이터를 생성하고 속도가 느려지므로 클라이언트의 메모리 사용량을 줄이고 싶습니다. 반대로 서버는 주로 사용되지 않습니다.
서버에서 HDD가 느려지기 때문에 클라이언트는 복사본이 덜 차단되도록 최대한 많은 데이터를 버퍼링합니다. 하드웨어 설정을 변경할 수 없습니다.
서버가 더 많은 데이터를 캐시하도록 강제할 수 있는 방법이 있습니까? 나는 클라이언트 메모리보다는 서버 메모리를 우선적으로 사용하고 싶습니다.
NFS 구성:
10.0.3.1:/ /mnt/field nfs nfsvers=4.2,noatime,nodiratime,_netdev,noauto,x-systemd.automount,x-systemd.mount-timeout=10 0 0
/etc/exports:
/mnt 10.0.0.0/16(rw,async,fsid=0,no_subtree_check,crossmnt)
서버의 Nic 구성:
MTU 9000
rinbuffer tx 512, rx 1024
클라이언트의 Nic 구성:
MTU 9000
rinbuffer tx 1024, rx 512
편집하다: 요청에 따라 /proc/meminfo:
클라이언트 서버 ------ ------------
이 클라이언트의 메모리 사용량에 대한 모니터링:
네트워크 사용량:
참고: 클라이언트는 계산을 위해 큰 tmpfs(100GB)를 사용합니다. 나는 이 tmpfs가 사용 가능한 메모리 수에서 결코 차감되지 않는다고 생각합니다.
편집2:
네트워크와 메모리 사용량 사이의 상관 관계는 다른 클라이언트에서 더 분명합니다(그때부터 시작했어야 했습니다). 이 클라이언트는 tmpfs를 사용하지 않습니다.
답변1
클라이언트가 지속적으로 데이터를 생성하고 속도가 느려지므로 클라이언트의 메모리 사용량을 줄이고 싶습니다.
이것을 어떻게 알 수 있나요? 대부분의 클라이언트 메모리는 페이지 캐시에 있으며 이는 완전히 정상적인 현상이며 서버의 버퍼링을 개선하더라도 이 데이터 클라이언트 측의 공격적인 캐싱을 방지할 수는 없습니다.
테스트로 페이지 캐시를 플러시하고 페이지 캐시 사용 없이 애플리케이션이 어떻게 작동하는지 확인해 보셨나요?
NFS에는 '개방에 가까운' 일관성이 있습니다. 즉, 파일을 적극적으로 열지 않은 경우에만 데이터와 메타데이터의 내용이 실제로 안정적이라는 것을 보장합니다(즉, 다른 클라이언트가 다른 클라이언트에서 파일을 변경할 수 있음). 시스템과 당신은 더 현명하지 않을 것입니다).
이러한 일관성 제한으로 인해 NFS 클라이언트 시스템 애플리케이션은 필요할 경우 데이터를 다시 읽을 수 있도록 하기 위해 페이지 캐시에 의존합니다.
/etc/exports더 많은 데이터를 서버에 오프로드하는 한 가지 방법 에서 무슨 일이 일어나고 있는지 알지 못한 채 sync마운트 옵션을 사용하여 클라이언트에 NFS를 마운트하고 서버에서 async마운트 옵션을 사용하여 경로를 내보내는 것일 수 있습니다.
이는 쓰기가 클라이언트 측 서버에 커밋되도록 하는 효과가 있으며, 서버는 데이터를 디스크에 커밋하기 전에 항상 '완료'라고 응답합니다.
클라이언트 측에서 모든 요청의 유효성을 검사하기 때문에 대기 시간이 발생하므로 클라이언트 처리량에 영향을 주지만, 서버는 데이터가 디스크에 먼저 도착할 때까지 기다리지 않으므로 훨씬 더 많은 데이터를 버퍼링합니다. 또한 dirty_write_centisecs쓰기 저장에 더 많은 데이터를 버퍼링할 수 있도록 서버의 비트와 기타 비트를 조정하고 싶을 수도 있습니다 .
문제는 여기에 있습니다. 이로 인해 충돌이 발생할 경우 클라이언트 속도가 느려지고 서버 무결성이 저하될 수 있습니다. 서버가 충돌하면 데이터가 손실될 수 있습니다.
또한 이는 NFS가 실제로 제어할 수 없는 클라이언트의 페이지 캐시에 대한 메모리 사용량에 영향을 미치지 않습니다.
전체적으로 나는 클라이언트 메모리 사용량(여기서 측정하고 있는 페이지 캐시인 경우)을 줄이는 것이 클라이언트 성능을 향상시킬 수 있을지 회의적입니다.
답변2
아니요, 더 적은 메모리를 강제로 사용하면 속도가 빨라지는 것이 아니라 속도가 느려질 가능성이 높습니다. 이미 188GB의 고속 DRAM에 전력을 소비하고 있으므로 이를 사용하는 것이 좋습니다.
클라이언트 호스트에는 188GB의 MemTotal이 있고 그 중 162GB를 캐시에 사용하고 있습니다. 실제로 메모리 요구량이 매우 낮습니다. 매우 빠르게 해제할 수 있는 123GB MemAvailable을 참고하세요. Shmem의 40GB 중 대부분은 아마도 tmpfs일 것입니다.
Cached + Shmem이 MemTotal보다 더 많아지기 때문에 tmpfs가 공유 메모리와 캐시에서 두 번 계산되는 것 같습니다. 또한 Cached에서 Shmem을 뺀 값이 대략 MemAvailable인 방법을 설명합니다. 영구 저장소가 부족한 tmpfs는 해제할 수 없습니다.
서버 측, 15GB 및 캐시된 MemTotal, 13GB를 변경합니다. 이 호스트에 사용 가능한 메모리가 많습니다. 아마도 수행하는 작업의 대부분은 파일을 제공하는 것이지 메모리를 많이 요구하지는 않습니다.
다음과 같은 간접비 증거 없이과도한 vmscan 활동또는 MemAvailable이 부족하면 조치를 취하지 않는 것이 좋습니다.