☰

ディスクIOトラフィックの分析

tag-icon • tag-icon ubuntu software-raid performance io
ディスクIOトラフィックの分析

予想外に書き込みトラフィックが増加する Web サーバー (Ubuntu 11.04) を実行しています。サーバーがまったく書き込みを行わないはずなのに、書き込みトラフィックの量が読み取りトラフィックの量に匹敵します。

不要な書き込み操作が心配だったので、システムで何が問題になっているのか分析してみました。Apacheのログの大量使用やアクセス時間の問題は除外できます（ノータイムマウント構成)。

問題を追跡するために、どのファイルが書き込まれたかを確認したいと思いました。そのため、block_dump 経由で IO ログを有効にしました (このトピックに関する役立つブログ エントリ:スプロケット)。すべてのファイルシステムのアクティビティは syslog に記録されます。以下は私のシステムの短い抜粋です。

8 月 21 日 18:22:55 xxxxx カーネル: [3984721.590864] apache2(2761): md2 のブロック 1098502400 を読み取り (8 セクター)
8 月 21 日 18:22:55 xxxxx カーネル: [3984721.594005] kjournald(316): md2 のブロック 2224394648 を書き込み (8 セクター)
8 月 21 日 18:22:55 xxxxx カーネル: [3984721.594029] md2_raid1(260): sdb3 のブロック 2925532672 を書き込み (8 セクター)
8 月 21 日 18:22:55 xxxxx カーネル: [3984721.594044] md2_raid1(260): sda3 のブロック 2925532672 を書き込み (8 セクター)
8 月 21 日 18:22:55 xxxxx カーネル: [3984721.644244] apache2(2761): md2 のブロック 2242118744 を読み取り (8 セクター)

さて、どのブロックが書き込まれたかがわかりました。しかし、これらのブロック ID に基づいて、書き込まれたファイル名を実際に識別する方法はありますか?

ご協力いただきありがとうございます！

ところで、私はソフトウェア 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になります。lsofstrace

答え3

Linuxにはカーネルシステムがあり、通知ファイルの変更を監視するために、ユーザーランドではinotify ツール( apt-get install inotify-tools) を使用してディレクトリを監視します。ただし、各ファイルには個別の監視を設定する必要があります。ディレクトリ (ルートでも) に再帰的に適用できますが、監視対象が少ないほどオーバーヘッドが少なくなります。

絞り込むための他のオプションは次のとおりです。

  • atopこれにより、どのプロセスが書き込みを実行しているかを確認できます
  • auditctl非常に難解な構文だが、任意のシステムコールに監視を配置できる。

関連情報