Download - アクセス集中時の Web サーバの性能に対する OS の影響
1
アクセス集中時のWebサーバの性能に対する
OSの影響
東京工業大学 千葉研究室日比野秀章 松沼正浩光来健一 千葉滋
2
アクセス集中によるサービスの滞り
• あるサイトで、人気イベントのチケットを販売することにした
• チケットを購入しようとアクセスが集中
• ページの閲覧が急にしづらくなる
?
3
チューニングにより調整• システム変更により問題が生じる– E.g. ページを閲覧しづらい
• 解決するためにはチューニングが必要
• 手間・労力がかかる– 各種パラメータの調整
Hardware
OS
JVM
AP Server
Application
•カーネルパラメータ (ファイル数、プロセス数 )•TCP/IPの設定パラメータ•ソケットのバッファサイズ
•ヒープサイズ•GCの設定
•実行スレッド数•JDBCコネクション・プールの設定•クラスタリング•デプロイメント・ディスクリプタ
•CPU•メモリ
4
苦労してチューニングしても
• 実行環境の変更が要求される–セキュリティの問題により OSを変更– 顧客の要望で、 OSを変更–ハードウェアの変更により、ソフトウェアが対応しなくなる
– JVMの変更– 等など・・・
挙動が変わってしまう
5
予備実験 :OSによる挙動の違い
• 対象とする処理– 軽い処理 :フィボナッチ数の計算– 重い処理 :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
実行環境
[サーバマシン ]
•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
Solaris 9
0
20
40
60
80
100
1 5 10 20 40
× 1000
重い処理へのリクエスト数
軽い処理の処理数
0
100
200
300
400
500
重い処理の処理数
軽い処理
重い処理
Linux 2.6.5
0
20
40
60
80
100
1 5 10 20 40
× 1000
重い処理へのリクエスト数
軽い処理の処理数
0
100
200
300
400
500
重い処理の処理数
軽い処理重い処理
FreeBSD 5.2.1
0
20
40
60
80
100
1 5 10 20 40
× 1000
重い処理へのリクエスト数
軽い処理の処理数
0
100
200
300
400
500重い処理の処理数
軽い処理重い処理
Windows 2003 Server
0
20
40
60
80
100
1 5 10 20 40
× 1000
重い処理へのリクエスト数
軽い処理の処理数
0
100
200
300
400
500
重い処理の処理数
軽い処理重い処理
落ち込む
落ち込まない
落ち込む
落ち込む
7
チューニングのやり直し
• OSの変更によりWeb App サーバの振る舞いが変わってしまった
• 一部 (OS)の変更により、影響する他の様々なパラメータについても設定を見直さなければならない– 手間・労力がかかる
• 実行環境の他の部分でも同様のことが起こると考えられる
面倒
8
目標と本発表の内容
• 目標– 実行環境によらず指定した挙動を実現
• 面倒なチューニングを省略• 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
接続失敗回数 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
11
仮説 1:ネットワーク処理の影響
• ネットワーク処理にかかる時間を測定
– SYNパケットの受信からシステムコールacceptの完了までにかかる時間の計測
–リクエストの投げ方• 軽い処理にのみ常時 30
• 軽い処理に常時 30,重い処理に常時 80
– Solarisと Linuxで実験
12
ネットワーク処理の処理時間に差はない
• Solarisと Linuxであまり違いは見られない– 接続失敗回数– 再送回数– 処理時間
• ネットワーク処理が要因とは考えにくい
0
1
2
3
[sec
]処理時間
軽い処理のみ 軽い処理と重い処理
Solaris Linux
13
仮説 2:GCによる影響
• 実験①– javaの loggcオプションにより GCの情報を収集
• 数値処理に常時 80リクエストを投げる
• 実験②– 軽い処理と数値処理で予備実験と同様の実験
数値処理 :フィボナッチ数の計算 (軽い処理より重い計算 )
0
5
10
15
20
25
30
35
40
45
Solaris Linux FreeBSD Windows
GCの回数
重い処理数値処理
• GCを止めて同様のプログラムで測定
Windows 2003 Server
0
20
40
60
80
100
120
1 5 10 20 40
× 1000
数値処理へのリクエスト数
軽い処理の処理数
0
200
400
600
800
1000
1200
数値処理の処理数
軽い処理数値処理
Solaris 9
0
20
40
60
80
100
120
1 5 10 20 40
× 1000
数値処理へのリクエスト数
軽い処理の処理数
0
200
400
600
800
1000
1200
数値処理の処理数
軽い処理数値処理
Linux 2.6.5
0
20
40
60
80
100
120
1 5 10 20 40
× 1000
数値処理へのリクエスト数
軽い処理の処理数
0
200
400
600
800
1000
1200
数値処理の処理数
軽い処理数値処理
FreeBSD 5.2.1
0
20
40
60
80
100
120
1 5 10 20 40
× 1000
数値処理へのリクエスト数
軽い処理の処理数
0
200
400
600
800
1000
1200数値処理の処理数軽い処理数値処理
落ち込まない 落ち込む
落ち込む 落ち込む予備実験の実験結果と
傾向は同じ
15
GCが原因とは考えにくい
• 重い処理の場合と数値処理の場合で傾向は同じ– 重い処理‥‥ GCが頻発– 数値処理‥‥ GCはほとんど起きない
GCの有無はあまり関係ない
16
仮説 3:OSのスケジューラ
• スケジューリングの待ち時間を測定–リクエストの受信から、実際の Javaプログラムが実行を開始するまでの時間
– 特にカーネル内のシステムコールでのスケジューリング
acceptの完了
poll recv ・・・
CPUのみ
カーネル内処理(実行待ち)
Javaプログラム
17
スケジューリングが要因の可能性大
• リクエストの投げ方– 軽い処理にのみ常時 30– 軽い処理に常時 30,重い処理に常時 80
• Solarisと Linuxで実験
• 実験結果– Linuxでは、カーネル内の処理時間が長い
• スケジューリングの頻度が高い箇所で処理時間長
Linux 2.6.5
02468
10121416
秒
軽い処理の処理時間
Solaris 9
02468
10121416
秒
軽い処理の処理時間
軽い処理のみ 軽い処理と重い処理
カーネル内処理 Javaプログラム
カーネル内処理
Javaプログラム
18
スケジューラの違いが原因だとすると
• アプリケーションレベルでスケジューリングすれば、実行環境によらずに同じポリシーで動作できる
• 簡易制御– sleep命令を挿入することで強制的に重い処理のスケジューリング頻度を下げる
• 実験方法– リソースを大量に使用する処理 (重い処理 )を一時停止
• 一時停止しない (S0)• 重い処理の毎回の探索の終り
– 毎回の停止時間は 20,40,60,80,100ms (S2,S4,S6,S8,S10)
– リクエストの投げ方• 軽い処理に常時 30• 重い処理に常時 20
Solaris 9
0
20
40
60
80
100
S0 S2 S4 S6 S8 S10
× 1000
sleepの入れ方
軽い処理の処理数
0
100
200
300
400
500
重い処理の処理数
軽い処理重い処理
FreeBSD 5.2.1
0
20
40
60
80
100
S0 S2 S4 S6 S8 S10
× 1000
sleepの入れ方
軽い処理の処理数
0
100
200
300
400
500重い処理の処理数
軽い処理重い処理
Linux 2.6.5
0
20
40
60
80
100
S0 S2 S4 S6 S8 S10
× 1000
sleepの入れ方
軽い処理の処理数
0
100
200
300
400
500
重い処理の処理数
軽い処理重い処理
Windows 2003 Server
0
20
40
60
80
100
S0 S2 S4 S6 S8 S10
× 1000
sleepの入れ方
軽い処理の処理数
0
100
200
300
400
500
重い処理の処理数
軽い処理重い処理
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]を利用した、サーバの状態に応じた制御