iostat await svctm の見かた、考え方

iostat の await, svctm の見かた、考え方

2

免責事項／注意事項

本資料において示されている見解は、私自身 ( 柴田歩 )の見解であり、 Oracle Corporation 及び日本オラクル社の見解を必ずしも反映したものではありません。予めご了承ください。

3

1 章 . 前提知識

4

下記は iostat -x のログのサンプルiostat -x 1

：avg-cpu: %user %nice %system %iowait %steal %idle 0.76 0.00 0.51 1.52 0.00 97.22

Device: rrqm/s … rsec/s wsec/s avgrq-sz avgqu-sz await svctm %utilsda 0.00 … 2000.00 88.00 208.80 0.14 13.70 8.00 8.00sdb 0.00 … 0.00 24.00 8.00 0.09 31.33 21.67 6.50

avg-cpu: %user %nice %system %iowait %steal %idle 0.76 0.00 0.51 0.25 0.00 98.48

Device: rrqm/s … rsec/s wsec/s avgrq-sz avgqu-sz await svctm %utilsda 0.00 … 2000.00 0.00 666.67 0.01 2.00 1.33 0.40sdb 0.00 … 0.00 0.00 0.00 0.00 0.00 0.00 0.00：

iostat のログ ( サンプル )

5

下記は iostat -x のログのサンプルiostat -x 1



avg-cpu: %user %nice %system %iowait %steal %idle 0.76 0.00 0.51 0.25 0.00 98.48

Device: rrqm/s … rsec/s wsec/s avgrq-sz avgqu-sz await svctm %utilsda 0.00 … 2000.00 0.00 666.67 0.01 2.00 1.33 0.40sdb 0.00 … 0.00 0.00 0.00 0.00 0.00 0.00 0.00：

await と svctm に注目

ここに注目

6

考え方はこのモデル (M/M/1 待ち行列 )

実作業担当者受付

お客様

お客様

お客様

7

Linux/UNIX なシステムに当てはめると、こう。

HDD/SSD/ストレージ等

OS のデバイス/dev/sda

ユーザプロセス


ユーザプロセスLU#1sda

※ 実際のシステムの I/O はもっと複雑ですが、解り易くするために抽象化して書いてます。

8

svctm の考え方






OS のデバイスからストレージ ( 等 )に

投げられた I/O リクエストが返ってくるまでレスポンスタイム

sda LU#1

9

await の考え方






複数のユーザープロセスから OS のデバイスに投げられた I/O リクエストが返ってくるまでの " 平均 " レスポンス

タイム(※ 一般的に svctm を包含する。 )

sda LU#1

10

2 章 . I/O 遅延のパターン①リクエスト数が多い。

11

I/O 遅延のパターン①・リクエスト数が多い






数が多過ぎて捌き切れない！

僕は楽勝～～♪

遅いなぁ…svctm は良好だが、

await が悪くなるケース

LU#1sda

12

下記は iostat -x のログのサンプル ※数字もサンプルです。iostat -x 1



：

この状況の時の iostat ログ

await >>> svctm な状況

13

M/M/1 待ち行列

14

M/M/1 の公式

IT Pro ネットワークの数学 M/M/1 より引用

http://itpro.nikkeibp.co.jp/

article/COLUMN/20060920/248528/

15

M/M/1 の公式と svctm 、 await の関係

svctm に相当await に相当

IT Pro ネットワークの数学 M/M/1 より引用

http://itpro.nikkeibp.co.jp/

article/COLUMN/20060920/248528/

16

下記の仮定を M/M/1 公式に当てはめてグラフ化すると……

M/M/1 の公式に下記の仮定を当てはめると…

変数名定義

ρ(到着率 ) λ÷μ

単位時間 1sec(と定義 )

先頭処理のレスポンス (Ts) 0.001sec(と定義 )

μ(単位時間あたりの処理数 ) 単位時間 (1sec)÷Ts(0.001sec)=(最大で )1000件 /sec

λ(単位時間当たりの到着数 ) 変数とする。

17

M/M/1 公式のグラフ化 ( 前ページの仮定の場合 )

0

0.2

0.4

0.6

0.8

1

1.2

1 23 45 67 89 111

133

155

177

199

221

243

265

287

309

331

353

375

397

419

441

463

485

507

529

551

573

595

617

639

661

683

705

727

749

771

793

815

837

859

881

903

925

947

969

991

1013

1035

1057

1079

リクエスト数と平均待ち時間の推移(sec)(Ts = 0.001secの場合, M/M/1モデル)

集計

リクエスト数(λ に相当 )

Ts=0.001sec で捌いていても、1000 件 /sec のリクエストで飽和

レスポンス(Tw に相当 )

18

この状況は……






数が多過ぎて捌き切れない！

僕は楽勝～～♪

遅いなぁ…svctm は良好だが、

