この記事の監修：宮崎智広（Linux実務・教育歴20年以上・受講者3,100名超）
そう言われて、とりあえずカーネルパラメータを変更し、swappinessを下げ、CPUガバナーをperformanceにしてみた——そういう経験をしたことがある方は多いと思います。
この記事では、20年以上Linuxサーバーを運用してきた経験から、パフォーマンスチューニングの「正しい入り口」を解説します。
チューニングのテクニックを覚える前に知っておくべき思考の型と、計測なき改善がなぜ現場で危険なのかをお伝えします。
この記事のポイント
・チューニングの前に「何が遅いか」を計測で特定することが絶対条件
・感覚やネット情報だけの変更は設定が複雑化し障害の原因になる
・top・vmstat・iostatの3コマンドで原因カテゴリを絞り込める
・チューニングは「変更前の状態を記録する」ことから始まる
でも安心してください。プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
「とりあえずチューニング」が現場で問題になる理由
私がSEとして働いていた頃（2001年～2006年）、先輩から言われた言葉があります。「問題が何かも分からないうちに設定を変えるのは、暗闇の中で壁を叩き続けるようなものだ」と。
当時は「そんなものか」と思っていましたが、20年以上現場を経験した今、この言葉の重みが本当によく分かります。
パフォーマンスチューニングには、大きく分けて2種類の失敗があります。
1つ目は「変えた設定が何だったか分からなくなる」失敗です。
ネットで見つけた設定値を複数のファイルにあちこち書いていくうちに、どのパラメータが何の意味を持っていたのかを追えなくなり、問題が起きても元に戻せない状態になります。
2つ目は「改善したように見えて実は悪化している」失敗です。
swappinessを下げてメモリを積極利用させたら、今度はOOMKillerが動くようになった——こういう副作用は、計測なしに変更した場合に起きがちです。
私のセミナーには3,100名以上の方が参加されてきましたが、「チューニングしたら返って遅くなった」という相談は今も定期的に来ます。
原因の8割は「計測より前に変更した」ことです。
まず「ボトルネックの種類」を特定する
Linuxサーバーのパフォーマンス問題には、大きく4つのボトルネックカテゴリがあります。・CPU：処理が多すぎてCPUが飽和している
・メモリ：物理RAMが不足してスワップが発生している
・ディスクI/O：読み書きが詰まってプロセスが待ち状態になっている
・ネットワーク：帯域が逼迫しているか、TCP接続の遅延が発生している
重要なのは、「遅い」という症状は全てのカテゴリに共通してあらわれる、という点です。
CPUが原因でもメモリが原因でも、サーバーは「遅い」という形でしか症状を見せません。
だからこそ、計測によるカテゴリの特定が先なのです。
1. topコマンドで最初の状況をつかむ
最初に確認するのは `top` コマンドです。# リアルタイムでCPU・メモリ・プロセスを確認する top # 1秒おきに更新（より細かく確認したい場合） top -d 1
top - 14:23:41 up 12 days, 3:17, 2 users, load average: 4.23, 3.87, 3.45 Tasks: 218 total, 3 running, 215 sleeping, 0 stopped, 0 zombie %Cpu(s): 87.3 us, 5.2 sy, 0.0 ni, 4.1 id, 3.4 wa, 0.0 hi, 0.0 si, 0.0 st MiB Mem : 7821.4 total, 234.6 free, 6109.8 used, 1477.0 buff/cache MiB Swap: 2048.0 total, 1023.4 free, 1024.6 used. 412.8 avail Mem
・load average：1分・5分・15分の平均負荷。CPUコア数を超えていると飽和
・%Cpu wa（iowait）：ここが高ければディスクI/Oが原因の可能性が高い
・MiB Swap used：スワップが大量消費されていればメモリ不足
・id（idle）：4.1%しか余裕がなく、CPU飽和状態
2. vmstatで継続的な推移を確認する
topは瞬間値ですが、`vmstat` は経時的な変化を追えます。# 3秒おきに5回出力する vmstat 3 5
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu----- r b swpd free buff cache si so bi bo in cs us sy id wa st 3 2 45312 23456 12344 876543 128 342 456 234 1234 5678 82 8 2 8 0 4 1 47890 18234 12100 875000 256 512 890 445 2345 8901 85 9 1 5 0
si/soが継続的にゼロでなければメモリが足りていないサインです。
3. iostatでディスクI/Oを確認する
topとvmstatでI/O待ちが疑われた場合は、`iostat` で絞り込みます。# 拡張統計で2秒おきに確認 iostat -xz 2
Device r/s w/s rMB/s wMB/s await r_await w_await %util sda 45.2 234.1 1.23 12.45 120.3 23.4 145.6 98.2
`await`（平均待ち時間）が100ms以上になると、アプリケーションはディスク待ちで明らかに詰まっています。
計測結果を「記録する」ことがチューニングの起点になる
ボトルネックのカテゴリを特定したら、次にやるべきことは「変更前の状態を記録する」ことです。私が現場でよく見かけるのが、「改善した気がするけど数値で確認していない」というケースです。
チューニングとは比較の作業であり、ビフォーアフターの数値がなければ、改善したかどうかが分かりません。
記録すべき最低限の項目はこちらです。
・計測日時・サーバー負荷状況：いつの、どんな状況でのデータか
・topの出力：load average・CPU%・メモリ使用量
・vmstat 5 3 の出力：5秒おき3回分
・変更したファイル名と変更前の内容：diff で残す
この記録があると、「変更後に悪化した」場合に確実に戻せます。
戻せる状態を保つことは、私がセミナーで必ず伝える「可逆性」という考え方の根本です。
チューニング前に確認すべき3つの事実
1. 「いつから遅くなったか」を調べる
突然遅くなったのか、じわじわ遅くなったのかで、原因のアプローチが変わります。突然の場合 → デプロイ・設定変更・バッチ追加などのイベントが起きていないか確認
じわじわの場合 → データ増加・アクセス増加・リソースリークがないか確認
`sar` コマンドで過去の記録を確認できます。
# 昨日のCPU使用率を時系列で確認 sar -u -f /var/log/sa/sa$(date -d "yesterday" +%d) # 過去7日分のメモリ使用量を確認 sar -r -f /var/log/sa/sa$(date -d "7 days ago" +%d)
2. 「何のプロセスが原因か」を特定する
サーバー全体が遅いのか、特定プロセスが原因なのかを確認します。# CPU使用率の高いプロセスを上から10件表示 ps aux --sort=-%cpu | head -11 # メモリ使用量の高いプロセスを上から10件表示 ps aux --sort=-%mem | head -11
サーバー全体のチューニングより、そのプロセスを直す方が効果的な場合がほとんどです。
3. 「アプリ側の問題ではないか」を先に疑う
OS側のチューニングを急ぐ前に、アプリケーション層の問題である可能性を先に排除することを推奨します。・SQLのN+1問題やフルスキャンがDBを詰まらせていないか
・Webサーバーのリクエストキューが溢れていないか
・ファイルディスクリプタの上限に達していないか
OS側のチューニングで解決できる問題は、現場では意外と少ないのが実態です。
チューニング作業の「正しい手順」をまとめる
ここまでの内容を整理します。正しいチューニングの手順は以下の通りです。| 順番 | やること | 使うコマンド・方法 |
|---|---|---|
| 1 | 症状と時系列を確認する | sar、アプリログ、デプロイ履歴 |
| 2 | 変更前の状態を計測・記録する | top、vmstat 5 3、iostat -xz |
| 3 | ボトルネックカテゴリを絞り込む | CPU/メモリ/I/O/ネットワークを判別 |
| 4 | 原因プロセスを特定する | ps aux、lsof、iotop |
| 5 | アプリ側の問題を排除する | DBクエリ確認、ログ確認 |
| 6 | 変更内容をdiffで記録してから適用する | diff、バックアップ作成 |
| 7 | 変更後に同じ計測を行い比較する | 2と同じコマンドで数値比較 |
「計測したのに原因が分からない」時のトラブルシュート
top・vmstat・iostatを確認しても、明確なボトルネックが見えないケースがあります。そういう時に私がよく使う追加の確認手順を紹介します。
1. dmesgでカーネルのエラーを確認する
ハードウェア障害やOOMKillerの発動は、アプリログには残りません。dmesgで確認します。
# カーネルログをタイムスタンプ付きで確認 $ dmesg -T | tail -50 # OOMKillerが発動していないか確認 $ dmesg -T | grep -i "out of memory\|oom"
[Thu May 8 03:12:44 2026] Out of memory: Killed process 4523 (mysqld) total-vm:2097152kB
2. netstatでTCPの状態を確認する
Webアプリケーションで遅延が出る場合、ネットワーク接続数の問題であることがあります。# TCPの状態別接続数を確認 $ ss -s # CLOSE_WAITが大量にないか確認（サーバー側のコネクションリーク） $ ss -nt | grep CLOSE_WAIT | wc -l
OSチューニングより、アプリ修正の方が根本対策になります。
3. 現在のカーネルパラメータを確認してから判断する
「swappinessを下げればいい」と聞いて変更する前に、現在の設定値を確認することが重要です。# swappinessの現在値を確認（デフォルトは60） $ sysctl vm.swappiness # vm.swappiness = 60 # vfs_cache_pressureの現在値を確認 $ sysctl vm.vfs_cache_pressure # vm.vfs_cache_pressure = 100
パラメータを変更する場合も、変更前の値を必ずメモしてから行いましょう。
「チューニングしないこと」が最良の判断になるケースもある
20年以上の運用経験で確信していることがあります。「チューニングしない」という判断が最善の場合も少なくない、ということです。
計測した結果、CPUもメモリもI/Oも正常で、遅いのが「一部の時間帯だけ」「特定のバッチ実行中だけ」だったとすれば、チューニングよりもバッチの実行時間を変えるだけで解決することがあります。
また、計測の結果「スペックが根本的に足りない」と分かった場合は、チューニングで時間を費やすより、スケールアップの判断を上長に上げる方がエンジニアとしての仕事です。
受講生からよく聞かれる質問が「どこまでチューニングすればいいですか」ですが、私の答えは「計測値が要件を満たしていればやめていい」です。
SLA（サービスレベル合意）や応答時間の目標値と計測値を照らし合わせ、満たしているなら追いかけ続ける必要はありません。
まとめ
この記事でお伝えしたかったことをまとめます。・チューニングは計測が先：top・vmstat・iostatで現状を記録してから始める
・ボトルネックカテゴリを特定する：CPU/メモリ/I/O/ネットワークのどれかを絞り込む
・変更前のdiffと記録は必須：戻せる状態を維持することが安全の基本
・アプリ層の問題を先に排除する：OS設定変更より先に原因を確認する
・「チューニングしない」も判断のひとつ：計測値が要件を満たしていれば追わない
パフォーマンスチューニングの技術そのものは、vmstat・sar・iostatの詳細な読み方や、カーネルパラメータの意味まで奥が深い領域です。
ただ、それらの技術を学ぶ前に「計測→特定→記録→変更→検証」という思考の型を持つことが、現場で信頼されるエンジニアになるための第一歩だと私は考えています。
計測から始めて、現場で通用するサーバー管理の「型」を身につけたいあなたへ
チューニングも障害対応も、根本は「現状を正しく計測して、根拠のある判断をする」という思考の積み重ねです。
現場で通用する安全なLinuxサーバー構築の「型」を体系的に身につけたい方へ、'Linuxサーバー構築入門マニュアル（図解60P）'を完全無料でプレゼントしています。
「独学の時間がもったいない」「プロから直接、現場の技術を最短で学びたい」という本気の方には、2日で実務レベルのスキルが身につく【初心者向けハンズオンセミナー】も開催しています。
3,100名以上が実践した「型」を無料で公開中
プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
その「型」を図解60Pにまとめた入門マニュアルを、完全無料でプレゼントしています。
登録10秒／合わなければ解除3秒 ／ 詳細はこちら
この記事を書いた人
宮崎 智広（みやざき ともひろ）
株式会社イーネットマーキュリー代表。現役のLinuxサーバー管理者として15年以上の実務経験を持ち、これまでに累計3,100名以上のエンジニアを指導してきたLinux教育のプロフェッショナル。「現場で本当に使える技術」を体系的に伝えることをモットーに、実践型のLinuxセミナーの開催や無料マニュアルの配布を通じてLinux人材の育成に取り組んでいる。
趣味は、キャンプにカメラ、トラウト釣り。好きな食べ物は、ラーメンにお酒。休肝日が作れない、酒量を減らせないのが悩み。最近、ドラマ「フライトエンジェル」を観て涙腺が崩壊しました。
- 次のページへ：Linuxの教科書には書いていない現場のリアル｜20年以上の運用経験で気づいた「知識」と「使える力」の差
- 前のページへ：Linuxの勉強記録を続けてきた人が3年後に驚くほど差がつく理由｜現役講師が語る自己振り返りの技術
- この記事の属するカテゴリ：Linux学習ガイドへ戻る
無料メルマガで学習を続ける
Linuxの実践スキルをメールで毎週お届け。
登録は1分、解除もいつでも可。
登録無料・いつでも解除できます