アクセス集中時の Webサーバの性能に対する OSの影響

Presentation on theme: "アクセス集中時の Webサーバの性能に対する OSの影響"— Presentation transcript:

1 アクセス集中時の Webサーバの性能に対する OSの影響
東京工業大学　千葉研究室 日比野秀章　松沼正浩 光来健一　千葉滋

2 アクセス集中によるサービスの滞り あるサイトで、 人気イベントのチケットを販売することにした チケットを購入しようとアクセスが集中
ページの閲覧が急にしづらくなる ?

3 チューニングにより調整 システム変更により問題が生じる 解決するためにはチューニングが必要 手間・労力がかかる
実行スレッド数 JDBCコネクション・プールの設定 クラスタリング デプロイメント・ディスクリプタ システム変更により問題が生じる E.g. ページを閲覧しづらい 解決するためにはチューニングが必要 手間・労力がかかる 各種パラメータの調整 Application AP Server ヒープサイズ GCの設定 JVM OS カーネルパラメータ (ファイル数、プロセス数) TCP/IPの設定パラメータ ソケットのバッファサイズ Hardware CPU メモリ

4 苦労してチューニングしても 実行環境の変更が要求される セキュリティの問題によりOSを変更 顧客の要望で、OSを変更
ハードウェアの変更により、ソフトウェアが対応しなくなる JVMの変更 等など・・・ 挙動が変わってしまう

5 予備実験:OSによる挙動の違い 対象とする処理 リクエストの投げ方 対象とするOS 軽い処理:フィボナッチ数の計算
実行環境 [サーバマシン] CPU:Intel Xeon 3.06GHz×2 メモリ:2GB ネットワーク:1000BaseTX [クライアントマシン×14] CPU:Pentium 733MHz メモリ:512MB ネットワーク:100BaseTX [Web App サーバ] Tomcat [JVM] Sun JDK 1.4.2 対象とする処理 軽い処理:フィボナッチ数の計算 重い処理:XMLファイルをパースし、 DOMツリーを100回探索 リクエストの投げ方 軽い処理に常時30 重い処理に常時1,5,10,20,40 対象とするOS Solaris 9, Linux 2.6.5, FreeBSD 5.2 1, Windows 2003 Server Enterprise Edition

6 落ち込まない 落ち込む 落ち込む 落ち込む

7 面倒 チューニングのやり直し OSの変更によりWeb App サーバの振る舞いが変わってしまった
手間・労力がかかる 実行環境の他の部分でも同様のことが起こると考えられる 面倒

8 目標と本発表の内容 目標 OS毎に挙動が異なる要因を検証 実行環境によらず指定した挙動を実現 仮説1:ネットワーク処理 仮説2:GC
面倒なチューニングを省略 E.g. Solarisと同様の振る舞いを、様々な実行環境で実現 一部の処理(重い処理)の増加時に、他のサービス(軽い処理)への影響が少ない OS毎に挙動が異なる要因を検証 仮説1:ネットワーク処理 仮説2:GC 仮説3:OSのスケジューラ

9 仮説1:ネットワーク処理の影響 コネクション失敗や再送の頻度を測定 リクエストの投げ方 パケット送受信の統計情報を調べる 軽い処理に常時30
重い処理に常時40 パケット送受信の統計情報を調べる クライアントマシン側でnetstatを使用

10 ネットワークの通信の失敗は少ない どのOSの場合も Solaris Linux FreeBSD Windows 再送はほとんど起きていない
軽い 処理 重い処理 重い 処理 接続数 28171 669 1977 834 5945 778 3570 958 接続失敗回数 受信セグメント数 140996 3613 10011 4372 29317 4111 17602 5049 送信セグメント数 141196 3723 10080 4485 29981 4218 18145 5208 再送回数 7 2 4 9 14 どのOSの場合も 再送はほとんど起きていない コネクションの失敗は起きていない

11 仮説1:ネットワーク処理の影響 ネットワーク処理にかかる時間を測定
SYNパケットの受信からシステムコールacceptの完了までにかかる時間の計測 リクエストの投げ方 軽い処理にのみ常時30 軽い処理に常時30,重い処理に常時80 SolarisとLinuxで実験

12 ネットワーク処理の処理時間に 差はない SolarisとLinuxであまり違いは見られない ネットワーク処理が要因とは考えにくい
接続失敗回数 再送回数 処理時間 ネットワーク処理が要因とは考えにくい Solaris Linux

13 仮説2:GCによる影響 GCを止めて同様のプログラムで測定 実験① 実験② javaのloggcオプションによりGCの情報を収集
数値処理に常時80リクエストを投げる 実験② 軽い処理と数値処理で予備実験と同様の実験 数値処理:フィボナッチ数の計算(軽い処理より重い計算)

14 落ち込まない 落ち込む 予備実験の実験結果と 傾向は同じ 落ち込む 落ち込む

15 GCが原因とは考えにくい 重い処理の場合と数値処理の場合で 傾向は同じ GCの有無はあまり関係ない 重い処理‥‥GCが頻発

16 仮説3:OSのスケジューラ スケジューリングの待ち時間を測定 リクエストの受信から、実際のJavaプログラムが実行を開始するまでの時間
特にカーネル内のシステムコールでのスケジューリング カーネル内処理（実行待ち） Javaプログラム CPUのみ acceptの完了 poll recv ・・・

17 スケジューリングが要因の可能性大 リクエストの投げ方 SolarisとLinuxで実験 実験結果
軽い処理にのみ常時30 軽い処理に常時30, 重い処理に常時80 SolarisとLinuxで実験 実験結果 Linuxでは、カーネル内の処理時間が長い スケジューリングの頻度が高い箇所で処理時間長 カーネル内処理 Javaプログラム カーネル内処理 Javaプログラム

18 スケジューラの違いが原因だとすると アプリケーションレベルでスケジューリングすれば、実行環境によらずに同じポリシーで動作できる 簡易制御
sleep命令を挿入することで強制的に重い処理のスケジューリング頻度を下げる 実験方法 リソースを大量に使用する処理(重い処理)を一時停止 一時停止しない(S0) 重い処理の毎回の探索の終り 毎回の停止時間は20,40,60,80,100ms　(S2,S4,S6,S8,S10) リクエストの投げ方 軽い処理に常時30 重い処理に常時20

19

20 簡単な制御であれば可能 挿入するsleepの長さ次第で、OS毎の挙動の違いを埋められる可能性有 Sleep命令挿入により 軽い処理増
重い処理減

21 まとめ 目標 予備実験 要因検証の実験 有効性確認の実験 実行環境によらず指定した挙動を実現したい
Web App サーバの振る舞いが実行環境の影響を強くうけることを例示 要因検証の実験 Web App サーバの振る舞いにOSのスケジューラが強い影響を与えている可能性が高い 有効性確認の実験 アプリケーションレベルのスケジューリング

22 今後の課題：要因の検証 Web App サーバの振る舞いに強く影響する要因をさらに検証
スケジューリングの検証はLinuxでしか行えていないが、他のOSでも検証 各スレッドのスケジューリングのされ方を調査 タイムスライスとスケジュールの頻度 各OSでのスケジューリングポリシーの調査 他のリソースを使用する処理(ディスク等)についても同様に実験を行い、OS別で比較

23 今後の課題：スケジューラ 様々な実行環境でユーザーが指定した挙動が得られるようにする アプリケーションレベルでのスケジューリング
例えば、検証実験で行ったsleep命令を利用した制御 sleep命令の長さ、頻度、場所の検討が必要 Progress-based regulation [J.R.Doucer 99]を利用した、サーバの状態に応じた制御