await が悪くなるケース

LU#1sda

19

0

0.2

0.4

0.6

0.8

1

1.2

1 23 45 67 89 111

133

155

177

199

221

243

265

287

309

331

353

375

397

419

441

463

485

507

529

551

573

595

617

639

661

683

705

727

749

771

793

815

837

859

881

903

925

947

969

991

1013

1035

1057

1079

リクエスト数と平均待ち時間の推移(sec)(Ts = 0.001secの場合, M/M/1モデル)

集計Ts=0.001sec で捌いていても、1000 件 /sec のリクエストで飽和

M/M/1 モデルの Tw が飽和している状態に相当

レスポンス(Tw に相当 )

svctm(Ts) に相当

await(Tw) に相当

リクエスト数(λ に相当 )

20

ストレージ側は余裕があるのに、ユーザプロセス

から見た I/O は遅い。

21

この状況の解決策は…

22

OS のデバイスを増やして、かつ分散させる






OS のデバイス/dev/sdb

OS のデバイス/dev/sdc


LU#1

LU#2

LU#3sdb

sda

sdc

ストレージから LU を切り出して、 OS デバイ

スとして追加する。

23

例えばOracle ASM

で分散 ( ステマ )

24

とは言え、物理的な制約が有ると、

このやり方は採用できない。

25

例えば、ストレージが内蔵 HDD の場合

内蔵 HDD





遅いなぁ…

sda

彡 ( ﾟ )( ﾟ )

できんわボケ !!!

LU 新しく切り出してデバイス増やしたら性能

スケールするで。

26

内蔵 HDD ではなく、 RAID なストレージでも……

RAID ストレージ





遅いなぁ…

sda

彡 ( ﾟ )( ﾟ )

そんな領域はもう無いなぁ…

LU#1

LU 新しく切り出してデバイス増やしたら性能

スケールするで。

27

このように物理的に制約が有るケースだと、

await >>> svctmでも、ストレージの性能限界と言える。

28

3 章 . I/O 遅延のパターン②svctm が悪化して遅延

29

I/O 遅延のパターン②・ svctm が悪化






作業担当者のレスポンスが遅い！

遅いなぁ…

svctm が悪化して、それに引き摺られて

await が遅くなるケース

30




：

この状況の時の iostat ログ

await >= svctm な状況で、かつ svctm の値が悪い。

31

このケースの遅延の原因は幾つかあって…

32

②' ストレージ ( 等 ) の性能が飽和している場合






遅いなぁ…

複数システムでストレージを共有している等の理由で、ストレージや

その経路の性能が飽和し、OS から見た svctm が悪化してい

る。

忙しいよ～～！


33


34

余り良い策は無い。 (基本はキャパの増強 )






ストレージ性能の増強

経路の増強

共有を止める( 処理量削減 )

35

②'' OS デバイス～ストレージの経路の問題のケース






遅いなぁ…

OS デバイス～ストレージの経路間で問題が発生して、svctm が悪化している。

何も来ないな？


36


37

やっぱり余り良い策は無い。 ( 経路間の問題を解消する )






OS デバイス～ストレージの経路間で発生している問題を

解消する。

38

4 章 . 分析のアンチパターン

39




：

処理量の統計だけに着目して分析

I/O の量が少ないので、I/O は問題無いです !!!!!!

40

(アカン )

41

■1回当たりの I/O が " 遅い " から処理量が少なくなっているのか？■そもそものリクエストが

少ないから、処理量が少ないのか？処理量だけ見ても、区別ができな

い。

42




：

レスポンス (svctm, await) も見ること

レスポンスの統計も ( を )確認する。

43

5 章 . まとめ

44

まとめ

遅延のパターンは複数あり、 await や svctm の傾向を分析して、遅延のパターンを見極めること– await >>> svctm なパターン– svctm がそもそも悪くなっているパターン

処理量の統計だけでなくレスポンスの統計も確認すること– 処理量が少ないから問題は無い。。。ではない。– 処理量が少ない ⇒ 遅いから少ない、と云うケースが有り得る。

45

参考サイト／参考ブログ

M/M/1 待ち行列について、下記サイトを参考にさせて頂きました (｀･ω ･ )ゞ– IT Pro ネットワークの数学 M/M/1

http://itpro.nikkeibp.co.jp/article/COLUMN/20060920/248528/yohei-a さん、いつもサンガツやで！彡 (^)(^)

– iostat の見方http://d.hatena.ne.jp/yohei-a/20110711/1310396665

– Linux の iostat の出力結果を銀行の ATM に例えて説明してみるhttp://d.hatena.ne.jp/yohei-a/20111203/1322909311

46

おわり

ご清聴、サンガツだったやで！

iostat await svctm の 見かた、考え方

Engineering

iostat await svctm の見かた、考え方