アクセス集中時の Webサーバの性能に対する OSの影響東京工業大学千葉研究室日比野秀章松沼正浩光来健一千葉滋 1 アクセス集中によるサービスの滞り • あるサイトで、人気イベントのチケットを販売することにした ? • チケットを購入しようとアクセスが集中 • ページの閲覧が急にしづらくなる 2 チューニングにより調整 • システム変更により問題が生じる – E.g. ページを閲覧しづらい Application AP Server • 解決するためにはチューニングが必要 • 手間・労力がかかる JVM OS Hardware – 各種パラメータの調整 •CPU •メモリ •実行スレッド数 •JDBCコネクション・プールの設定 •クラスタリング •デプロイメント・ディスクリプタ •ヒープサイズ •GCの設定 •カーネルパラメータ (ファイル数、プロセス数) •TCP/IPの設定パラメータ •ソケットのバッファサイズ 3 苦労してチューニングしても • 実行環境の変更が要求される – セキュリティの問題によりOSを変更 – 顧客の要望で、OSを変更 – ハードウェアの変更により、ソフトウェアが対応しなくなる – JVMの変更 – 等など・・・挙動が変わってしまう 4 予備実験:OSによる挙動の違い • 対象とする処理 – 軽い処理:フィボナッチ数の計算 – 重い処理:XMLファイルをパースし、 DOMツリーを100回探索 • リクエストの投げ方 – 軽い処理に常時30 – 重い処理に常時1,5,10,20,40 • 対象とするOS 実行環境 [サーバマシン] •CPU:Intel Xeon 3.06GHz×2 •メモリ:2GB •ネットワーク:1000BaseTX [クライアントマシン×14] •CPU:Pentium 733MHz •メモリ:512MB •ネットワーク:100BaseTX [Web App サーバ] – Solaris 9, Linux 2.6.5, FreeBSD 5.2 1, •Tomcat 5.0.25 Windows 2003 Server Enterprise Edition [JVM] •Sun JDK 1.4.2 5 Linux 2.6.5 ×1000 ×1000 500 落ち込まない重い処理 400 60 300 40 200 20 100 0 軽い処理の処理数 0 1 5 10 20 80 400 60 300 0 0 1 400 200 100 20 0 0 10 20 20 40 40 重い処理へのリクエスト数軽い処理重い処理 100 軽い処理の処理数落ち込む ×1000 500 300 5 10 Windows 2003 Server 60 40 5 重い処理へのリクエスト数重い処理の処理数軽い処理の処理数 100 40 軽い処理重い処理 80 200 20 FreeBSD 5.2.1 100 1 落ち込む 40 重い処理へのリクエスト数 ×1000 500 500 80 400 60 300 落ち込む 40 200 100 20 0 0 1 5 10 20 40 重い処理へのリクエスト数重い処理の処理数 80 軽い処理 100 重い処理の処理数軽い処理の処理数 100 軽い処理重い処理重い処理の処理数 Solaris 9 チューニングのやり直し • OSの変更によりWeb App サーバの振る舞いが変わってしまった面倒 • 一部(OS)の変更により、影響する他の様々なパラメータについても設定を見直さなければならない – 手間・労力がかかる • 実行環境の他の部分でも同様のことが起こると考えられる 7 目標と本発表の内容 • 目標 – 実行環境によらず指定した挙動を実現 • 面倒なチューニングを省略 • E.g. Solarisと同様の振る舞いを、様々な実行環境で実現 – 一部の処理(重い処理)の増加時に、他のサービス(軽い処理)への影響が少ない • OS毎に挙動が異なる要因を検証 – 仮説1:ネットワーク処理 – 仮説2:GC – 仮説3:OSのスケジューラ 8 仮説1:ネットワーク処理の影響 • コネクション失敗や再送の頻度を測定 – リクエストの投げ方 • 軽い処理に常時30 • 重い処理に常時40 – パケット送受信の統計情報を調べる • クライアントマシン側でnetstatを使用 9 ネットワークの通信の失敗は少ない Solaris 軽い処理接続数 Linux 重い処理軽い処理重い処理 FreeBSD Windows 軽い処理軽い処理重い処理重い処理 28171 669 1977 834 5945 778 3570 958 0 0 0 0 0 0 0 0 受信セグメント数 140996 3613 10011 4372 29317 4111 17602 5049 送信セグメント数 141196 3723 10080 4485 29981 4218 18145 5208 0 7 0 2 2 4 9 14 接続失敗回数再送回数 • どのOSの場合も – 再送はほとんど起きていない – コネクションの失敗は起きていない 10 仮説1:ネットワーク処理の影響 • ネットワーク処理にかかる時間を測定 – SYNパケットの受信からシステムコールacceptの完了までにかかる時間の計測 – リクエストの投げ方 • 軽い処理にのみ常時30 • 軽い処理に常時30,重い処理に常時80 – SolarisとLinuxで実験 11 ネットワーク処理の処理時間に差はない – 接続失敗回数 – 再送回数 – 処理時間 • ネットワーク処理が要因とは考えにくい軽い処理のみ軽い処理と重い処理 3 処理時間[sec] • SolarisとLinuxであまり違いは見られない 2 1 0 Solaris Linux 12 仮説2:GCによる影響 • GCを止めて同様のプログラムで測定 • 実験① – javaのloggcオプションにより GCの情報を収集 • 数値処理に常時80リクエストを投げる GCの回数 45 40 重い処理数値処理 35 30 • 実験② – 軽い処理と数値処理で予備実験と同様の実験 25 20 15 10 数値処理:フィボナッチ数の計算 (軽い処理より重い計算) 5 0 Solaris Linux FreeBSD Windows 13 Linux 2.6.5 ×1000 ×1000 1000 800 60 600 40 20 400 200 0 0 1 5 10 20 120 100 80 落ち込む 60 40 40 200 0 1 10 40 20 800 600 400 200 0 0 1 5 10 20 40 数値処理へのリクエスト数軽い処理の処理数落ち込む 1200 1000 数値処理の処理数 ×1000 80 60 20 40 Windows 2003 Server ×1000 軽い処理の処理数 5 数値処理へのリクエスト数 FreeBSD 5.2.1 軽い処理数値処理 600 400 20 0 数値処理へのリクエスト数 120 100 1200 1000 800 軽い処理数値処理 120 100 1200 1000 40 予備実験の実験結果と800 600 落ち込む傾向は同じ 400 20 200 80 60 0 0 1 5 10 20 40 数値処理へのリクエスト数数値処理の処理数落ち込まない 1200 軽い処理の処理数軽い処理数値処理数値処理の処理数軽い処理の処理数 120 100 80 軽い処理数値処理数値処理の処理数 Solaris 9 GCが原因とは考えにくい • 重い処理の場合と数値処理の場合で傾向は同じ – 重い処理‥‥GCが頻発 – 数値処理‥‥GCはほとんど起きない GCの有無はあまり関係ない 15 仮説3:OSのスケジューラ • スケジューリングの待ち時間を測定 – リクエストの受信から、実際のJavaプログラムが実行を開始するまでの時間 – 特にカーネル内のシステムコールでのスケジューリングカーネル内処理（実行待ち） Javaプログラム CPUのみ accept poll の完了 recv ・・・ 16 スケジューリングが要因の可能性大軽い処理のみ • リクエストの投げ方 • SolarisとLinuxで実験軽い処理の処理時間 – 軽い処理にのみ常時30 – 軽い処理に常時30, 重い処理に常時80 秒カーネル内処理秒軽い処理の処理時間 • スケジューリングの頻度が高い箇所で処理時間長 Solaris 9 16 14 12 10 8 6 4 2 0 • 実験結果 – Linuxでは、カーネル内の処理時間が長い軽い処理と重い処理 Javaプログラム Linux 2.6.5 16 14 12 10 8 6 4 2 0 カーネル内処理 Javaプログラム 17 スケジューラの違いが原因だとすると • アプリケーションレベルでスケジューリングすれば、実行環境によらずに同じポリシーで動作できる • 簡易制御 – sleep命令を挿入することで強制的に重い処理のスケジューリング頻度を下げる • 実験方法 – リソースを大量に使用する処理(重い処理)を一時停止 • 一時停止しない(S0) • 重い処理の毎回の探索の終り – 毎回の停止時間は20,40,60,80,100ms (S2,S4,S6,S8,S10) – リクエストの投げ方 • 軽い処理に常時30 • 重い処理に常時20 18 Solaris 9 400 60 300 40 200 20 100 0 0 S0 S2 S4 S6 S8 80 400 60 300 40 200 20 100 0 S10 0 S0 sleepの入れ方 ×1000 100 300 40 200 20 100 0 0 S2 S4 S6 S8 sleepの入れ方 S10 軽い処理の処理数 400 重い処理の処理数軽い処理の処理数軽い処理重い処理 60 S0 S4 S6 S8 S10 Windows 2003 Server 500 80 S2 sleepの入れ方 FreeBSD 5.2.1 ×1000 100 500 500 軽い処理重い処理 80 400 60 300 40 200 20 100 0 0 S0 S2 S4 S6 S8 sleepの入れ方 S10 重い処理の処理数 80 軽い処理の処理数軽い処理重い処理軽い処理重い処理重い処理の処理数 ×1000 100 500 重い処理の処理数軽い処理の処理数 ×1000 100 Linux 2.6.5 簡単な制御であれば可能 • 挿入するsleepの長さ次第で、OS毎の挙動の違いを埋められる可能性有 – Sleep命令挿入により • 軽い処理増 • 重い処理減 20 まとめ • 目標 – 実行環境によらず指定した挙動を実現したい • 予備実験 – Web App サーバの振る舞いが実行環境の影響を強くうけることを例示 • 要因検証の実験 – Web App サーバの振る舞いにOSのスケジューラが強い影響を与えている可能性が高い • 有効性確認の実験 – アプリケーションレベルのスケジューリング 21 今後の課題：要因の検証 • Web App サーバの振る舞いに強く影響する要因をさらに検証 – スケジューリングの検証はLinuxでしか行えていないが、他のOSでも検証 – 各スレッドのスケジューリングのされ方を調査 • タイムスライスとスケジュールの頻度 – 各OSでのスケジューリングポリシーの調査 – 他のリソースを使用する処理(ディスク等)についても同様に実験を行い、OS別で比較 22 今後の課題：スケジューラ • 様々な実行環境でユーザーが指定した挙動が得られるようにする – アプリケーションレベルでのスケジューリング • 例えば、検証実験で行ったsleep命令を利用した制御 – sleep命令の長さ、頻度、場所の検討が必要 • Progress-based regulation [J.R.Doucer 99]を利用した、サーバの状態に応じた制御 23