CentOS에서 파일 당 디스크 IO를 모니터링하는 유틸리티 또는 프로세스에 관심이 있습니다.
Win2008에서 resmon 유틸리티는 이러한 유형의 드릴 다운을 허용하지만 내가 찾은 Linux 유틸리티 (iostat, iotop, dstat, nmon)는 없습니다.
데이터베이스 서버에서 IO 병목 현상을 모니터링하는 데 관심이 있습니다. MSSQL을 사용하면 어떤 파일 / 파일 공간이 가장 까다로운 지 알 수있는 유익한 진단이 있습니다.
CentOS에서 파일 당 디스크 IO를 모니터링하는 유틸리티 또는 프로세스에 관심이 있습니다.
Win2008에서 resmon 유틸리티는 이러한 유형의 드릴 다운을 허용하지만 내가 찾은 Linux 유틸리티 (iostat, iotop, dstat, nmon)는 없습니다.
데이터베이스 서버에서 IO 병목 현상을 모니터링하는 데 관심이 있습니다. MSSQL을 사용하면 어떤 파일 / 파일 공간이 가장 까다로운 지 알 수있는 유익한 진단이 있습니다.
답변:
아마도 SystemTap 이 최선의 선택 일 것입니다.
iotime.stp 예제 의 출력 결과는 다음과 같습니다.
825946 3364 (NetworkManager) access /sys/class/net/eth0/carrier read: 8190 write: 0
825955 3364 (NetworkManager) iotime /sys/class/net/eth0/carrier time: 9
[...]
117061 2460 (pcscd) access /dev/bus/usb/003/001 read: 43 write: 0
117065 2460 (pcscd) iotime /dev/bus/usb/003/001 time: 7
[...]
3973737 2886 (sendmail) access /proc/loadavg read: 4096 write: 0
3973744 2886 (sendmail) iotime /proc/loadavg time: 11
학습 곡선과는 다른 단점 은 프로덕션 시스템에서는 불가능한 kernel-debug 를 설치해야한다는 것입니다 . 그러나 개발 시스템에서 모듈을 컴파일 하고 프로덕션 시스템에서 해당 .ko 를 실행하는 교차 계측에 의존 할 수 있습니다 .
또는 초조 한 경우 초보자 안내서의 4 장. 유용한 SystemTap 스크립트 를 참조하십시오.
시스템 탭 * 스크립트 :
#!/usr/bin/env stap
#
# Monitor the I/O of a program.
#
# Usage:
# ./monitor-io.stp name-of-the-program
global program_name = @1
probe begin {
printf("%5s %1s %6s %7s %s\n",
"PID", "D", "BYTES", "us", "FILE")
}
probe vfs.read.return, vfs.write.return {
# skip other programs
if (execname() != program_name)
next
if (devname=="N/A")
next
time_delta = gettimeofday_us() - @entry(gettimeofday_us())
direction = name == "vfs.read" ? "R" : "W"
# If you want only the filename, use
// filename = kernel_string($file->f_path->dentry->d_name->name)
# If you want only the path from the mountpoint, use
// filename = devname . "," . reverse_path_walk($file->f_path->dentry)
# If you want the full path, use
filename = task_dentry_path(task_current(),
$file->f_path->dentry,
$file->f_path->mnt)
printf("%5d %1s %6d %7d %s\n",
pid(), direction, $return, time_delta, filename)
}
결과는 다음과 같습니다.
[root@sl6 ~]# ./monitor-io.stp cat
PID D BYTES us FILE
3117 R 224 2 /lib/ld-2.12.so
3117 R 512 3 /lib/libc-2.12.so
3117 R 17989 700 /usr/share/doc/grub-0.97/COPYING
3117 R 0 3 /usr/share/doc/grub-0.97/COPYING
또는 마운트 지점에서 경로 만 표시하도록 선택한 경우 :
[root@f19 ~]# ./monitor-io.stp cat
PID D BYTES us FILE
26207 R 392 4 vda3,usr/lib64/ld-2.17.so
26207 R 832 3 vda3,usr/lib64/libc-2.17.so
26207 R 1758 4 vda3,etc/passwd
26207 R 0 1 vda3,etc/passwd
26208 R 392 3 vda3,usr/lib64/ld-2.17.so
26208 R 832 3 vda3,usr/lib64/libc-2.17.so
26208 R 35147 16 vdb7,ciupicri/doc/grub2-2.00/COPYING
26208 R 0 2 vdb7,ciupicri/doc/grub2-2.00/COPYING
[root@f19 ~]# mount | grep -E '(vda3|vdb7)'
/dev/vda3 on / type ext4 (rw,relatime,seclabel,data=ordered)
/dev/vdb7 on /mnt/mnt1/mnt11/data type xfs (rw,relatime,seclabel,attr2,inode64,noquota)
제한 사항 / 버그 :
devname
IS"N/A"
devname
이다"N/A"
Matthew Ife 의 검색 결과 의 프로그램 :
대한 mmaptest 개인 :
PID D BYTES us FILE
3140 R 392 5 vda3,usr/lib64/ld-2.17.so
3140 R 832 5 vda3,usr/lib64/libc-2.17.so
3140 W 23 9 N/A,3
3140 W 23 4 N/A,3
3140 W 17 3 N/A,3
3140 W 17 118 N/A,3
3140 W 17 125 N/A,3
대한 mmaptest 공유 :
PID D BYTES us FILE
3168 R 392 3 vda3,usr/lib64/ld-2.17.so
3168 R 832 3 vda3,usr/lib64/libc-2.17.so
3168 W 23 7 N/A,3
3168 W 23 2 N/A,3
3168 W 17 2 N/A,3
3168 W 17 98 N/A,3
대한 diotest (직접 I / O) :
PID D BYTES us FILE
3178 R 392 2 vda3,usr/lib64/ld-2.17.so
3178 R 832 3 vda3,usr/lib64/libc-2.17.so
3178 W 16 6 N/A,3
3178 W 1048576 509 vda3,var/tmp/test_dio.dat
3178 R 1048576 244 vda3,var/tmp/test_dio.dat
3178 W 16 25 N/A,3
* RHEL 6 또는 그에 대한 빠른 설정 지침 : yum install systemtap
및debuginfo-install kernel
task_dentry_path
) 에서 또 하나의 버그를 발견했습니다 .-) I / O에 대해서는 전혀 모르지만 명령이나 명령을 주면 테스트 할 수 있습니다 샘플 프로그램. 예를 들어 파이썬 을 사용 하여 mmap을 테스트했습니다. dd iflag=direct oflag=direct
나타나다.
실제로 blktrace
이것을 사용하고 싶습니다 . 만나다Seekwatcher 및 blktrace를 사용하여 Linux IO 시각화를 .
내 예 중 하나를 곧 게시 할 수 있는지 살펴 보겠습니다.
편집하다:
Linux 배포에 대해서는 언급하지 않지만 RHEL과 유사한 시스템을 사용하는 경우 Linux 또는 System Tap 의 dtrace 스크립트 에 적합한 경우 일 수 있습니다.
높은 IO에 기여하는 프로세스의 PID를 얻으려면 iotop을 사용하십시오.
생성 한 PID에 대해 strace를 실행하면 특정 프로세스에서 어떤 파일에 액세스하고 있는지 확인할 수 있습니다.
strace -f -p $PID -e trace=open,read,write
csysdig
F2를 누르고 Files
보기를 선택하십시오 . OPS 열별로 액세스 한 파일의 상단을 볼 수 있습니다 (F9를 눌러 변경할 수 있음).
csysdig -v files
"파일"보기로 바로 이동
나는 당신이 잘못된 질문을했을지도 모른다고 주장합니다. I / O 병목 현상을 찾는 경우 디스크에서 발생하는 상황을 확인하는 것이 중요 할 수 있습니다. db는 랜덤 i / o를 수행하는 것으로 유명하며 특히 스핀들 수가 적은 경우 처리량을 크게 줄일 수 있습니다.
더 흥미로운 것은 디스크 자체에서 대기 시간이 오래 걸리는지 확인하는 것입니다. 개별 디스크 성능 통계를 표시하는 "collectl -sD"명령을 통해 collectl로이를 수행 할 수 있습니다. 최상위 홈 유틸리티로 바꾸려면 --home입니다. 관련된 디스크가 많으면 colmux : colmux -command "-sD"를 통해 실행하면 여러 시스템에서 선택한 열을 기준으로 정렬 할 수 있습니다.
수 있음 inotify를이 이 문제를 해결 해결됩니다.
inotify API는 파일 시스템 이벤트를 모니터링하기위한 메커니즘을 제공합니다 .Iotify는 개별 파일을 모니터링하거나 디렉토리를 모니터링하는 데 사용할 수 있습니다. 디렉토리가 모니터 될 때, inotify는 디렉토리 자체 및 디렉토리 내의 파일에 대한 이벤트를 리턴합니다.
lsof
)
여기에 답변에 좋은 정보가 많이 있지만 실제로 적용 가능한지 궁금합니다.
10 기가 바이트 단위의 파일에 대해 지속적으로 쓰고있는 경우, 파일이 지속적으로 추가되는 (파일 크기 만 모니터링하는 경우) 로그 파일 또는 이와 유사한 경우가 아니면 파일이 mmap'd 일 가능성이 큽니다. . 이 경우 가장 좋은 해결책은 대부분의 솔루션을 보지 말아야한다는 것입니다. 제안 된 다른 솔루션에 대해 가장 먼저 물어봐야 할 것은 "mmap과 함께 작동합니까?"입니다. 그러나 대부분 문제가 해결되지는 않지만 파일을 모니터링하는 대신 문제를 블록 장치 모니터링으로 전환 할 수 있습니다.
프로그램이 mmap'd 파일에서 페이지를 요청하면 가상 메모리의 위치를 참조하는 것입니다. 해당 페이지가 이미 메모리에 있거나 없을 수 있습니다. 그렇지 않은 경우 페이지 폴트가 발생하여 디스크에서 페이지가로드되는 것을 트리거하지만 가상 메모리 시스템 내에서 발생하며 특정 응용 프로그램 프로세스 또는 특정 파일에 쉽게 연결되지 않습니다. 마찬가지로 앱이 플래그에 따라 mmap'd 페이지를 업데이트 할 때 디스크에 즉시 쓰기를 트리거하지 않을 수 있으며 경우에 따라 디스크에 전혀 가지 않을 수도 있습니다 (마지막으로 관심이없는 경우도 있음) 에서).
mmap'd 파일에 대해 생각할 수있는 최선의 방법은 실행 가능한 경우 관심있는 각 파일을 별도의 장치에 넣고 장치 통계를 사용하여 사용 정보를 수집하는 것입니다. 이를 위해 lvm 파티션을 사용할 수 있습니다. 바인드 마운트는 새 블록 장치를 만들지 않으므로 작동하지 않습니다.
별도의 블록 장치에 파일이 있으면 / sys / block / * 또는 / proc / diskstats에서 통계를 얻을 수 있습니다.
이것을 프로덕션 서버에 도입하기에는 너무 혼란 스러울 수 있지만,이를 사용할 수 있습니다.
파일이 잘리지 않으면 여기에서 다른 솔루션 중 하나를 선택할 수 있습니다.
나는 최근에 collectl 을 땜질하고 있었고 , 그것은 훌륭한 도구이며, 설치하기가 매우 간단합니다. 가장 흥미로운 점은 IO 병목 현상의 원인이되는 프로세스를 찾을 수 있다는 것입니다. Collectl 사용 을 읽는 것이 좋습니다 . 유용 할 수 있습니다.
http://dag.wieers.com/home-made/dstat/ 를 확인하는 것이 좋습니다 . 이 훌륭한 도구는 많은 통계를 확인할 수 있습니다.