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]を利用した、サーバの状態に応じた制御