우리 애플리케이션의 잠재적인 병목 현상을 추적하는 데 도움이 되도록 NFS 서버를 분석하고 싶습니다. 서버가 SUSE Enterprise Linux 10을 실행 중입니다.
내가 알고 싶은 것들은 다음과 같습니다:
- 어떤 클라이언트가 어떤 파일에 액세스하고 있는지
- 클라이언트별 읽기/쓰기 처리량
- 다른 RPC 호출로 인한 오버헤드
- 클라이언트 서비스를 위해 다른 NFS 요청 또는 디스크 I/O를 기다리는 데 소요된 시간
나는 이미 다음에서 제공되는 통계에 대해 알고 있습니다./proc/net/rpc/nfsd 있으며 실제로 다음과 같은 글을 썼습니다.블로그 게시물그것들을 깊이 있게 설명합니다. 제가 찾고 있는 것은 더 깊이 파고들어 특정 고객이 본 성과에 기여하는 요소가 무엇인지 이해하는 데 도움이 되는 방법입니다. NFS 서버가 클러스터의 애플리케이션 성능에서 수행하는 역할을 분석하여 이를 가장 잘 최적화할 수 있는 방법을 생각하고 싶습니다.
답변1
단지 아이디어입니다. Wireshark로 nfs 트래픽을 스니핑해 보세요. 어떤 사용자가 어떤 파일에 액세스했는지 알려줄 수 있습니다.
tshark -R nfs -i eth0
답변2
사용할 수 있는 다양한 *stat 유틸리티 중 nfsstat가 단연 최악입니다! 그것은 당신에게 많은 카운터를 볼 수 있는 능력을 제공하지만 그게 전부입니다. 두 번 보면 각 카운터가 얼마나 변경되었는지 알아내려는 작업을 수행해야 하며 변경 속도를 알고 싶다면 샘플 간의 초 수로 나누어야 합니다. 공평하게 말하면, nfsstat는 상황이 여전히 매우 조잡했던 수년 전으로 거슬러 올라갑니다. 이제는 많은 문제가 발생할 수 있기 때문에 출력 형식을 변경하려는 사람이 아무도 없어 방해를 받습니다.
nfs를 모니터링하기 위해 Collectl을 사용하는 경우 읽기 쉬운 형식으로 nfsstat 출력을 제공하지만 더 좋은 점은 몇 시간 또는 며칠 동안 실행하고 백그라운드에서 수집한 데이터를 재생할 수 있다는 것입니다. 프로세스가 수행 중인 작업을 확인하는 요청의 경우, Collectl은 각 프로세스가 수행 중인 I/O 양을 포함한 프로세스 데이터를 수집하고 상위 I/O 사용자를 표시하는 재생도 가능합니다. 실시간으로 최고의 기능을 사용할 수도 있습니다.
디스크 테마 자체 수집을 보고 싶다면 그렇게 할 수도 있고 모든 것을 조정된 디스플레이에 표시할 수도 있습니다.
확인해 보세요... -마크
답변3
수집하다(특히 그NFS 하위 시스템)은 분석에 유용할 수 있는 매우 훌륭한 유틸리티이지만 실제로는 그렇지 않습니다.~ 아니다귀하의 요구 사항 목록과 일치하십시오. 나는 어떤 Linux 유틸리티도 알지 못합니다.
(주제에서 벗어난 메모를 추가하겠습니다.~이다귀하의 요구 사항에 맞는 소프트웨어: Sun의 DTrace 기반분석(PDF)- 아쉽게도 Linux에서는 사용할 수 없습니다. 다음에서 훌륭한 예를 많이 찾을 수 있습니다.브렌든 그레그의 블로그이 도구의 기능을 설명합니다.)
답변4
내 생각에는 이것이 바로 오늘날 도구의 문제점을 강조하는 것 같습니다. 여기서는 nfsstat, iostat 및 iotop을 포함하여 최소 3개를 언급했습니다. 그런 다음 wireshare와 nfsreplay에 대한 언급이 지나갔습니다. 이것이 실제로 일을 하는 정상적인 방법처럼 들립니까? Wireshark 외에 자체 카테고리가 있는데, 도구 1개를 선호하지 않나요?
오프너의 경우 iostat의 출력이 매우 유용하다고 생각하지만 숫자에 .00이 모두 포함되어 읽기가 너무 어렵습니다. Collectl은 똑같은 데이터를 보고하지만 눈에 훨씬 더 쉽게 포맷되었습니다. 당신은 이미 nfsstat에 대해 내가 어떻게 생각하는지 알고 있으며, Collectl은 모든 데이터를 재생할 수 있으므로 '재생' 유틸리티가 필요하지 않습니다. 'iotop'의 경우 Collect는 포함된 I/O를 기준으로 정렬된 프로세스를 표시할 수도 있습니다.
따라서 타임스탬프까지 포함하여 모든 정보가 포함되어 있습니다. 더 미세한 모니터링 간격이 필요한 경우 항상 샘플링을 0.1초, 0.5초 또는 그 사이의 임의의 속도로 되돌릴 수 있습니다. 하지만 이렇게 빠르게 프로세스를 모니터링하면 더 많은 오버헤드가 발생하지만 프로세스 모니터링 유틸리티를 사용하면 가능합니다.
그리고 마지막 보너스는 스프레드시트에 로드하여 쉽게 플롯하거나 Collectl-utils의 일부인 coplot을 사용할 수 있는 Collectl로 수집한 모든 것입니다.
-표시