☰

디스크 IO 트래픽 분석

tag-icon • tag-icon ubuntu software-raid performance io
디스크 IO 트래픽 분석

예상치 못한 높은 쓰기 트래픽을 보이는 웹 서버(Ubuntu 11.04)를 실행하고 있습니다. 서버가 전혀 쓰지 않을 경우 쓰기 트래픽의 양은 읽기 트래픽과 비슷합니다.

불필요한 쓰기 작업이 걱정되어 시스템에 어떤 문제가 있는지 분석해 보았습니다. 과도한 아파치 로깅 또는 액세스 시간 문제를 제외할 수 있습니다(사용정시마운트 구성).

문제를 추적하기 위해 어떤 파일이 어디에 기록되었는지 확인하고 싶었습니다. 따라서 block_dump를 통해 IO 로그인을 활성화했습니다(이 주제에 대한 유용한 블로그 항목:스프로킷.io). 모든 파일 시스템 활동은 syslog에 기록됩니다. 내 시스템의 짧은 발췌문은 다음과 같습니다.

8월 21일 18:22:55 xxxxx 커널: [3984721.590864] apache2(2761): md2의 READ 블록 1098502400(8 섹터)
8월 21일 18:22:55 xxxxx 커널: [3984721.594005] kjournald(316): WRITE 블록 222439 md2의 4648 (8 섹터)
8월 21일 18:22:55 xxxxx 커널: [3984721.594029] md2_raid1(260): sdb3의 WRITE 블록 2925532672(8 섹터)
8월 21일 18:22:55 xxxxx 커널: [3984721.594044] md2_raid1(260): 쓰기 sda3(8 섹터)의 블록 2925532672
Aug 21 18:22:55 xxxxx 커널: [3984721.644244] apache2(2761): md2(8 섹터)의 블록 2242118744 읽기

좋아, 이제 어떤 블록이 기록되었는지 알 수 있습니다. 그런데 이러한 블록 ID를 기반으로 작성된 파일 이름을 실제로 식별할 수 있는 방법이 있습니까?

당신의 도움을 주셔서 감사합니다!

참고: Software Raid를 사용하고 있는데 문제의 일부일 수 있습니다.

답변1

ext2/ext3/ext4를 가정하면 다음으로 시작합니다.

[406420.877412] vi(12496): READ block 4522288 on dm-1 (8 sectors)

파일 시스템 블록 크기를 결정합니다.

# /sbin/dumpe2fs /dev/dm-1 | grep 'Block size'
dumpe2fs 1.42.3 (14-May-2012)
Block size:               4096

512바이트 섹터가 있는 드라이브가 있다고 가정하면 블록을 4096/512, 즉 8로 나누어 565286을 얻습니다.

와 다음 debugfs의 조합을 사용 합니다 :icheckncheck

debugfs:  icheck 565286
Block   Inode number
565286  142506

debugfs:  ncheck 142506
Inode   Pathname
142506  /etc/security/time.conf

편집: sd* 장치가 아닌 md* 장치에서 이 작업을 수행하십시오. sd* 장치 I/O는 소프트웨어 raid의 결과입니다.

답변2

파일 시스템은 블록 장치 및 소프트웨어 RAID보다 더 높은 수준의 추상화에 상주합니다. 즉, 소프트웨어 RAID는 99.9% 확률로 문제의 일부가 아니며 단지 블록 장치일 뿐입니다. 따라서 I/O 활동을 분석하려면 다른 도구 세트를 사용해야 합니다. iotop먼저 실행 중인 프로세스 중에서 최고의 작성자를 식별하는 것부터 시작하는 것이 좋습니다 . 그러면 어떤 파일이 기록되고 있는지 확인 lsof하고 사용할 수 있습니다 .strace

답변3

Linux에는 다음과 같은 커널 시스템이 있습니다.inotify파일의 변경 사항을 확인합니다. 사용자 영역에서는 다음을 사용할 수 있습니다.inotify 도구( apt-get install inotify-tools) 디렉토리를 보려면. 그러나 각 파일에는 개별 감시가 있어야 합니다. 이를 디렉터리(루트 포함)에 재귀적으로 적용할 수 있지만 감시하는 횟수가 적을수록 오버헤드가 줄어듭니다.

범위를 좁힐 수 있는 다른 옵션은 다음과 같습니다.

  • atop이를 통해 어떤 프로세스가 쓰기를 수행하고 있는지 확인할 수 있습니다.
  • auditctl매우 난해한 구문을 가지고 있지만 시계를 모든 시스템 호출에 배치할 수 있습니다.

관련 정보