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)
제한 사항 / 버그 :
- mmap I / O가 있기 때문에 표시되지 않습니다 기반
devnameIS"N/A" - tmpfs의 파일 있기 때문에 표시되지 않습니다
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
답변
실제로 blktrace이것을 사용하고 싶습니다 . 만나다Seekwatcher 및 blktrace를 사용하여 Linux IO 시각화를 .
내 예 중 하나를 곧 게시 할 수 있는지 살펴 보겠습니다.
편집하다:
Linux 배포에 대해서는 언급하지 않지만 RHEL과 유사한 시스템을 사용하는 경우 Linux 또는 System Tap 의 dtrace 스크립트 에 적합한 경우 일 수 있습니다.
답변
내가 아는 유일한 도구는 파일로 I / O 활동을 모니터링 할 수 있습니다 inotifywatch. inotify-tools패키지 의 일부입니다 . 불행히도, 그것은 당신에게 작업 횟수를 제공합니다.
답변
높은 IO에 기여하는 프로세스의 PID를 얻으려면 iotop을 사용하십시오.
생성 한 PID에 대해 strace를 실행하면 특정 프로세스에서 어떤 파일에 액세스하고 있는지 확인할 수 있습니다.
strace -f -p $PID -e trace=open,read,write
답변
답변
나는 당신이 잘못된 질문을했을지도 모른다고 주장합니다. I / O 병목 현상을 찾는 경우 디스크에서 발생하는 상황을 확인하는 것이 중요 할 수 있습니다. db는 랜덤 i / o를 수행하는 것으로 유명하며 특히 스핀들 수가 적은 경우 처리량을 크게 줄일 수 있습니다.
더 흥미로운 것은 디스크 자체에서 대기 시간이 오래 걸리는지 확인하는 것입니다. 개별 디스크 성능 통계를 표시하는 “collectl -sD”명령을 통해 collectl로이를 수행 할 수 있습니다. 최상위 홈 유틸리티로 바꾸려면 –home입니다. 관련된 디스크가 많으면 colmux : colmux -command “-sD”를 통해 실행하면 여러 시스템에서 선택한 열을 기준으로 정렬 할 수 있습니다.