🕵️‍♂️ LinuxディスクI/Oボトルネック、犯人からデバイスまで追跡！

10月 1, 2026

—

こんにちは！Linuxシステムを運用していると、突然ディスクI/Oが急増してシステム全体が遅くなる経験、皆さん一度はありますよね？🐢 その際、どのプロセスが問題を引き起こしているのか、そしてそのプロセスが実際にどの物理ディスクに負荷をかけているのかを突き止めることは非常に重要です。

今日は、iotopという強力なツールを活用して、多くのディスクI/Oを引き起こしているプロセスを特定し、そのプロセスが使用するファイルシステムを経由して、最終的にどの物理ディスクに接続されているのかまで追跡する旅に出かけましょう！🚀

📊 ステップ1：最も多くのディスク読み取り(Read)を引き起こすプロセスを見つける

まず、システムに負荷をかけている原因を特定する必要があります。ディスクI/Oを監視するには、iotopコマンドが非常に役立ちます。もしインストールされていない場合は、簡単にインストールできます。

# iotopがインストールされていない場合はインストールします。
yum install -y iotop

次に、iotopをバッチモード(-b)で2回実行(-n 2)し、現在I/Oがあるプロセスのみ(-o)をフィルタリングします。その結果をディスク読み取り(DISK READ)基準でソートし、最も高いプロセスのPID(プロセスID)を見つけてファイルに保存してみましょう。

# iotopをバッチモードで2回繰り返し、I/Oがあるプロセスのみを表示して実行。
# 結果をディスク読み取り(4番目のカラム)でソートし、最上位プロセスのPID(1番目のカラム)を抽出。
PID_HIGH_READ=$(iotop -b -n 2 -o | tail -n +3 | sort -k4,4nr | head -n 1 | awk '{print $1}')

# 見つかったPIDを/opt/highread.pidファイルに保存。
echo ${PID_HIGH_READ} > /opt/highread.pid

iotop -b -n 2 -o: 自動化されたスクリプトで使用するために、バッチモードで2回情報を収集します。
tail -n +3: iotopのヘッダー情報を除外し、実際のプロセスリストのみを取得します。
sort -k4,4nr: 4番目のカラム(DISK READ)を基準に数値降順(nr)でソートします。
head -n 1: ソートされた結果の中から一番上の最初の行のみを取得します。(最も高いプロセス)
awk ‘{print $1}’: 最初のカラムであるPIDのみを抽出します。

これで、/opt/highread.pidファイルを開けば、どのプロセスがディスクを最も多く読み込んでいるのかをすぐに確認できます！📈

🔄 ステップ2：最も頻繁なI/Oトランザクションを引き起こすプロセスを見つける

単に読み書き容量だけでなく、I/O操作の頻度(IO%)が高いプロセスを見つけることも重要です。小さなファイルを何度も読み書きする作業が、システムにより大きな負荷を与えることもあるからです。

今回は、I/O使用率(10番目のカラム)を基準にソートして、最も忙しいプロセスを見つけてみましょう。

# iotopの結果をI/O使用率(10番目のカラム)でソートし、最上位プロセスのPIDを抽出。
PID_HIGH_TPS=$(iotop -b -n 2 -o | tail -n +3 | sort -k10,10nr | head -n 1 | awk '{print $1}')

これで、PID_HIGH_TPS変数には、最も頻繁なディスク操作を実行しているプロセスのIDが保存されました。このプロセスを徹底的に調べてみましょう！🧐

🗺️ ステップ3：プロセスから物理ディスクまでのパスを追跡する

いよいよ最も興味深い部分です。上記で見つけたPID_HIGH_TPSプロセスが、一体どのファイルにアクセスし、そのファイルはどのパーティションを経由して、どの物理ディスクに保存されているのかを追跡してみましょう。

📝 3-1. プロセスが開いているファイルを見つける

lsof (List Open Files)コマンドを使用すると、特定のプロセスが現在どのファイルを開いているかを確認できます。

# lsofで、該当PIDが開いているファイルのうち、通常ファイル(REG)のパスを見つける。
FILE_PATH=$(lsof -p ${PID_HIGH_TPS} | awk '$4 ~ /REG/ {print $9}' | head -n 1)

上記のコマンドにより、プロセスが現在使用しているファイルの完全なパス(FILE_PATH)を特定しました。

🔗 3-2. ファイルが属するデバイス(Device Mapper)を見つける

ファイルパスが分かったので、dfコマンドでそのファイルがどのファイルシステム(マウントポイント)に属しているかを確認できます。LVM(Logical Volume Manager)を使用している場合、通常は/dev/mapper/形式の論理ボリューム名が表示されます。

# dfコマンドでファイルパスが属するデバイス名を見つける。
DM_DEVICE=$(df ${FILE_PATH} | tail -n 1 | awk '{print $1}')

DM_DEVICE変数には、/dev/mapper/centos-rootのような論理的なデバイス名が保存されます。

💿 3-3. 本当の物理ディスク(Physical Device)を見つける！

最後のステップです！論理的なデバイス名は、実際の物理ディスクを指す名札のようなものです。lsblkとreadlinkを組み合わせて、この論理ボリュームがどの物理パーティション上に作成されたのかを最終的に確認できます。

# lsblkでデバイスマッパー名(DM_DEVICE)が指す実際の物理パーティション名を見つける。
REAL_DEVICE_PARTITION=$(lsblk -no pkname $(readlink -f ${DM_DEVICE}))

# 最終的に見つかった物理デバイスパスをファイルに保存。
echo "/dev/${REAL_DEVICE_PARTITION}" > /opt/devname.txt

readlink -f ${DM_DEVICE}: シンボリックリンクであるデバイス名の元のパスを見つけます。
lsblk -no pkname …: そのデバイスの親カーネル名(pkname)、つまり実際の物理パーティション名を出力します。(例: sda2など)

ついに/opt/devname.txtファイルを開けば、問題を引き起こしていたプロセスが最終的に使用している物理ディスクデバイス名(/dev/sda2など)を確認できます！🎉

✨ まとめ

このように、iotop、lsof、df、lsblkといった基本的なLinuxコマンドをパイプラインで連結し、漠然としていたディスク負荷の原因を、具体的なプロセスIDから実際の物理ディスクまで段階的に追跡する方法を学びました。

このような過程を通じて、システムのボトルネックを正確に把握し、ディスク交換やデータ再配置など、より効果的な解決策を講じることができます。皆さんのシステムに問題が発生した際には、この方法を活用して名探偵のように原因を追跡してみてください！😉