ITPub博客

首页 > Linux操作系统 > Linux操作系统 > iostat -x 1 10

iostat -x 1 10

原创 Linux操作系统 作者:zhanglei_itput 时间:2009-07-15 18:16:17 0 删除 编辑

 

    被一个问题困惑了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/,如需转载,请注明出处,否则将追究法律责任。

上一篇: 随笔-人生
请登录后发表评论 登录
全部评论

注册时间:2009-02-10

  • 博文量
    400
  • 访问量
    1108468