Upload
-
View
1.295
Download
1
Embed Size (px)
Citation preview
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 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:
await と svctm に 注目
ここに注目
6
考え方はこのモデル (M/M/1 待ち行列 )
実作業担当者受付
お客様
お客様
お客様
7
Linux/UNIX なシステムに当てはめると、こう。
HDD/SSD/ストレージ等
OS のデバイス/dev/sda
ユーザプロセス
ユーザプロセス
ユーザプロセスLU#1sda
※ 実際のシステムの I/O はもっと複雑ですが、解り易くするために抽象化して書いてます。
8
svctm の考え方
HDD/SSD/ストレージ等
OS のデバイス/dev/sda
ユーザプロセス
ユーザプロセス
ユーザプロセス
OS のデバイスからストレージ ( 等 )に
投げられた I/O リクエストが返ってくるまでレスポンスタイム
sda LU#1
9
await の考え方
HDD/SSD/ストレージ等
OS のデバイス/dev/sda
ユーザプロセス
ユーザプロセス
ユーザプロセス
複数のユーザープロセスから OS のデバイスに投げられた I/O リクエストが返ってくるまでの " 平均 " レスポンス
タイム(※ 一般的に svctm を包含する。 )
sda LU#1
10
2 章 . I/O 遅延のパターン①リクエスト数が多い。
11
I/O 遅延のパターン①・リクエスト数が多い
HDD/SSD/ストレージ等
ユーザプロセス
ユーザプロセス
ユーザプロセス
OS のデバイス/dev/sda
数が多過ぎて捌き切れない!
僕は楽勝~~♪
遅いなぁ…svctm は 良好だが、
await が 悪くなるケース
LU#1sda
12
下記は 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 … 1386.67 32.00 386.91 0.00 1109.91 1.55 100.03sdb 0.00 … 1386.67 32.00 386.91 0.00 1109.91 1.55 100.03
:
この状況の時の 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
この状況は……
HDD/SSD/ストレージ等
ユーザプロセス
ユーザプロセス
ユーザプロセス
OS のデバイス/dev/sda
数が多過ぎて捌き切れない!
僕は楽勝~~♪
遅いなぁ…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 のデバイスを増やして、かつ分散させる
HDD/SSD/ストレージ等
OS のデバイス/dev/sda
ユーザプロセス
ユーザプロセス
ユーザプロセス
OS のデバイス/dev/sdb
OS のデバイス/dev/sdc
ユーザプロセス
LU#1
LU#2
LU#3sdb
sda
sdc
ストレージから LU を切り出して、 OS デバイ
スとして追加する。
23
例えばOracle ASM
で分散 ( ステマ )
24
とは言え、物理的な制約が有ると、
このやり方は採用できない。
25
例えば、ストレージが内蔵 HDD の場合
内蔵 HDD
ユーザプロセス
ユーザプロセス
ユーザプロセス
OS のデバイス/dev/sda
遅いなぁ…
sda
彡 ( ゚ )( ゚ )
できんわボケ !!!
LU 新しく切り出してデバイス増やしたら性能
スケールするで。
26
内蔵 HDD ではなく、 RAID なストレージでも……
RAID ストレージ
ユーザプロセス
ユーザプロセス
ユーザプロセス
OS のデバイス/dev/sda
遅いなぁ…
sda
彡 ( ゚ )( ゚ )
そんな領域はもう無いなぁ…
LU#1
LU 新しく切り出してデバイス増やしたら性能
スケールするで。
27
このように物理的に制約が有るケースだと、
await >>> svctmでも、ストレージの性能限界と言える。
28
3 章 . I/O 遅延のパターン②svctm が悪化して遅延
29
I/O 遅延のパターン②・ svctm が悪化
HDD/SSD/ストレージ等
OS のデバイス/dev/sda
ユーザプロセス
ユーザプロセス
ユーザプロセス
作業担当者のレスポンスが遅い!
遅いなぁ…
svctm が悪化して、それに引き摺られて
await が 遅くなるケース
30
下記は 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 … 1386.67 32.00 386.91 0.00 1109.91 1109.91 100.03sdb 0.00 … 1386.67 32.00 386.91 0.00 1109.91 1109.91 100.03
:
この状況の時の iostat ログ
await >= svctm な状況で、かつ svctm の値が悪い。
31
このケースの遅延の原因は幾つかあって…
32
②' ストレージ ( 等 ) の性能が飽和している場合
HDD/SSD/ストレージ等
OS のデバイス/dev/sda
ユーザプロセス
ユーザプロセス
ユーザプロセス
遅いなぁ…
複数システムでストレージを共有している等の理由で、ストレージや
その経路の性能が飽和し、OS から見た svctm が悪化してい
る。
忙しいよ~~!
作業担当者のレスポンスが遅い!
33
この状況の解決策は…
34
余り良い策は無い。 (基本はキャパの増強 )
HDD/SSD/ストレージ等
OS のデバイス/dev/sda
ユーザプロセス
ユーザプロセス
ユーザプロセス
ストレージ性能の増強
経路の増強
共有を止める( 処理量削減 )
35
②'' OS デバイス~ストレージの経路の問題のケース
HDD/SSD/ストレージ等
OS のデバイス/dev/sda
ユーザプロセス
ユーザプロセス
ユーザプロセス
遅いなぁ…
OS デバイス~ストレージの経路間で問題が発生して、svctm が悪化している。
何も来ないな?
作業担当者のレスポンスが遅い!
36
この状況の解決策は…
37
やっぱり余り良い策は無い。 ( 経路間の問題を解消する )
HDD/SSD/ストレージ等
OS のデバイス/dev/sda
ユーザプロセス
ユーザプロセス
ユーザプロセス
OS デバイス~ストレージの経路間で発生している問題を
解消する。
38
4 章 . 分析のアンチパターン
39
下記は 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 … 86.67 32.00 386.91 0.00 1109.91 1109.91 100.03sdb 0.00 … 86.67 32.00 386.91 0.00 1109.91 1109.91 100.03
:
処理量の統計だけに着目して分析
I/O の量が少ないので、I/O は問題無いです !!!!!!
40
(アカン )
41
■1回当たりの I/O が " 遅い " から処理量が少なくなっているのか?■そもそものリクエストが
少ないから、処理量が少ないのか?処理量だけ見ても、区別ができな
い。
42
下記は 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 … 86.67 32.00 386.91 0.00 1109.91 1109.91 100.03sdb 0.00 … 86.67 32.00 386.91 0.00 1109.91 1109.91 100.03
:
レスポンス (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
おわり
ご清聴、サンガツだったやで!