파일 당 Linux IO 모니터링?


29

CentOS에서 파일 당 디스크 IO를 모니터링하는 유틸리티 또는 프로세스에 관심이 있습니다.

Win2008에서 resmon 유틸리티는 이러한 유형의 드릴 다운을 허용하지만 내가 찾은 Linux 유틸리티 (iostat, iotop, dstat, nmon)는 없습니다.

데이터베이스 서버에서 IO 병목 현상을 모니터링하는 데 관심이 있습니다. MSSQL을 사용하면 어떤 파일 / 파일 공간이 가장 까다로운 지 알 수있는 유익한 진단이 있습니다.


2
아마도 Linux 성능 분석 및 도구 : SCaLE 11x에서 Brendan Gregg의 대화 가 도움이 될 것입니다. 슬라이드 72/115를 참조하십시오.
Cristian Ciupitu

1
이것이 가능하다면, 대부분의 파일이 pagecache에 맵핑되므로 pagecache에있는 바이트와 디스크에있는 바이트에 따라 숫자가 모든 곳에있을 수 있습니다.
Matthew Ife

@Matt 그러나 작동하는 대답!
ewwhite

답변:


18

아마도 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 스크립트 를 참조하십시오.


17

시스템 탭 * 스크립트 :

#!/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 systemtapdebuginfo-install kernel


저것은 꽤 인상적인 시스템 탭입니다. 다목적성에 대한 탁월한 데모.
Matthew Ife

이 측정은 직접 I / O 및 비동기 I / O를 측정합니까? (posix가 아니라 io_submit 사용)
Matthew Ife

@Mlfe : 감사합니다! 참고로 스크립트를 작성하는 동안 pv 에서 작은 버그를 발견하고 SystemTap ( task_dentry_path) 에서 또 하나의 버그를 발견했습니다 .-) I / O에 대해서는 전혀 모르지만 명령이나 명령을 주면 테스트 할 수 있습니다 샘플 프로그램. 예를 들어 파이썬 을 사용 하여 mmap을 테스트했습니다. dd iflag=direct oflag=direct나타나다.
Cristian Ciupitu

2
mmap을 위해 이것을 시도하십시오 : gist.github.com/anonymous/7014284 개인 매핑은 측정되지 않지만 공유되는 매핑은 베팅입니다.
Matthew Ife


9

실제로 blktrace이것을 사용하고 싶습니다 . 만나다Seekwatcher 및 blktrace를 사용하여 Linux IO 시각화를 .

내 예 중 하나를 곧 게시 할 수 있는지 살펴 보겠습니다.


편집하다:

Linux 배포에 대해서는 언급하지 않지만 RHEL과 유사한 시스템을 사용하는 경우 Linux 또는 System Tapdtrace 스크립트 에 적합한 경우 일 수 있습니다.


2
고마워, 좋은 점과 매우 가깝지만 자세한 블록 레이어 정보를 제공하므로 VFS 추상화 레이어에서 작동하는 것이 필요합니다.
GioMac

이것을 실행하기 위해 일부 시스템 탭 스크립트를 시도하기 시작했습니다. 서버가 충돌하여 실패했습니다. Solaris의 Dtrace에서이 정보를 얻을 수 있습니다. 나는 오늘 리눅스로 시도 할 것이다.
ewwhite 2016 년

4

내가 아는 유일한 도구는 파일로 I / O 활동을 모니터링 할 수 있습니다 inotifywatch. inotify-tools패키지 의 일부입니다 . 불행히도, 그것은 당신에게 작업 횟수를 제공합니다.


4

높은 IO에 기여하는 프로세스의 PID를 얻으려면 iotop을 사용하십시오.

생성 한 PID에 대해 strace를 실행하면 특정 프로세스에서 어떤 파일에 액세스하고 있는지 확인할 수 있습니다.

strace -f -p $PID -e trace=open,read,write

strace는 syscall 및 액세스 된 파일에 대한 정보를 제공 할 것입니다. 구문 분석하고 사용법에 대한 통계를 얻는 것이 매우 어려울 것입니다.
GioMac

1
나는 이것을 시도 할 것이라고 생각했다. 많은 데이터를 생성합니다. Ctrl + C를 누르면 프로세스가 중단 될 수 있습니다. 다소 위험한 것 같습니다.
Matt


2

나는 당신이 잘못된 질문을했을지도 모른다고 주장합니다. I / O 병목 현상을 찾는 경우 디스크에서 발생하는 상황을 확인하는 것이 중요 할 수 있습니다. db는 랜덤 i / o를 수행하는 것으로 유명하며 특히 스핀들 수가 적은 경우 처리량을 크게 줄일 수 있습니다.

더 흥미로운 것은 디스크 자체에서 대기 시간이 오래 걸리는지 확인하는 것입니다. 개별 디스크 성능 통계를 표시하는 "collectl -sD"명령을 통해 collectl로이를 수행 할 수 있습니다. 최상위 홈 유틸리티로 바꾸려면 --home입니다. 관련된 디스크가 많으면 colmux : colmux -command "-sD"를 통해 실행하면 여러 시스템에서 선택한 열을 기준으로 정렬 할 수 있습니다.


나는 디스크 관점에서 당신과 동의하지 않습니다. 통찰력을 얻을 수있는 곳은 데이터베이스 파일 공간을 사용하여 데이터, 인덱스, 로그 등을 분할하는 데 사용되지만 리소스가 제한되어있을 때 공유 디스크에 마운트하는 경우입니다 (예 : 개발 서버). 이상적으로, 각 파일 공간은 별도의 볼륨에 있으므로 디스크 관점에서 IO를 보는 것이 적절합니다. 이것이 모든 모니터링 유틸리티가 파일 기반이 아닌 디스크 인 이유 일 수 있습니다.
kermatt

