• 解读 iostat -mxd 1


     ####

    for AWR 报告 :

    建议如下:

    不能随便调整db_file_multiblock_read_count 值, 

    取同样时间段的AWR 报告 02:00 ~ 05:00,所以db_file_multiblock_read_count 的值不能随便调整,从48 调整大到 128,发现 avg time 从 6 秒 调大 到 22 秒。

    db_file_multiblock_read_count 48     

    =Wait Avg(ms) 6

    db_file_multiblock_read_count 128           

    = Wait Avg(ms) 22

    ##########sample 0

    linux block 大小为1M. 

    # time dd if=/dev/sdak bs=1024k of=/dev/null iflag=direct

     写

    dd if=/dev/zero of=kwxgd bs=64k count=4k oflag=dsync

    dd if=kwxgd of=/dev/zero bs=64k count=4k iflag=direct

    正常 50M左右 性能比较好

    在第一个图中,我们只写1块,然后使用oflag=sync与conv=fsync 测出来一个是32.1kb/s 一个是37.8kb/s 差别不大。但是下一个我写1000个,conv=fsync就明显的比oflag=dsync/sync快很多了,所以觉得上面自己扣的英文的理解应该是正确的。

    所以在用dd做读或者写的时候,应该要注意自己的使用场景,如果需要将数据写入磁盘的话

    dd if=/dev/zero of=test bs=64k count=16k 是不准确的,

    如何真正写磁盘
    dd if=/dev/zero of=test bs=64k count=16k 这个是不准确的,因为命令结束的时候数据还没有真正写到磁盘上去,因为对磁盘的写,我们一般是先写到了缓存就返回了。

    我们来看dd的帮助页面对于一些参数的解释

    the FLAG 参数(完整的看手册哦,这里假设你是知道iflag跟oflag的)

    -dsync
    Use synchronized I/O for data. For the output file, this forces a physical write of output data on each write. For the input file, this flag can matter when reading from a remote file that has been written to synchronously by some other process. Metadata (e.g., last-access and last-modified time) is not necessarily synchronized.

    -sync likewise, but also for metadata

    the CONV参数
    -fsync 
    Synchronize output data and metadata just before finishing. This forces a physical write of output data and metadata

    dsync跟sync比较好理解,前者是只同步写数据,sync同时写元数据

    但是感觉dsync与 -fsync怎么感觉有些一样? 网上的说法是 dd if=/dev/zero of=test bs=64k count=4k oflag=dsync 这个可以当成是模拟数据库插入操作,所以很慢,但还是没太明白。

    后来自己认真的抠了这英文用词, conv=fsync Synchronize output data and metadata just before finishing 意思也就是在dd命令结束前同步data和metadata,那就是不是每一次写都同步一次咯,也就是如果我们在dd命令中写了100次,他可能是等到最后的时候才把他们同步到磁盘。而oflag=dsync是说Use synchronized I/O for data. For the output file, this forces a physical write of output data on each write,注意这里边用词 a physical write of output data on each write,那就是他是每一次写都得等到这一次写写到了磁盘才进行下一个写,也就是如果我们使用dd写100次,他每次写都是写到磁盘后才进行下一次写的。所以这样当然要比conv=fsync慢一些吧。那么自己感觉如果只是写一次的话,两者应该是差别不大的,后来做了下小实验,证实确实是这样的。

    而 dd if=/dev/zero of=test bs=64k count=16k conv=fsync 比较准备,他在dd结束前会写到磁盘,

    而dd if=/dev/zero of=test bs=64k count=4k oflag=dsync或者sync 是真正的每写一次就写一次磁盘,所以其实可以听到磁盘啪啪啪的响的。

     ##########sample 1


    At the same time:
    $ iostat -mx dm-10 10    ( 建议使用这个方法查看  iostat -dmx 1     ,  rMB/s    wMB/s ,svctm, r/s   w/s      )
    ...
    avg-cpu:  %user   %nice %system %iowait  %steal   %idle
              11.97    0.00    1.79   12.21    0.00   74.03

    Device:         rrqm/s   wrqm/s   r/s   w/s    rMB/s    wMB/s avgrq-sz avgqu-sz   await  svctm  %util
    sdak              0.00     0.00 800.00  0.00   200.00     0.00   512.00     1.77    2.22   0.60  47.86


    平均单次IO大小(IO Chunk Size) avgrq-sz  512-sector chunks  ,每个chunk size 为512k, 每秒一共(1/ 0.002)= 400K 个chunks, (0.002 取自await 时间)

    每秒 800 次读,每秒200M,


    * I.e. – as per iostat the 1024KB operations are being split into 512-sector chunks (i.e. into 256KB). Same happens with 512KB requests too.
    * 256KB and smaller don’t seem to be split in that way.
    * 8MB -> split to 256KB
    * 20000MB -> split into ~500KB avg request size. (So seems it can do more than 256K sometimes…)

    平均单次IO大小(IO Chunk Size) avgrq-sz

      平均IO响应时间(IO Response Time) await

      IOPS(IO per Second) r/s + w/s

      吞吐率(Throughtput) rkB/s + wkB/s

    Oracle ORION 下载

     http://www.oracle.com/technetwork/cn/topics/index-088165-zhs.html

     http://www.jydba.net/oracle-orion-calibration-tool/

    (important)

     ####sampe 2:

    ## iostat -dmx 1

    root@temc_vcs01 dev]# vxprint -g temcdg
    TY NAME ASSOC KSTATE LENGTH PLOFFS STATE TUTIL0 PUTIL0
    dg temcdg temcdg - - - - - -

    dm eerd04 eerd - 146729872 - - - -
    dm eerd05 eere - 146729872 - - - -
    dm eerd06 eerf - 146729872 - - - -
    dm eerd07 eerg - 146729872 - - - -
    dm eerd08 eerh - 419348128 - - - -
    dm temcdisk01 eera - 209643136 - - - -
    dm temcdisk02 eerb - 419348128 - - - -
    dm temcdisk03 eerc - 419348128 - - - -

    v archiveloglv fsgen ENABLED 104857600 - ACTIVE - -
    pl archiveloglv-01 archiveloglv ENABLED 104857600 - ACTIVE - -
    sd temcdisk02-01 archiveloglv-01 ENABLED 104857600 0 - - -

    v oracleapplv fsgen ENABLED 31457280 - ACTIVE - -
    pl oracleapplv-01 oracleapplv ENABLED 31457280 - ACTIVE - -
    sd temcdisk01-01 oracleapplv-01 ENABLED 31457280 0 - - -

    v oracledatalv fsgen ENABLED 1614807040 - ACTIVE - -
    pl oracledatalv-01 oracledatalv ENABLED 1614807040 - ACTIVE - -
    sd temcdisk02-02 oracledatalv-01 ENABLED 209797472 0 - - -
    sd temcdisk03-01 oracledatalv-01 ENABLED 419348128 209797472 - - -
    sd temcdisk01-02 oracledatalv-01 ENABLED 178185856 629145600 - - -
    sd temcdisk02-03 oracledatalv-01 ENABLED 52642400 807331456 - - -
    sd eerd04-01 oracledatalv-01 ENABLED 146729872 859973856 - - -
    sd eerd05-01 oracledatalv-01 ENABLED 146729872 1006703728 - - -
    sd temcdisk02-04 oracledatalv-01 ENABLED 52050656 1153433600 - - -
    sd eerd08-01 oracledatalv-01 ENABLED 409322784 1205484256 - - -
    [root@temc_vcs01 dev]#
    [root@temc_vcs01 dev]#
    [root@temc_vcs01 dev]#
    [root@temc_vcs01 dev]#
    [root@temc_vcs01 dev]#
    [root@temc_vcs01 dev]# pwd


    vi ptest.lun

    /dev/eera
    /dev/eerb
    /dev/eerc
    /dev/eerd
    /dev/eere
    /dev/eerf
    /dev/eerg
    /dev/eerh


    [root@temc_vcs01 dev]# dd if=/dev/eerc of=/dev/null bs=8129 count=1024
    1024+0 records in
    1024+0 records out


    Orion命令行示例
    1.对于OLTP数据库来评估存储的IO性能 (IOPS通道)

    system 1: vcfs :   8个盘加起来,IOPS=12190 ,平均每个盘1300左右

    ./orion -run oltp -testname ptest

    [root@temc_vcs01 orion]# ./orion -run oltp -testname ptest
    ORION: ORacle IO Numbers -- Version 11.1.0.7.0
    ptest_20171225_2324
    Test will take approximately 29 minutes
    Larger caches may take longer
    [root@temc_vcs01 round1]# more *summ*
    ORION VERSION 11.1.0.7.0

    Commandline:
    -run oltp -testname ptest

    This maps to this test:
    Test: ptest
    Small IO size: 8 KB
    Large IO size: 1024 KB
    IO Types: Small Random IOs, Large Random IOs
    Simulated Array Type: CONCAT
    Write: 0%
    Cache Size: Not Entered
    Duration for each Data Point: 60 seconds
    Small Columns:, 8, 16, 24, 32, 40, 48, 56, 64, 72, 80, 88, 96,
    104, 112, 120, 128, 136, 144, 152, 160
    Large Columns:, 0
    Total Data Points: 28

    Name: /dev/eera Size: 107374510080
    Name: /dev/eerb Size: 214749020160
    Name: /dev/eerc Size: 214749020160
    Name: /dev/eerd Size: 75162255360
    Name: /dev/eere Size: 75162255360
    Name: /dev/eerf Size: 75162255360
    Name: /dev/eerg Size: 75162255360
    Name: /dev/eerh Size: 214749020160
    8 FILEs found.

    Maximum Small IOPS=12190 @ Small=160 and Large=0
    Minimum Small Latency=7.47 @ Small=8 and Large=0


    ---system 2 vmware vg00   4个盘加起来,IOPS=5190 ,平均每个盘1300左右

    [root@pisa orion]# more *summary*
    ORION VERSION 11.1.0.7.0

    Commandline:
    -run oltp -testname ptest

    This maps to this test:
    Test: ptest
    Small IO size: 8 KB
    Large IO size: 1024 KB
    IO Types: Small Random IOs, Large Random IOs
    Simulated Array Type: CONCAT
    Write: 0%
    Cache Size: Not Entered
    Duration for each Data Point: 60 seconds
    Small Columns:, 4, 8, 12, 16, 20, 24, 28, 32, 36, 40, 44, 48, 52, 56,
    60, 64, 68, 72, 76, 80
    Large Columns:, 0
    Total Data Points: 24

    Name: /dev/sda3 Size: 29956469760
    Name: /dev/sda4 Size: 53686402560
    Name: /dev/sdb Size: 107374182400
    Name: /dev/sdc Size: 858993459200
    4 FILEs found.

    Maximum Small IOPS=5363 @ Small=68 and Large=0
    Minimum Small Latency=6.07 @ Small=4 and Large=0

    2.对于DSS数据库评估存储IO性能 (测试存储通道宽)
    ./orion -run dss -testname ptest &

    ##system 1 vcfs 0.218           8个盘加起来,MBPS=772.00 ,平均每个盘98M 

    [root@temc_vcs01 round2]# more *su*
    ORION VERSION 11.1.0.7.0

    Commandline:
    -run dss -testname ptest

    This maps to this test:
    Test: ptest
    Small IO size: 8 KB
    Large IO size: 1024 KB
    IO Types: Small Random IOs, Large Random IOs
    Simulated Array Type: CONCAT
    Write: 0%
    Cache Size: Not Entered
    Duration for each Data Point: 240 seconds
    Small Columns:, 0
    Large Columns:, 8, 16, 24, 32, 40, 48, 56, 64, 72, 80, 88, 96,
    104, 112, 120
    Total Data Points: 23

    Name: /dev/eera Size: 107374510080
    Name: /dev/eerb Size: 214749020160
    Name: /dev/eerc Size: 214749020160
    Name: /dev/eerd Size: 75162255360
    Name: /dev/eere Size: 75162255360
    Name: /dev/eerf Size: 75162255360
    Name: /dev/eerg Size: 75162255360
    Name: /dev/eerh Size: 214749020160
    8 FILEs found.

    Maximum Large MBPS=772.00 @ Small=0 and Large=72


    ####system 2 local  


    This maps to this test:     4个盘加起来,MBPS=400.00 ,平均每个盘100M 
    Test: ptest
    Small IO size: 8 KB
    Large IO size: 1024 KB
    IO Types: Small Random IOs, Large Random IOs
    Simulated Array Type: CONCAT
    Write: 0%
    Cache Size: Not Entered
    Duration for each Data Point: 240 seconds
    Small Columns:, 0
    Large Columns:, 4, 8, 12, 16, 20, 24, 28, 32,
    36, 40, 44, 48, 52, 56, 60
    Total Data Points: 19

    Name: /dev/sda3 Size: 29956469760
    Name: /dev/sda4 Size: 53686402560
    Name: /dev/sdb Size: 107374182400
    Name: /dev/sdc Size: 858993459200
    4 FILEs found.

    Maximum Large MBPS=438.48 @ Small=0 and Large=32

    3.对于基本的数据集评估存储IO性能
    ./orion -run normal -testname jytest


    4.为了理解存储性能使用只读,小与大的随机I/O工作量:
    /orion -run simple -testname jytest


    3..为了理解存储性能使用小与大混合的随机I/O工作量:

    http://blog.csdn.net/haiross/article/details/43196731?locationNum=9&fps=1

    (important)

    ########SAMPLE 3:

     

     

    $iostat -x 1  Linux 2.6.33-fukai (fukai-laptop)          _i686_    (2 CPU)  avg-cpu:  %user   %nice %system %iowait  %steal   %idle            
     5.47    0.50    8.96   48.26    0.00   36.82     
    Device:  rrqm/s  wrqm/s   r/s    w/s  rsec/s  wsec/s avgrq-sz avgqu-sz  await  svctm  %util  
    sda    6.00   273.00   99.00    7.00  2240.00  2240.00    42.26     1.12   10.57   7.96  84.40  
    sdb    0.00     4.00    0.00  350.00     0.00  2068.00     5.91     0.55    1.58   0.54  18.80

    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系统已经满负荷,该磁盘
    可能存在瓶颈。
    idle小于70% IO压力就较大了,一般读取速度有较多的wait.
    同时可以结合vmstat 查看查看b参数(等待资源的进程数)和wa参数(IO等待所占用的CPU时间的百分比,高过30%时IO压力高)
    另外 await 的参数也要多和 svctm 来参考。差的过高就一定有 IO 的问题。
    avgqu-sz 也是个做 IO 调优时需要注意的地方,这个就是直接每次操作的数据的大小,如果次数多,但数据拿的小的话,其实 IO 也会很小.如果数据拿的大,才IO 的数据会高。也可以通过 avgqu-sz × ( r/s or w/s ) = rsec/s or wsec/s.也就是讲,读定速度是这个来决定的。

    ###########SAMPLE 4

    下面是别人写的这个参数输出的分析

    # iostat -DMx 1  
    avg-cpu: %user %nice %sys %idle  16.24 0.00 4.31 79.44  
    Device:     rrqm/s wrqm/s r/s w/s rsec/s wsec/s rkB/s wkB/s avgrq-sz avgqu-sz await svctm %util  
    /dev/cciss/c0d0  0.00 44.90 1.02 27.55 8.16 579.59   4.08 289.80 20.57    22.35    78.21 5.00 14.29

    上面的 iostat 输出表明秒有 28.57 次设备 I/O 操作: 总IO(io)/s = r/s(读) +w/s(写) = 1.02+27.55 = 28.57 (次/秒) 其中写操作占了主体 (w:r = 27:1)。

    平均每次设备 I/O 操作只需要 5ms 就可以完成,但每个 I/O 请求却需要等上78ms,为什么? 因为发出的 I/O 请求太多 (每秒钟约 29 个),假设这些请求是同时发出的,那么平均等待时间可以这样计算:

    平均等待时间 = 单个 I/O 服务时间 * ( 1 + 2 + … + 请求总数-1) / 请求总数

    应用到上面的例子: 平均等待时间 = 5ms * (1+2+…+28)/29 = 70ms,和 iostat 给出的78ms 的平均等待时间很接近。这反过来表明 I/O 是同时发起的。

     

    每秒发出的 I/O 请求很多 (约 29 个),平均队列却不长 (只有 2 个 左右),这表明这 29 个请求的到来并不均匀,大部分时间 I/O 是空闲的。

    一秒中有 14.29% 的时间 I/O 队列中是有请求的,也就是说,85.71% 的时间里 I/O 系统无事可做,所有 29 个 I/O 请求都在142毫秒之内处理掉了。

    delta(ruse+wuse)/delta(io) = await = 78.21 => delta(ruse+wuse)/s =78.21 * delta(io)/s = 78.21*28.57 = 2232.8,表明每秒内的I/O请求总共需要等待2232.8ms。所以平均队列长度应为 2232.8ms/1000ms = 2.23,而 iostat 给出的平均队列长度 (avgqu-sz) 却为 22.35,为什么?! 因为 iostat 中有 bug,avgqu-sz 值应为 2.23,而不是 22.35。

     

     

     

    https://sort.veritas.com/patch/detail/8260

    https://www.cnblogs.com/ch3n3y/p/5930605.html (dmesg -c)

    http://blog.itpub.net/23718752/viewspace-1246724

    http://blog.csdn.net/t0nsha/article/details/22905433

    http://blog.csdn.net/hayyon/article/details/246666

    http://blog.csdn.net/yangzhenzhen/article/details/39078277

     

    平均单次IO大小(IO Chunk Size)

  • 相关阅读:
    前端代码规范
    AD 对联
    leaflet 入门笔记
    在Mac OS X上安装Git
    在Mac上开启C的新征程
    Python编程基础
    GitHub的使用(Git Shell)
    《网页设计心理学》Susan M.Weinschenk 小结精粹
    【问题】做图片验证码时乱码了,在header前加上ob_clean()就能神奇的显示?!
    --allow-file-access-from-files 命令的使用
  • 原文地址:https://www.cnblogs.com/feiyun8616/p/8068847.html
Copyright © 2020-2023  润新知