在生产中经常遇到一些IO延迟长导致系统吞吐量下降、响应时间慢等问题，如交换机故障、网线老化、存储阵列条带宽度、缓存不足、QoS限制、RAID水平设置不当等。IO延时。
一、评估 IO 能力的前提
评估系统IO能力的前提是了解系统IO模型是什么样的。那么IO什么是模型，为什么要提炼IO模型呢？
(一) IO模型
一般来说，在实际的业务处理过程中IO比较混杂，比如读写比例，IO尺寸等，都有波动。所以我们提炼IO当模型时，模型通常是为特定场景建立的，用于IO容量规划和问题分析。
最基本的模型包括：
IOPS带宽IO尺寸(尺寸)如果是磁盘IO，还需要注意：
磁盘IO哪些盘读？IO和写IO的比例读IO是顺序还是随机写？IO是顺序还是随机(二)为什么要提炼？IO模型
在不同的模型下，相同的存储或相同的存储LUN，能够提供的IOPS、带宽（MBPS）、响应时间3的最大值不同。
存储中提到的IOPS最大能力时，一般采用随机小IO测试时，占用的带宽很低，响应时间会比顺序更长IO要长很多。
存储中提到的IOPS最大能力时，一般采用随机小IO测试时，占用的带宽很低，响应时间会比顺序更长IO要长得多。如果随机变小。IO改为顺序小IO，那么IOPS还会更大。当测试顺序大时IO此时带宽占用率很高，但是IOPS却很低。
因此，做IO需要分析业务的容量规划和性能调优IO什么是模型？
二、评估工具(一)磁盘IO评估工具
磁盘IO评估能力的工具有很多，比如orion、iometer，dd、xdd、iorate，iozone，postmark，不同的工具支持不同的操作系统平台，应用场景也有自己的特点。
有些工具可以模拟应用场景，比如orion是oracle出品，模拟Oracle数据库IO负载(使用和Oracle相同的IO软件栈）。
即模拟oracle应用程序读写文件或磁盘分区(可指定读写比例)io size，顺序or这里需要提前了解自己IO模型。如果不知道，可以使用自动模式orion自动跑步，可以得到不同的并发读写过程，最高的IOPS、MBPS，以及相应的响应时间。
比对dd，只读写文件，没有模拟应用、业务、场景的效果。
postmark可实现文件读写、创建、删除等操作。适用于小文件应用场景的测试。
(二)网络IO评估工具ping：最基本的，可以指定包的大小。
iperf、ttcp：测试tcp、udp协议最大的带宽、延迟和丢包。
衡量windows平台下有许多带宽能力和工具：NTttcp、LANBench、pcattcp、LAN Speed Test (Lite)、NETIO、NetStress。
三、主要监控指标和常用监控工具(一)磁盘IO
对于存储IO：unix、linux平台，Nmon、iostat是更好的工具。
nmon用于事后分析，iostat可用于实时查看，也可用脚本记录事后分析。
1.IOPS总IOPS：Nmon DISK_SUMM Sheet：IO/Sec
阅读对应于每个盘IOPS ：Nmon DISKRIO Sheet
每一盘对应的写作IOPS ：Nmon DISKWIO Sheet
总IOPS：命令行iostat -Dl：tps
阅读对应于每个盘IOPS ：命令行iostat -Dl：rps
每一盘对应的写作IOPS ：命令行iostat -Dl：wps
2.带宽总带宽：Nmon DISK_SUMM Sheet：Disk Read KB/s，Disk Write KB/s
读取带宽对应于每个盘：Nmon DISKREAD Sheet
每个盘对应的写带宽：Nmon DISKWRITE Sheet
总带宽：命令行iostat -Dl：bps
读取带宽对应于每个盘：命令行iostat -Dl：bread
每个盘对应的写带宽:命令行iostat -Dl：bwrtn
3.响应时间每个磁盘对应的读取响应时间：命令行iostat -Dl：read - avg serv，max serv
每个盘对应的写作响应时间:命令行iostat -Dl：write - avg serv，max serv
4.其他磁盘繁忙程度、队列深度、每秒队列满次数等。
(二)网络IO1.带宽
最好直接处最好直接查看流量(比较准确)，也可以查看业务服务器
Nmon：NET Sheet
命令行topas：Network：BPS、B-In、B-Out
2.响应时间可以采用简单的方法ping命令查看ping延迟是否在合理范围内，是否丢包。
有些交换机是对的ping命令设置较低的优先级，可了较低的优先级ping包装时有延迟，所以ping结果可能无法反映真实情况。
有些交换机是对的ping命令设置较低的优先级，可了较低的优先级ping包装时有延迟，所以ping结果可能无法反映真实情况。如果需要更准确的测量，探针可以从服务器中捕获TCP连接时发送SYN包后开始计时，收到对端发回TCP SYNACK后期时差。更准确、更有利于后期分析的方法是在网络设备的端口使用专业的网络设备进行报纸捕获和计算分析。
四、性能定位与优化
(一)磁盘IO有哪些争论的调优思路？典型问题:主要用途是IO在相关场景下，调优的思路是什么？主要的技术或方法是什么？
首先要搞清楚IO争论是因为应用程序等级IO由于数量过系统层面无法承载这些IO量。若应用层面有过多不必要的读写，首先要解决应用问题。
例1:数据库用于数据库sort的buffer过小，当做sort内存和磁盘之间有大量的数据交换，所以这样IO可以通过扩展sort buffer减少或避免内存。例2：从应用程序的角度来看，有些日志根本不重要，不需要写，所以你可以降低日志水平，甚至不记录日志，可以添加到数据库水平hint “no logging”。
二是存储问题的分析思路存储IO问题可能出现在IO对链路的各个环节进行分析IO瓶颈是由主机/网络/存储中的哪个环节引起的。
IO从应用->内存缓存->块设备层->HBA卡->驱动->交换网络->存储前端->存储cache->RAID组->磁盘，经过一条长链。
需要逐步分析：
1、主机侧：应用->内存缓存->块设备层→HBA卡->驱动
2.网络侧:交换网络
3.存储侧:存储前端-cache-》RAID组-》磁盘
分析思路：
1、主机侧
主机侧观察到的延迟很大，存储侧延迟较小，可能是主机侧或网络问题。
主机是I/O的发起端，I/O该特性首先由主机的业务软件、操作系统软件和硬件配置决定。例如，本章介绍了服务队列满I/O 队列长度参数（queue_depth），当然，还有很多其他参数(如: driver 最大的可以发送到存储 I/O、光纤卡DMA memor区域大小、块设备并发数、HBA卡并发数)。
如果调查完成，性能问题仍然存在，则需要调查组网、链路和存储侧的性能问题。
如果调查完成，性能问题仍然存在，则需要调查组网、链路和存储侧的性能问题。
2、网络侧
当主机侧观察到延迟较大，存储侧延迟较小，主机侧无问题时，可能会出现性能问题。
可能的问题包括：带宽瓶颈、交换机配置不当、交换机故障、多路径选择错误、线路电磁干扰、光纤线损坏、接口松动等。瓶颈带宽、交换机配置不当、多路径选择错误、线路电磁干扰等。
3、存储侧
若主机侧延迟与存储侧延迟大且相差小，则表明存储中可能出现问题。首先，我们需要了解当前存储侧承载的内容IO根据存储侧的模型、存储资源配置和性能数据收集I/O路径定位性能问题。
硬盘性能达到上限、镜像带宽达到上限、存储规划(如条带过小)、硬盘域和存储池划分(如低速磁盘划分)、thin LUN还是thick LUN、LUN缓存设置(缓存大小、缓存类型、内存还是SSD）；IO的Qos限制的磁盘IO的带宽、LUN优先级设置，存储接口模块数量过小，RAID划分（比如RAID10>RAID5>RAID6)增值功能，如条带宽度、条带深度、配置快照、克隆、远程复制等，会减缓性能，是否有重构balancing操作正在进行，存储控制器CPU利用率过高，LUN未格式化完成会导致短期性能问题，cache刷入磁盘的参数(高低水位设置)，甚至数据也在盘子的中心或边缘。
每体的每一个环节 有一些具体的方法、命令和工具来查看性能，这里就不赘述了。
每体的每一个环节 有一些具体的方法、命令和工具来查看性能，这里就不赘述了。
(二)低延迟事务和高速交易的应用IO有哪些调优思路和建议？典型问题：关于最近在一些证券行业遇到的低延迟事务和高速交易的应用需求IO可以调整模型路径的想法和建议是什么？
对于低延迟事务，我们可以分析业务是否需要持久的保存日志，或者保存的安全性有多高，以决定使用什么IO。
1.从业务角度
比如业务上不需要保存日志，就不用写了IO。
或者如果保存级别不高，只能写一份数据。对于保存级别较高的日志，一般需要双写或多写。
2.从存储介质的角度
1)可全部使用SSD
2）或者采用SSD作为存储的二级缓存(一级缓存为内存)
3)或存储服务器中的存储分级(将热点数据迁移到存储服务器中(将热点数据迁移到存储分级)SSD、SAS性能好的硬盘等)
4）可以采用RAMDISK(内存用作磁盘)
5）增加LUN缓存相应的存储服务器
3.从配置的角度
存储普通磁盘LUN，可合理设置RAID模式（比如RAID10)适应你的业务场景。分条的深度大于或等于一个IO支持并发写作的大小和足够的宽度。
分条的深度大于或等于一个IO支持并发写作的大小和足够的宽度。
4.IO路径的角度
采用高速组网技术而非iSCSI低速等等。
(三) 网络IO定位问题的思路和方法与磁盘IO类似，网络IO还需要分段搜索和分析。通过网络抓包和分析工具，诊断网络延迟、丢包等异常情况，然后进行具体分析。同时，抓住主机端IPtrace可以帮助诊断很多网络问题，有兴趣看这篇文章。http://www.aixchina.net/Article/177921
(四)误判IO问题的案例很多时候，应用响应时间很慢，似乎是IO问题，其实不然，这里举两个例子
1.【案例分享】：Oracle buffer等待占总时间的大头在一个场景中，oracle的awr报告top10事件的第一名是:buffer busy waits
buffer busy waits是个比较general的等待，是sessio n等