sar -d 后发现avwait的值高，请高手指教下

vs8788

HP-UX zhzw02 B.11.11 U 9000/800    06/28/07

11:16:19   device   %busy   avque   r+w/s  blks/s  avwait  avserv
11:16:21  c14t1d3   89.95   47.11     238    4465  215.76   29.35
                c14t1d4   86.93   49.25     225    4577  200.60   30.00
                c14t1d5   91.46   56.52     261    5258  253.73   27.70
                c14t1d6   95.48   51.38     241    5153  212.00   30.36
                c14t1d7   97.49   44.71     218    4564  222.06   33.13
                c14t2d0   92.46   42.23     223    4229  210.82   31.93
                c14t2d1   93.47   46.23     228    4531  203.17   31.70
                c14t2d2   93.97   48.72     253    5114  239.63   28.75
                c14t2d3   89.95   53.57     239    4510  233.26   29.37
                c14t2d4   92.46   46.06     237    4768  209.81   29.60
                c14t2d5   94.47   52.72     268    5057  232.90   27.27
                c14t2d6   94.97   50.41     254    4961  229.88   28.92
                c14t2d7    8.04    0.50      10     153    5.32   23.71
                c14t3d0    9.05    0.50       9     137    4.68   19.97
                c14t3d1    9.55    0.50      15     241    5.17   22.42
                c14t3d2    8.04    0.50      10     161    5.27   22.28
                c14t3d3   11.06    0.50      12     185    5.19   21.15
                c14t3d4    7.04    0.50       7     105    6.85   18.23
                c14t3d5    8.54    0.50       9     145    4.97   21.03
                c14t3d6    7.54    0.50      10     153    4.14   21.28
                c15t1d3   90.45   47.55     253    5175  231.07   27.46
                c15t1d4   86.93   51.40     237    4661  212.61   28.12
                c15t1d5   82.41   53.75     200    4082  201.88   31.11
                c15t1d6   94.97   49.41     254    4632  242.14   29.12
                c15t1d7   88.94   48.87     232    4526  222.68   29.20
                c15t2d0   91.46   45.44     218    4687  209.15   32.33
                c15t2d1   90.95   43.00     240    4623  232.90   29.53
                c15t2d2   92.96   50.12     263    4808  227.55   27.54
                c15t2d3   91.46   51.06     251    5033  226.20   28.02
                c15t2d4   88.94   49.35     243    4704  230.84   27.77
                c15t2d5   86.43   50.12     228    4595  206.71   28.81
                c15t2d6   93.97   45.54     254    4945  231.03   28.32
                c15t2d7    9.55    0.50      11     177    5.66   21.35
                c15t3d0   10.55    0.50      10     153    4.72   23.55
       请高手指点下，响应时间特别长，busy也很高！！

leelangco

sar -Mu 5 100 看看wio是不是也特别的高

你的avwait远大于avserve 看来i/o真的是有问题，而且盘的%busy也特别的高。

c14 和c15是不同的控制器，我猜应该是有两条光纤路经认到同一个lun.

应该检查一下你的应用逻辑卷  是不是读写很频繁的逻辑卷分配了较多的pe在c14t1d3   到c14t2d6
之间的这些盘上面

vs8788

[/@zhzw02]#strings /etc/lvmtab
/dev/vg00
/dev/dsk/c0t6d0
/dev/dsk/c4t6d0
/dev/billvg01
/dev/dsk/c14t1d3
/dev/dsk/c14t1d4
/dev/dsk/c14t1d5
/dev/dsk/c14t1d6
/dev/dsk/c14t1d7
/dev/dsk/c14t2d0
/dev/dsk/c14t2d1
/dev/dsk/c14t2d2
/dev/dsk/c14t2d3
/dev/dsk/c14t2d4
/dev/dsk/c14t2d5
/dev/dsk/c14t2d6
/dev/dsk/c15t1d3
/dev/dsk/c15t1d4
/dev/dsk/c15t1d5
/dev/dsk/c15t1d6
/dev/dsk/c15t1d7
/dev/dsk/c15t2d0
/dev/dsk/c15t2d1
/dev/dsk/c15t2d2
/dev/dsk/c15t2d3
/dev/dsk/c15t2d4
/dev/dsk/c15t2d5
/dev/dsk/c15t2d6
/dev/rptvg01
/dev/dsk/c14t2d7
/dev/dsk/c14t3d0
/dev/dsk/c14t3d1
查看lvm的静态表，发现占用高的都在billvg01下。rptvg01下的都是正常的。（rptvg01下的内容太多只粘贴了一部分）

