ASM を味わう ～ DISK の I/O をもう一度均等化してみる ～ その１４
＜ASM を味わう ～ DISK の I/O をもう一度均等化してみる ～ その１４＞
ペンネーム：ダーリン
前回の検証で、同一 DISK Group 内で偏っている DISK I/O をリバランスコマ
ンドで均等化できるかどうかを試してみました。結果としては、I/O バランス
はまったく変わらず、少なくとも I/O に関して ASM の機能でバランシングを
行っていないであろうことを確認しました。
では、今回は強引にデータを移動させて見ましょう。つまり、DISK を DROP &
ADD してみます。これならいやでもデータは移動するはずです。
ちなみに DISK Group に所属している DISK を DROP すると、当然その DISK
に配置されているデータが他の DISK に移動されます。ということは、今回の
ように、DISK I/O が偏っている場合は、I/O が集中している DISK のデータ
を他の DISK へ移動させてしまえば、I/O の集中は緩和されるはずです。仮に、
I/O が集中していない DISK を DROP しても、もともと少ない I/O なら DROP
後の I/O の偏りは大きくは変化しないはずです。
今回は、I/O の偏りを緩和できるかどうかと言う点に着目しているので、I/O
が集中している DISK_002 を DROP して見ましょう。
<>
検索前 検索後 差分
------ ------ -----
DISK_001 1995 2010 15
DISK_002 17593 18817 1224
DISK_003 3741 3849 108
SQL> alter diskgroup dg_0001 drop disk disk_002; Diskgroup altered.
さてデータが移動したかどうか確認しましょう。
<>
SQL> select a.name dg_name 2 , b.disk_number 3 , b.total_mb 4 , b.free_mb 5 , b.name 6 , b.path 7 from v$asm_diskgroup a 8 , v$asm_disk b 9 where a.group_number = b.group_number 10 and a.name = 'DG_0001'; DG_NAME DISK_NUMBER TOTAL_MB FREE_MB NAME PATH ---------- ----------- ---------- ---------- ---------- ------------- DG_0001 2 10236 10185 DISK_003 /dev/raw/raw5 DG_0001 1 10236 10183 DISK_002 /dev/raw/raw4 DG_0001 0 10236 10185 DISK_001 /dev/raw/raw3
<>
SQL> / DG_NAME DISK_NUMBER TOTAL_MB FREE_MB NAME PATH ---------- ----------- ---------- ---------- ---------- ------------- DG_0001 2 10236 10176 DISK_003 /dev/raw/raw5 DG_0001 1 10236 10200 DISK_002 /dev/raw/raw4 DG_0001 0 10236 10177 DISK_001 /dev/raw/raw3
<>
SQL> / DG_NAME DISK_NUMBER TOTAL_MB FREE_MB NAME PATH ---------- ----------- ---------- ---------- ---------- ------------- DG_0001 2 10236 10158 DISK_003 /dev/raw/raw5 DG_0001 0 10236 10161 DISK_001 /dev/raw/raw3
DISK_002 が切り離された様です。
では、前回と同じ検索を実施して I/O の状況を確認します。
SQL> select /*+ index(b ui_tbl001) */
2 dbms_rowid.rowid_block_number(b.rowid) blk_num
3 , b.c2
4 from darling.tbl001 b
5 where ( ( b.c1 >= 1 and b.c1 <= 124 )
6 or ( b.c1 >= 377 and b.c1 <= 502 )
7 or ( b.c1 >= 755 and b.c1 <= 880 )
8 or ( b.c1 >= 1133 and b.c1 <= 1258 )
9 or ( b.c1 >= 1511 and b.c1 <= 1636 )
10 or ( b.c1 >= 1889 and b.c1 <= 2014 )
11 or ( b.c1 >= 2267 and b.c1 <= 2392 )
12 or ( b.c1 >= 2645 and b.c1 <= 2770 )
13 or ( b.c1 >= 3032 and b.c1 <= 3148 )
14 or ( b.c1 >= 3401 and b.c1 <= 3526 )
15 or ( b.c1 >= 3779 and b.c1 <= 3840 ));
1311 rows selected.
Execution Plan
----------------------------------------------------------
0 SELECT STATEMENT Optimizer=ALL_ROWS (Cost=49 Card=1341 Bytes=2711502)
1 0 TABLE ACCESS (BY INDEX ROWID) OF 'TBL001' (TABLE) (Cost=49 Card=1341 Bytes=2711502)
2 1 INDEX (FULL SCAN) OF 'UI_TBL001' (INDEX (UNIQUE)) (Cost=26 Card=88)
Statistics
----------------------------------------------------------
0 recursive calls
0 db block gets
1408 consistent gets
1320 physical reads
0 redo size
5285567 bytes sent via SQL*Net to client
1469 bytes received via SQL*Net from client
89 SQL*Net roundtrips to/from client
0 sorts (memory)
0 sorts (disk)
1311 rows processed
実行計画や統計値は前回と同様です。
では、I/O はどうでしょうか。うまく均等化されているでしょうか。
完全とまではいかなくても、データ量がほぼ同等に割り振られているので、必
然的に I/O が分散されていてもおかしくないはずです。
<>
SQL> select a.name 2 , a.path 3 , a.reads 4 , a.writes 5 , a.bytes_read 6 , a.bytes_written 7 from v$asm_disk a 8 , v$asm_diskgroup b 9 where a.group_number = b.group_number 10 and b.name = 'DG_0001'; NAME PATH READS WRITES BYTES_READ BYTES_WRITTEN ---------- --------------- ------ ---------- ---------- ------------- DISK_003 /dev/raw/raw5 5331 1102 228646912 111109120 DISK_001 /dev/raw/raw3 2371 35731 175112192 233034240
<>
SQL> / NAME PATH READS WRITES BYTES_READ BYTES_WRITTEN ---------- --------------- ------ ---------- ---------- ------------- DISK_003 /dev/raw/raw5 6617 1102 239423488 111109120 DISK_001 /dev/raw/raw3 2431 35737 176828416 233058816
検索前 検索後 差分 ------ ------ ----- DISK_001 2371 2431 60 DISK_003 5331 6617 1286
なんだこれ！？ だめだめじゃん！！
データ量がほぼ均等に割り振られているのに、I/O が振り分けられないという
ことは、DISK_002 にあったデータが実は丸ごと DISK_003 に移動されただけ
なんでしょうか？
よし、ではもう一度挑戦します。次は今 DROP した DISK を追加します。
<>
SQL> select a.name dg_name 2 , b.disk_number 3 , b.total_mb 4 , b.free_mb 5 , b.name 6 , b.path 7 from v$asm_diskgroup a 8 , v$asm_disk b 9 where a.group_number = b.group_number 10 and a.name = 'DG_0001' DG_NAME DISK_NUMBER TOTAL_MB FREE_MB NAME PATH ---------- ----------- ---------- ---------- ---------- ------------- DG_0001 2 10236 10158 DISK_003 /dev/raw/raw5 DG_0001 0 10236 10161 DISK_001 /dev/raw/raw3
<>
SQL> / DG_NAME DISK_NUMBER TOTAL_MB FREE_MB NAME PATH ---------- ----------- ---------- ---------- ---------- ------------- DG_0001 2 10236 10182 DISK_003 /dev/raw/raw5 DG_0001 1 10236 10188 DISK_002 /dev/raw/raw4 DG_0001 0 10236 10183 DISK_001 /dev/raw/raw3
追加出来たようです。各 DISK のデータ量は DISK を DROP する前とほぼ同じ
ような状態になっています。
では、同様の検索処理を実行して I/O の偏り状態を確認します。
今度はどうでしょうか。
<>
NAME PATH READS WRITES BYTES_READ BYTES_WRITTEN ---------- --------------- ------ ---------- ---------- ------------- DISK_003 /dev/raw/raw5 6684 1178 264765440 111420416 DISK_002 /dev/raw/raw4 24 94 98304 50397184 DISK_001 /dev/raw/raw3 2496 36550 200073216 236392960
<>
NAME PATH READS WRITES BYTES_READ BYTES_WRITTEN ---------- --------------- ------ ---------- ---------- ------------- DISK_003 /dev/raw/raw5 7918 1178 274870272 111420416 DISK_002 /dev/raw/raw4 80 94 921600 50397184 DISK_001 /dev/raw/raw3 2553 36562 201641984 236442112
検索前 検索後 差分
------ ------ -----
DISK_001 2496 2553 57
DISK_002 24 80 56
DISK_003 6684 7918 1234
んー。
I/O が偏る DISK が入れ替わっただけで、結局問題解決にはなっていないよう
です。
DISK Group 内の DISK I/O の偏りについては、ASM 自体は何の効力も発揮し
てくれないようですね。しかし、DISK を DROP したらその DISK のデータが
特定の DISK にだけ再配置されるなんてどうにも納得できない。バランスでき
ていないじゃないか。
ASM は”サイジングが容易な大きな器”とだけ認識したほうがよさそうです。
I/O バランシングに関して過大に期待してはいけません。
さて、ASM に関しての検証は今回で一旦終了しますが、まだまだ検証したりな
い部分がたくさん出てきました。いずれ機会を見つけてご報告したいと思います。
では。
砂浜でなくしたカギが見つかりました。送ってくれた人、ありがとう。
茅ヶ崎にて