1 / 23

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

アクセス集中時の Web サーバの性能に対する OS の影響. 東京工業大学　千葉研究室 日比野秀章　松沼正浩 光来健一　千葉滋. アクセス集中によるサービスの滞り. あるサイトで、 人気イベントのチケットを販売することにした チケットを購入しようとアクセスが集中 ページの閲覧が急にしづらくなる. ?. チューニングにより調整. 実行スレッド数 JDBC コネクション・プールの設定 クラスタリング デプロイメント・ディスクリプタ. システム変更により問題が生じる E.g. ページを閲覧しづらい 解決するためにはチューニングが必要 手間・労力がかかる

whittaker-jovani
Download Presentation

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

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

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

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

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

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

  5. 予備実験:OSによる挙動の違い • 実行環境 • [サーバマシン] • CPU:Intel Xeon 3.06GHz×2 • メモリ:2GB • ネットワーク:1000BaseTX • [クライアントマシン×14] • CPU:Pentium 733MHz • メモリ:512MB • ネットワーク:100BaseTX • [Web App サーバ] • Tomcat 5.0.25 • [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 サーバの振る舞いが変わってしまった • 一部(OS)の変更により、影響する他の様々なパラメータについても設定を見直さなければならない • 手間・労力がかかる • 実行環境の他の部分でも同様のことが起こると考えられる

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

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

  10. ネットワークの通信の失敗は少ない • どの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はほとんど起きない GCの有無はあまり関係ない

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

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

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

  19. 簡単な制御であれば可能 • 挿入する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]を利用した、サーバの状態に応じた制御

More Related