levine

定论还没有，我觉得应该首先考虑应用方面的问题，同样的一个阵列上的连接LUN，rptvg01中的/dev/dsk/c14t2d7、/dev/dsk/c14t3d0、/dev/dsk/c14t3d1算是正常的，而billvg01里的LUN都比较慢。需要根据此VG上的业务应用多考虑。看看系统中有没有其它报警信息，进程是否都正常等等。

vs8788

主要的ORACLE数据文件都在该VG下，而且在syslog中有报错
Jun 27 21:18:56 zhzw02 vmunix: 1/0/0/2/1.7.0 sctl
Jun 27 21:18:56 zhzw02 vmunix: 1/0/0/3/0 c720
Jun 27 21:18:56 zhzw02 vmunix: SCSI: Parity Error -- lbolt: 8661, dev: cb066002
Jun 27 21:18:56 zhzw02 vmunix:          lbp->state: 2060
Jun 27 21:18:56 zhzw02 vmunix:          lbp->offset: ffffffff
Jun 27 21:18:56 zhzw02 vmunix:          lbp->uPhysScript: 87ff8000
Jun 27 21:18:56 zhzw02 vmunix:  From most recent interrupt:
Jun 27 21:18:56 zhzw02 vmunix:          ISTAT: 0a, SIST0: 11, SIST1: 00, DSTAT:80, DSPS: 00110900
Jun 27 21:18:56 zhzw02 vmunix:  lsp: 000000005e39b800
Jun 27 21:18:56 zhzw02 vmunix:          bp->b_dev: cb066002
Jun 27 21:18:56 zhzw02 vmunix:          scb->io_id: 6000007
Jun 27 21:18:56 zhzw02 vmunix:          scb->cdb: 12 00 00 00 80 00
Jun 27 21:18:56 zhzw02 vmunix:          lbolt_at_timeout: 0, lbolt_at_start: 0
Jun 27 21:18:56 zhzw02 vmunix:          lsp->state: 5
Jun 27 21:18:56 zhzw02 vmunix:  lbp->owner: 0000000000000000
Jun 27 21:18:56 zhzw02 vmunix:  scratch_lsp: 000000005e39b800
Jun 27 21:18:56 zhzw02 vmunix:  Script dump [000000005a04a000]:
Jun 27 21:18:56 zhzw02 vmunix:          09000080 00110900 e25c0004 87ff87f8
Jun 27 21:18:56 zhzw02 vmunix:          80080000 87ff8090 80080000 87ff5090
Jun 27 21:18:56 zhzw02 vmunix: SCSI: Resetting SCSI -- lbolt: 8761,
Jun 27 21:18:59 zhzw02 vmunix: bus: 6
Jun 27 21:18:59 zhzw02 vmunix: SCSI: Reset detected -- lbolt: 8761, bus: 6
总是提示SCSI RESET

vs8788

还有个情况就是当跑应用的时候，占用就会起来了。

wnzl

显然你的盘太忙了，看看你的oracle业务时段的平均IOPS是多少，在看看存储的磁盘的IOPS是多少，如果业务的iops比磁盘的iops要高的话，就会造成这样的情况

iops

你的问题解决了吗？

你的系统明显是I/O的问题，

你可以贴一下sar -ud 的值吗？ 可以问题一下你目前存储的配置吗？

可以贴一下你的df -k ?

看一下www.iops.com.cn 专门看io慢的问题？