パフォチュー日記&QA６
第６回 ディスク転送量
ミッション：ＸＸ処理の処理速度を上げる！！！
同時更新の多いトランザクション
1. 4000件のＸＸ処理を連続実行し処理時間を測定
測定：約800秒
2. 負荷の高いSQL文を発見
トリガー内で実行されていたINSERT前のデータ有無チェックを止め、UNIQUE
インデックスによる重複レコードの排除を行うように変更。
3. 再度測定：約400秒に短縮
--------------------------------------- END TIME : 02/03/08 11:20 RUN TIME : 401.89 (sec) USER CPU TIME : 11.55 (sec) SYSTEM CPU TIME : 1.49 (sec) ---------------------------------------
4. インデックスに対する更新負荷が高い事を発見：無駄なインデックス削除
5. 無駄なGROUP BY処理を発見：GROUP BYからORDER BYに変更
6. バインド変数の徹底化
7. SQL文の実行回数：from dualによる型変換SQLをまとめる
8. ロールバックセグメントの見直し
9. 再度測定：約236秒に短縮
10.並列実効によるパフォーマンスアップを測定
CPU 多 U S 重 秒 S Y 度 数 R S 1 236.20 10.91 1.40 2 172.62 12.85 1.69 3 159.56 12.99 1.83 4 132.19 13.43 2.14 5 152.34 14.37 2.31 6 145.04 15.05 2.40 7 145.12 13.85 2.40 8 142.28 14.49 2.60 9 151.25 14.61 2.97 10 149.40 15.30 2.91 20 156.66 18.05 4.24
今回の処理(トランザクション)は4多重実行が一番効率的でした。
132.19秒 – 236.20秒 = -104.01秒（44%の改善）
並列実行するということはプロセスの数が増えるという事なので当然CPUの使用
時間は上がってしまいます。また、Oracleに接続するプロセス数もその分増え
Oracle側の負荷も高くなってしまいます。ですから、4多重のプロセスで使用し
たCPU時間の合計は1多重時よりも26％増えています。ということは実行時間は
44％改善されたのだけれどCPU資源という点からは26％のマイナスです。しかし、
CPU資源を全体としてみると今回の負荷テストレベルでは全く問題はありません。
CPU使用率が100%を振り切っているのではなく「単に多く使いました」というだ
けです。
ということで、このテスト(トランザクション)では、1個のディスクドライブで
処理すると4多重が限界という事になります。
今回のディスク装置はディスク・キャッシュが256MB装備されていますのでこれ
だけの値が出たのだと思います。キャッシュなしディスクであったら2多重ぐら
いが限度であったでしょう。
目標の処理件数20万件の概算は：
1 多重のとき : 約 3.3時間
4 多重のとき : 約 1.8時間
となります。この概算時間は：
トランザクションが完全に連続して実行起動され、他のトランザクションが存
在していない！という条件になります。他のトランザクションも同時に稼動す
ることを考慮するとディスク・ドライブを追加してストライピングを行いWrite
転送量を増やす事が必要となります。
Write転送量について
ディスクI/Oの平均アクティビティ統計
kw/sの値（1秒間にWriteしたバイト数）が4多重の時は平均で約5.6MB(5600.94KB)秒
の書き込み転送を行っていますが多重度が増えてもこれ以上にはなっていません。
むしろ減っていく傾向にあります。
4000件の処理を132.19秒で処理した平均のWrite転送量が5.6MBであったのだか
ら1件当りのWriteバイト数は：
(5.6 * 132.19) / 4000 = 0.185MB = 185KB となります。
ここから20万件のWriteバイト数を求めてみると：
((5.6 * 132.19) / 4000) * 200000
= 37013.2MB = 37GB
という事になります。
20万件の処理とは、
なんと！37ギガバイトもディスクへ書き出すということなのです。
多 重 度 r/s w/s kr/s kw/s actv asvc_t busy% 1 3.07 785.73 35.90 4114.38 0.55 0.70 51.79 2 0.37 972.66 3.67 5226.69 0.70 0.73 65.89 3 0.46 967.67 5.50 5305.18 0.68 0.70 63.88 4 1.42 1012.46 13.90 5600.94 0.73 0.72 67.96 5 0.60 977.49 5.20 5275.75 0.72 0.74 67.76 6 0.74 1019.45 5.57 5506.76 0.76 0.75 71.50 7 0.55 947.53 4.39 5154.83 0.67 0.71 64.14 8 0.64 997.33 6.12 5397.51 0.68 0.69 64.18 9 0.66 923.31 10.44 4965.27 0.65 0.69 61.32 10 1.26 967.82 13.54 5209.50 0.70 0.73 66.43 20 0.77 943.03 9.83 5090.55 0.70 0.73 65.52 r/s reads per second w/s writes per second Kr/s kilobytes read per second Kw/s kilobytes written per second actv average number of transactions actively being serviced (removed from the queue but not yet completed) asvc_t average service time active transactions, in milliseconds busy% percent of time the disk is busy (transactions in progress)
ディスクのパフォーマンス調査でよく使われるビジー率
この例からも分かるようにビジー率(busy%)は状態を表す指標としては相応しく
ありません。転送量をベースにチューニングおよび監視を行うというのが今回
のキーワードです。
次号に続く、
茅ケ崎 フィッシャーマン