iostat -x 1 10

cr147369

1002人浏览 · 2009-07-15 18:16:17

cr147369 · 2009-07-15 18:16:17 发布

    被一个问题困惑了n久，终于有点眉目了，但是还不确定最后的原因，希望在这方面有经验的朋友能帮忙看看，我的推测是否正确。

1. 问题描述
   大概20G左右的dmp文件，做imp：
   一台windows的机器
                   (只有2个盘)（很老的机器）
                   imp需要2:30小时
   一台Linux 64位的机器 Linux 2.6.9-67.ELlargesmp
                   8快硬盘，做raid1+0
                   imp却需要4-5个小时。
   2个数据库都是noarchivelog的。

2. 故障排除思路
   1.增加redo log
     在linux做imp的时候，发现v$log中的status总是为1个current和多个active，考虑会不会是oracle再等待redo log的写，所以加大成员和组数。
     现在linux的redo log每组的大小和组数都>>(远远大于)windows的机器。但是速度快了一些，可还是不如windows的机器（郁闷）。

   2.怀疑磁盘IO负载
     做imp时，iostat采样

     [root@ntkdb oradata]# iostat -x 1 10
     Linux 2.6.9-67.ELlargesmp (ntkdb) 07/15/2009

     avg-cpu: %user   %nice    %sys %iowait   %idle
                0.00    0.00    0.00    6.25   93.75

     Device:    rrqm/s wrqm/s   r/s   w/s rsec/s wsec/s    rkB/s    wkB/s avgrq-sz avgqu-sz   await svctm %util
     cciss/c0d0   0.00   0.00 0.00 0.00    0.00    0.00     0.00     0.00     0.00     0.00    0.00   0.00   0.00
     cciss/c0d1   0.00 162.00 0.00 162.00    0.00 2592.00     0.00 1296.00    16.00     0.99    6.12   6.12 99.10
     cciss/c0d2   0.00   0.00 0.00 0.00    0.00    0.00     0.00     0.00     0.00     0.00    0.00   0.00   0.00
     cciss/c0d3   0.00   0.00 0.00 0.00    0.00    0.00     0.00     0.00     0.00     0.00    0.00   0.00   0.00
     dm-0         0.00   0.00 0.00 0.00    0.00    0.00     0.00     0.00     0.00     0.00    0.00   0.00   0.00
     dm-1         0.00   0.00 0.00 0.00    0.00    0.00     0.00     0.00     0.00     0.00    0.00   0.00   0.00
     dm-2         0.00   0.00 0.00 0.00    0.00    0.00     0.00     0.00     0.00     0.00    0.00   0.00   0.00
     dm-3         0.00   0.00 0.00 0.00    0.00    0.00     0.00     0.00     0.00     0.00    0.00   0.00   0.00
     dm-4         0.00   0.00 0.00 0.00    0.00    0.00     0.00     0.00     0.00     0.00    0.00   0.00   0.00
     dm-5         0.00   0.00 0.00 0.00    0.00    0.00     0.00     0.00     0.00     0.00    0.00   0.00   0.00
     dm-6         0.00   0.00 0.00 324.00    0.00 2592.00     0.00 1296.00     8.00     1.98    6.11   3.06 99.10

     备注：
     rrqm/s:   每秒进行 merge 的读操作数目。即 delta(rmerge)/s
     wrqm/s:   每秒进行 merge 的写操作数目。即 delta(wmerge)/s
     r/s:      每秒完成的读 I/O 设备次数。即 delta(rio)/s
     w/s:      每秒完成的写 I/O 设备次数。即 delta(wio)/s
     rsec/s:   每秒读扇区数。即 delta(rsect)/s
     wsec/s:   每秒写扇区数。即 delta(wsect)/s
     rkB/s:    每秒读K字节数。是 rsect/s 的一半，因为每扇区大小为512字节。(需要计算)
     wkB/s:    每秒写K字节数。是 wsect/s 的一半。(需要计算)
     avgrq-sz: 平均每次设备I/O操作的数据大小 (扇区)。delta(rsect+wsect)/delta(rio+wio)
     avgqu-sz: 平均I/O队列长度。即 delta(aveq)/s/1000 (因为aveq的单位为毫秒)。
     await:    平均每次设备I/O操作的等待时间 (毫秒)。即 delta(ruse+wuse)/delta(rio+wio)
     svctm:    平均每次设备I/O操作的服务时间 (毫秒)。即 delta(use)/delta(rio+wio)
     %util:    一秒中有百分之多少的时间用于 I/O 操作，或者说一秒中有多少时间 I/O 队列是非空的。即 delta(use)/s/1000 (因为use的单位为毫秒)

     如果 %util 接近 100%，说明产生的I/O请求太多，I/O系统已经满负荷，该磁盘可能存在瓶颈。
     cciss/c0d1明显看出i/o负载过重。估计是数据文件划分的不合理。

     当初规划的时候，是这样考虑的。

     a. vgdisplay
     [root@ntkdb oradata]# vgdisplay -s
       "VolGroup03" 136.69 GB [97.78 GB used / 38.91 GB free]
       "VolGroup02" 136.69 GB [58.59 GB used / 78.09 GB free]
       "VolGroup01" 136.69 GB [117.19 GB used / 19.50 GB free]
       "VolGroup00" 136.56 GB [73.28 GB used / 63.28 GB free]

     b. bdf
     [root@ntkdb oradata]# df -k
     Filesystem           1K-blocks      Used Available Use% Mounted on
     /dev/mapper/VolGroup00-LogVol00
                           30254032   9830088 18887128 35% /
     /dev/cciss/c0d0p1       101086     14733     81134 16% /boot
     none                   8205024         0   8205024   0% /dev/shm
     /dev/mapper/VolGroup00-orainstall(ORACLE_BASE 目录，包括redo log 文件)
                           30254032   3886328 24830888 14% /u01/orainstall
     /dev/mapper/VolGroup01-oradata(数据文件)
                           60475476 54322692   3080784 95% /u02/oradata
     /dev/mapper/VolGroup02-oraindex(index)
                           60475476 49441188   7962288 87% /u02/oraindex
     /dev/mapper/VolGroup03-orabackup(存放其他文件)
                          100920744 22308440 73485752 24% /u03/orabackup
     /dev/mapper/VolGroup01-oradata02(扩充的数据文件)
                           60475476 46210964 11192512 81% /u03/oradata

     但是我们明显看到了磁盘的IO全部聚集到了cciss/c0d1 --》VolGroup01上，明显是当初考虑划分lv的时候，没有考虑分散磁盘io的问题。
     初步查明原因，想把/dev/mapper/VolGroup01-oradata02下的数据文件挪到 /dev/mapper/VolGroup03-orabackup下，是24小时的测试环境，如果有机会的话，我试一下移动数据文件，看看磁盘io的问题是不是得到了缓解，imp是否可以缩短时间。
[root@ntkdb oradata]# dmsetup ls
VolGroup01-oradata02 (253, 6)
VolGroup01-oradata (253, 5)
VolGroup03-orabackup (253, 3)
VolGroup00-orainstall (253, 2)
VolGroup00-LogVol01 (253, 1)
VolGroup00-LogVol00 (253, 0)
VolGroup02-oraindex (253, 4)

[root@ntkdb oradata]# hdparm -t /dev/cciss/c0d0
/dev/cciss/c0d0:
Timing buffered disk reads: 236 MB in 3.02 seconds = 78.11 MB/sec
HDIO_DRIVE_CMD(null) (wait for flush complete) failed: Inappropriate ioctl for device

[root@ntkdb oradata]# hdparm -t /dev/cciss/c0d1
/dev/cciss/c0d1:
Timing buffered disk reads: 256 MB in 3.01 seconds = 84.98 MB/sec
HDIO_DRIVE_CMD(null) (wait for flush complete) failed: Inappropriate ioctl for device

参考文献：
        1. http://www.php-oa.com/2009/02/03/iostat.html

        2. http://www.eygle.com/archives/2007/07/linux_diskio_speed_test.html

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/9252210/viewspace-609258/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/9252210/viewspace-609258/