올바른 질문입니다. 목표는 "어떤 I / O가 어떤 테이블에 발생 하는가?"를 파악하는 것입니다. 대부분의 데이터베이스에서 테이블은 하나 이상의 파일입니다. 모든 디스크는 많은 파일로 끝나게되며 핫스팟 중 어떤 것이 핫스팟인지 판별하는 것이 유용한 데이터베이스 조정 입력입니다.
Greg Smith

2

블록 장치 (/ proc / diskstats를 통해) 및 프로세스 (io accounting /proc/$PID/ioor 또는 taskstats 를 통해)마다 I / O를 모니터링 할 수 있지만 파일별로 수행하는 방법을 모르겠습니다.


0

수 있음 inotify를이 이 문제를 해결 해결됩니다.

inotify API는 파일 시스템 이벤트를 모니터링하기위한 메커니즘을 제공합니다 .Iotify는 개별 파일을 모니터링하거나 디렉토리를 모니터링하는 데 사용할 수 있습니다. 디렉토리가 모니터 될 때, inotify는 디렉토리 자체 및 디렉토리 내의 파일에 대한 이벤트를 리턴합니다.

inotify를 사용하여 파일 시스템 활동 모니터링

inotify 참조


이것은 파일에 대한 호출을 제공 할 수 있지만 pid가 무엇을했는지, 쓰기가 얼마나 컸는 지, 어디에서 얼마나 오래 걸 렸는지 발견하는 데 거의 도움이되지 않습니다.
Matthew Ife

이 질문은 그 과정에 대해 묻지 않습니다. (아마도 다른 방법으로 발견 될 수 있습니다 lsof)
Gert van den Berg

0

여기에 답변에 좋은 정보가 많이 있지만 실제로 적용 가능한지 궁금합니다.

10 기가 바이트 단위의 파일에 대해 지속적으로 쓰고있는 경우, 파일이 지속적으로 추가되는 (파일 크기 만 모니터링하는 경우) 로그 파일 또는 이와 유사한 경우가 아니면 파일이 mmap'd 일 가능성이 큽니다. . 이 경우 가장 좋은 해결책은 대부분의 솔루션을 보지 말아야한다는 것입니다. 제안 된 다른 솔루션에 대해 가장 먼저 물어봐야 할 것은 "mmap과 함께 작동합니까?"입니다. 그러나 대부분 문제가 해결되지는 않지만 파일을 모니터링하는 대신 문제를 블록 장치 모니터링으로 전환 할 수 있습니다.

프로그램이 mmap'd 파일에서 페이지를 요청하면 가상 메모리의 위치를 ​​참조하는 것입니다. 해당 페이지가 이미 메모리에 있거나 없을 수 있습니다. 그렇지 않은 경우 페이지 폴트가 발생하여 디스크에서 페이지가로드되는 것을 트리거하지만 가상 메모리 시스템 내에서 발생하며 특정 응용 프로그램 프로세스 또는 특정 파일에 쉽게 연결되지 않습니다. 마찬가지로 앱이 플래그에 따라 mmap'd 페이지를 업데이트 할 때 디스크에 즉시 쓰기를 트리거하지 않을 수 있으며 경우에 따라 디스크에 전혀 가지 않을 수도 있습니다 (마지막으로 관심이없는 경우도 있음) 에서).

mmap'd 파일에 대해 생각할 수있는 최선의 방법은 실행 가능한 경우 관심있는 각 파일을 별도의 장치에 넣고 장치 통계를 사용하여 사용 정보를 수집하는 것입니다. 이를 위해 lvm 파티션을 사용할 수 있습니다. 바인드 마운트는 새 블록 장치를 만들지 않으므로 작동하지 않습니다.

별도의 블록 장치에 파일이 있으면 / sys / block / * 또는 / proc / diskstats에서 통계를 얻을 수 있습니다.

이것을 프로덕션 서버에 도입하기에는 너무 혼란 스러울 수 있지만,이를 사용할 수 있습니다.

파일이 잘리지 않으면 여기에서 다른 솔루션 중 하나를 선택할 수 있습니다.


주의 깊게 읽으십시오, 나는 블록 레벨 통계가 필요하지 않습니다 :)
GioMac

맞습니다.하지만 요청하는 통계 종류는 mmapped 파일에서는 불가능합니다. 따라서 실행중인 경우 장치 당 하나의 파일을 사용하여 파일에 대한 통계를 얻는 방법을 제공합니다. 기기 통계.
mc0e

-1

나는 최근에 collectl 을 땜질하고 있었고 , 그것은 훌륭한 도구이며, 설치하기가 매우 간단합니다. 가장 흥미로운 점은 IO 병목 현상의 원인이되는 프로세스를 찾을 수 있다는 것입니다. Collectl 사용 을 읽는 것이 좋습니다 . 유용 할 수 있습니다.


1
collectl은 파일별로 모니터링하지 않고 프로세스별로 작동합니다.
Greg Smith


-2

iotop은 Linux에서 IO의 병목 현상을 식별하는 데 가장 적합한 도구 중 하나라고 생각합니다.


3
-1 iotop은 파일 당 모니터링하지 않으며 프로세스 당 작동합니다.
dyasny
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.