응용 프로그램의 잠재적 병목 현상을 추적 할 수 있도록 NFS 서버를 분석하고 싶습니다. 서버가 SUSE Enterprise Linux 10을 실행 중입니다.
내가 알고 싶은 것들은 다음과 같습니다.
- 어떤 클라이언트가 어떤 파일에 액세스하고 있는지
- 클라이언트별로 읽기 / 쓰기 처리량
- 다른 RPC 호출로 부과되는 오버 헤드
- 클라이언트를 서비스하기 위해 다른 NFS 요청 또는 디스크 I / O를 기다리는 데 소요 된 시간
나는 이미 사용 가능한 통계에 대해 알고 /proc/net/rpc/nfsd있으며 실제로 그 통계 를 자세히 설명 하는 블로그 게시물을 작성했습니다. 내가 찾고있는 것은 특정 클라이언트가 보는 성능에 어떤 요소가 영향을 미치는지 더 깊이 파고 이해하는 방법입니다. 클러스터의 응용 프로그램 성능에서 NFS 서버가 수행하는 역할을 분석하여 가장 최적화하는 방법을 생각할 수 있습니다.
답변
그냥 아이디어, wireshark로 nfs 트래픽을 스니핑하십시오. 어떤 사용자가 어떤 파일에 액세스했는지 알려줄 수 있습니다.
tshark -R nfs -i eth0
답변
하나의 가능한 모든 * stat 유틸리티에 대해 이야기해야합니다. nfsstat는 훨씬 최악입니다! 그것은 당신에게 많은 카운터를 볼 수있는 능력을 제공하지만 그게 전부입니다. 두 번 살펴보면 각 카운터가 얼마나 많이 바뀌 었는지 파악하는 작업을 수행해야하며 변경 속도를 알고 싶다면 샘플 사이의 시간 (초)으로 나눠야합니다. 모든 공정성에서, nfsstat는 몇 년 전으로 거슬러 올라가는 일이 많았으며, 아마도 출력 형식을 바꾸고 싶지 않은 사람이 많은 것을 깨뜨릴 수 있기 때문에 아무도 방해를받습니다.
collectl을 사용하여 nfs를 모니터하는 경우 nfsstat 출력을 훨씬 읽기 쉬운 형식으로 제공하지만 몇 시간 또는 며칠 동안 실행하여 백그라운드에서 수집 한 데이터를 재생할 수있는 것이 더 좋습니다. 어떤 프로세스가 수행되고 있는지에 대한 요청과 관련하여 collectl은 각 프로세스가 수행하는 I / O의 양을 포함하여 프로세스 데이터를 수집하고 상위 I / O 사용자를 표시하여 재생할 수도 있습니다. 최고의 기능을 실시간으로 사용할 수도 있습니다.
디스크 테마를보고 싶다면 collectl도 그렇게 할 수 있으며 모든 것을 조정 된 디스플레이에 표시 할 수 있습니다.
확인해보세요 … -mark
답변
collectl (특히 NFS 하위 시스템 )은 분석에 유용하지만 요구 사항 목록과 일치 하지 않는 매우 유용한 유틸리티입니다 . 나는 리눅스 유틸리티를 모른다.
(내가이 주제에서 벗어난 메모를 추가 할 수 있도록 참조 : 입니다 귀하의 요구 사항과 일치하는 소프트웨어 : 썬의 DTrace를 기반 분석 (PDF 파일) . -하지만 불행히도 리눅스에서 사용할 수 없습니다 당신은 큰 예를 많이 찾을 수 있습니다 브렌든 그레그의 블로그 설명 이 도구의 기능.)
답변
nfsstat를 확인하십시오. 그것은 당신이 원하는 모든 것을 보여주지는 않지만 최소한 좋은 부분 집합을 보여줍니다.
http://linux.die.net/man/8/nfsstat
답변
내 생각에 이것은 오늘날 도구의 문제를 정확하게 강조합니다. 여기에서는 nfsstat, iostat 및 iotop을 포함하여 3 개 이상 언급했습니다. 그런 다음 wireshare와 nfsreplay에 대한 언급이있었습니다. 이것이 실제로 일을하는 일반적인 방법처럼 들립니까? wireshark 이외의 범주는 모두 고유 한 범주입니다. 도구 하나를 선호하지 않습니까?
오프너에게는 iostat의 출력이 매우 유용하다는 것을 알지만 숫자로 된 .00을 모두 읽는 것은 너무 어렵습니다. Collectl은 똑같은 데이터를보고하지만 눈에 훨씬 쉽게 서식을 지정합니다. 당신은 이미 nfsstat에 대해 어떻게 생각하는지 알고 있으며 collectl은 모든 데이터를 재생할 수 있기 때문에 ‘재생’유틸리티가 필요하지 않습니다. ‘iotop’의 경우 collect는 I / O를 포함한 모든 프로세스를 정렬하여 표시 할 수도 있습니다.
타임 스탬프를 완성하면됩니다. 보다 정밀한 모니터링 간격이 필요한 경우 항상 샘플링을 0.1 또는 0.5 초 또는 그 사이의 시간으로 크랭크 할 수 있지만 프로세스를 빠르게 모니터링하면 더 많은 오버 헤드가 발생하지만 프로세스 모니터링 유틸리티를 사용하면 더 많은 오버 헤드가 발생합니다.
그리고 마지막 보너스는 collectl을 사용하여 스프레드 시트에로드 할 수 있고 collectl-utils의 일부인 colplot을 쉽게 플롯하거나 사용할 수있는 것입니다.
-표
답변
당신이 시도 할 수 있습니다 nfswatch에서 http://nfswatch.sourceforge.net
http://prefetch.net/blog/index.php/2009/06/16/monitoring-nfs-operations-with-nfswatch/ 에서 샘플 출력을 볼 수 있습니다 .
nfswatch일종의 top(배치 모드가 있는지 확실하지 않지만). 일단 실행되면 키를 눌러 디스플레이를 변경할 수 있습니다 (예 : NFS 서버를 사용하여 NFS 클라이언트를 표시하려면 “c”).
그러나 간단한 테스트에서는 nfswatchNFSv4에서 작동하지 않는 것 같습니다.
답변
현재로서는 더 나은 답변이 없지만 디스크 IO를 매우 정확하게 따라갈 수 있습니다.
iostat -mx <delay in sec.> <devices>
매우 유용한 수치, 특히 IO의 평균 대기열 크기 및 대기 시간 (ms)을 제공합니다. 디스크에 병목 현상이 있고 병목 현상이 IO 수 또는 처리량인지 여부를 쉽게 알 수 있습니다.
그런 다음
netstat -plaute | grep nfs
클라이언트 연결과 각 클라이언트에서 전송 된 바이트가 실시간으로 표시됩니다. 지속적인 데이터를 위해 루프를 반복하십시오. 지속적인 데이터를 제공하는 스크립트를 만드는 것은 매우 쉬울 것입니다 …
이제 프로세스 당 IO를 얻으려면 우수한 iotop을 사용할 수 있습니다 . 그래도 nfsd 프로세스를 클라이언트와 일치시키는 방법을 찾아야합니다.
어떤 클라이언트가 어떤 파일에 액세스하는지에 관해서는 붙어 있습니다. 실제로 NFS 클라이언트에서 현재 읽고 쓰는 파일은 lsof 출력에도 나타나지 않습니다.
netstat를 확장하기 위해 watch -d를 사용하여 상황이 호스트별로 어떻게 바뀌고 정렬되는지 확인하십시오.
watch -d "netstat -plaute | grep nfs | sort -k 4,5"
