Webエンジニアが知っておきたいインフラの基本 #7 ボトルネックの見つけ方

webシステムのキャパシティ向上とは?

  • 単位時間あたりの処理性能を上げる
  • 単位時間あたりの所要処理量を上げる
単位時間あたりの所要処理量 = 単位時間あたりのアクセス数 x 1アクセスの処理量

普通はアクセス数は減らせないので、処理量を減らす方向に

ターゲットとゴールを決める

  • ターゲット : 何を改善するのか?
  • ゴール : 目標とする数値

ボトルネックにアプローチする

全体のキャパシティはボトルネックで決まる ボトルネックの解消を再優先に対応する

ボトルネックの見つけ方(基礎編)

データフローのポイントごとに処理内容を確認する

  • プログラム外との通信箇所と内容(DBなど)
  • プログラムの外部呼び出し(exec関数、system関数)
  • 外部システムとの通信(API呼び出しなど)
  • ディスクの読み書き箇所と内容
  • 配列やリストのサイズが大きすぎないか?
  • ループの回数が多すぎないか?

システムリソースを確認する

  • 特定項目の特定の時間帯にとらわれ過ぎない
    • とにかく俯瞰すること
  • CPU性能、メモリ、ネットワーク帯域、ディスクを使い切っていないか?
  • 制約が強すぎて、性能を発揮できていないか?
    • 殆どのミドルウェアはサーバリソースを使い過ぎないように制約が掛かっている
    • 歴史のあるミドルウェアは大体デフォルトの制約が強い

ボトルネックの見つけ方(ログ編)

Apache

  • 1アクセス毎の所要時間を出力するように設定
  • 所要時間 x アクセス数が大きい処理を探す

Mysql

  • スロークエリログを見る

ボトルネックの見つけ方(サーバリソース編)

  • cacti
    • 値が一定値に張り付いたまま : 性能上限まで使い切っている場合がある
    • 前日、先週、先月の同時刻と著しく値の動きが異なる
    • 値の変動が激しい
  • top, dstat
    • Cpu* の値が100に張り付いたまま : CPUリソースが足りていない
    • Userが多すぎる : アプリケーションの処理量が多すぎる
    • Systemが多すぎる : アプリケーションの効率化を検討する
      • メモリを使いすぎている、NFSアクセスが多すぎる等
    • Iowaitが多すぎる : iostatで更に原因を調査する
      • ディスクアクセスが多い? 等
    • dstatでpagigが頻発 : メモリ不足