ORACLE PROCESS의 DISK I/O PERFORMANCE CHECK

Question

제품 : ORACLE SERVER
작성날짜 : 2003-06-27
ORACLE PROCESS 가 I/O 를 과도하게 사용할 경우 조치 방법
=======================================================
I/O 가 heavy 하여 database 의 performance 가 떨어질 경우,
원인을 확인하는 방법은 다음과 같습니다.
먼저, i/o 를 빠르게 하기 위한 async I/O 가 setting 되어 있는지 확인합니다.
async I/O 란 사용하는 H/W level 에서 제공하는 것으로, 동시에 하나 이상의
I/O 를 할 수 있도록 해 줍니다.
SVRMGRL 또는 SQLDBA> show parameter asyn
NAME TYPE VALUE
async_read boolean TRUE
async_write boolean TRUE
위의 값이 false 이면, H/W 가 Async I/O 를 제공하는지 확인한 후에,
$ORACLE_HOME/dbs/initSID.ora 에 위 값을 True 로 setting 하고
restartup 해 줍니다.
(Async I/O 가 제공되지 않을 경우, OS channel 한개 당 하나의
dbwr process 가 기동되도록 할 수 있습니다. db_writers 를 늘려주는 방법
을 고려할 수도 있습니다.)
두 번째 방법은 각 데이타 화일의 I/O를 확인해서, I/O 가 빈번한 데이타 화일을
찾아 disk 를 옮겨 주거나 table을 다른 데이타 화일로 move해줍니다.
다음 결과에 의해 각 datafile 의 access가 다른 datafile의 수치와 비슷할 때,
데이타들이 잘 분산되어 I/O 병목 현상이 없는 것입니다.
다음은 datafile 6, 7번에 read 가 집중되어 있습니다.
만약, I/O 속도의 향상을 원한다면, 자주 read 되는 table 을 찾아서 다른 disk의
datafile 로 옮겨 주는 것이 좋은 경우입니다.
SQL> select file#, phyrds, phywrts from v$filestat;
FILE# PHYRDS PHYWRTS
              1              61667             26946
              2              2194               58882
              3              1972                189
              4              804                   2
              5              7306               13575
              6              431859            21137
              7              431245            3965
              8              307                  19
마지막으로, I/O 가 빈번한 session 을 찾아 내어 어떤 작업을 하는지
확인하는 방법입니다.
Session ID를 알 수 있으므로, 이 session 의 SQL 문을 확인한 후에
I/O 를 줄일 수 있는 SQL 문으로 조정하십시오.
(tkprof 를 이용하여 plan 과 소요 시간을 확인할 수 있습니다.)
SQL> select sid, physical_reads, block_changes from v$sess_io
SID PHYSICAL_READS BLOCK_CHANGES
              1                0                0
              2                0                0
              3                0                0
              4               15468          379
              5                67               0
              6                0                6
              7                1               105
              8               2487          2366
              9               61               14
              11             311              47

Answer 1

I have seen slow iSCSI performance but in all cases it is slow on OS level already. You measurements indicate however that this is not the case but that the performance is slow just from within the guests when iSCSI disks are used.
Two thoughts:
- try to disable Jumbo frames. They are not standardized. While incompatible Jumbo frames typically result in a total loss of communication there might be an issue with the block sizes. Your dd tests could have been fast because of the 4K block sizes you use but the iSCSI initiator of VB may use a different block size which does not work well with Jumbo frames.
- test the iSCSI with dd a little bit more. Use a file created from /dev/random (you can't use /dev/random directly as this is dead slow) instead of /dev/zero to avoid any interference from possible optimizations along the way. Test with different block sizes with and without Jumbo frames. What I typically get (w/ Jumbo frames) is:
bs OSOL AR
512 14:43 9:13
4096 1:57 1:44
8192 1:18 1:09
16384 1:14 1:06
32768 1:08 1:04 <--- sweet spot
65536 1:08 1:08
131072 1:14 1:11
1048576 1:38 1:32
Good luck,
~Thomas