如何进行I/O评估、监控、定位和优化?

生产中经常遇到一些IO延时长导致的系统吞吐量下降、响应时间慢等问题,例如交换机故障、网线老化导致的丢包重传;存储阵列条带宽度不足、缓存不足、QoS限制、RAID级别设置不当等引起的IO延时。

本文由社区专家杨建旭根据社区活动整理,包括其分享的相关知识点分享和大家关心的典型问题,供大家参考

01 评估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要长很多。如果将随机小IO改为顺序小IO,那么IOPS还会更大。当测试顺序大IO时,此时带宽占用非常高,但IOPS却很低。因此,做IO的容量规划、性能调优需要分析业务的IO模型是什么。

02 评估工具   

(一)磁盘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。

03 主要监控指标和常用监控工具  

(一)磁盘IO

对于存储IO:unix、linux平台,Nmon、iostat是比较好的工具。nmon用于事后分析,iostat可用于实时查看,也可以采用脚本记录下来事后分析。

  1. IOPS总IOPS:Nmon DISK_SUMM Sheet:IO/Sec
  2. 每个盘对应的读IOPS :Nmon DISKRIO Sheet
  3. 每个盘对应的写IOPS :Nmon DISKWIO Sheet
  4. 总IOPS:命令行iostat -Dl:tps
  5. 每个盘对应的读IOPS :命令行iostat -Dl:rps
  6. 每个盘对应的写IOPS :命令行iostat -Dl:wps

2.带宽

  1. 总带宽:Nmon DISK_SUMM Sheet:Disk Read KB/s,Disk Write KB/s
  2. 每个盘对应的读带宽:Nmon DISKREAD Sheet
  3. 每个盘对应的写带宽:Nmon DISKWRITE Sheet
  4. 总带宽:命令行iostat -Dl:bps
  5. 每个盘对应的读带宽:命令行iostat -Dl:bread
  6. 每个盘对应的写带宽:命令行iostat -Dl:bwrtn

3.响应时间

  1. 每个盘对应的读响应时间:命令行iostat -Dl:read – avg serv,max serv
  2. 每个盘对应的写响应时间:命令行iostat -Dl:write – avg serv,max serv

4.其他

  1. 磁盘繁忙程度、队列深度、每秒队列满的次数等等。

(二)网络IO

1.带宽

最好在网络设备处直接查看流量(比较准),如果在业务的服务器也可以查看:

  • Nmon:NET Sheet
  • 命令行topas:Network:BPS、B-In、B-Out

2.响应时间

  • 简单的方法,可采用ping命令查看ping的延时是否在合理范围,是否有丢包现象。
  • 有些交换机对ping命令设置了较低的优先级,可能在回复、转发ping包的时候有延迟,因此ping的结果不一定能反映真实情况。如果需要更为精确的测量可以探针捕获从某服务器建立TCP连接时发送的SYN包后开始计时起,到其收到对端发回的TCP SYNACK后的时间差。

更为准确、利于后期分析的方法是采用专业的网络设备在网络设备的端口处进行报文捕获和计算分析。

 04 性能定位与优化   

(一)对磁盘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。

从业务角度比如说业务上不需要保存日志,那就不用写IO。或者保存级别不高,那就可以只写一份数据,对于保存级别较高的日志,一般要双写、或多写。

2.从存储介质角度

1)可以全部采用SSD

2)或者采用SSD作为存储的二级缓存(一级缓存是内存)

3)或者存储服务器里面采用存储分级(将热点数据迁移到SSD、SAS等性能较好的硬盘上)

4)可以采用RAMDISK(内存作为磁盘用)

5)增加LUN所对应的存储服务器的缓存

3.从配置的角度

普通磁盘存储的LUN,可以设置合理的RAID模式(比如RAID10)去适应你的业务场景。

分条的深度大于等于一个IO的大小、有足够的宽度支持并发写。

4.IO路径的角度

采用高速的组网技术,而不用iSCSI之类的低速方式。

(三) 网络IO问题定位思路和方法

与磁盘IO类似,网络IO同样需要分段查找和分析。通过网络抓包和分析的工具,诊断网络的延时、丢包等异常情况出现在哪一段,然后具体分析。

(四)误判为IO问题的案例

很多时候,应用响应时间很慢,看似是IO问题,实则不然,这里举两个例子。

1.案例分享:Oracle buffer等待占总时间的大头

在一个场景中,oracle的awr报告top10事件的第一名是:buffer busy waits

buffer busy waits是个比较general的等待,是session等待某个buffer引起的,但具体是什么buffer并不清楚,比如log sync等待也会引起buffer busy wait。这是个连带指标,分析是暂且不管,需要看看他临近的问题事件是什么。

awr报告top10事件的第二名是enq:TX – index contention

这里的临近事件就是enq:TX – index contention, index contention常由大量并发INSERT 造成的 index split 引起,也就是说不断更新索引的过程中,二叉树不断长大。需要分裂,分裂的时候,其他session就需要等着。(这里的分析需要些数据库知识)

之后的调优过程中,将索引分区,避免竞争。调整后重新测试,Index contention、Bufferbusy wait双双从top10事件中消失了

这类数据库相关的等待事件非常常见,看似是等待IO,实际上是数据库的规划设计有问题。

2.案例分享:ping延时间歇性暴增

某业务系统的响应时间很不稳定,该系统有两类服务器构成,可以简单理解为A和B,A为客户端,B为服务端,A处业务的响应时间非常不稳定。

第一步:从各类资源(CPU、内存、网络IO、磁盘IO)中追查原因。最终发现A与B直接的网络延时非常不稳定。A ping B,在局域网环境,按理说延时应该是0ms-1ms之间,而我们在业务高峰时发现,隔一小段时间就有100-200ms的延时出现。即使在没有业务的情况下,ping也30-40ms的延时。

第二步:那么好,着手定位网络问题吧。开始排查网路。换A的物理端口、换交换机、换网线、换对端的物理端口等等一系列措施之后,发现问题依然存在。

第三步:采用网络探测设备,从交换机两侧端口抓包,分析一个tcp连接的建立过程时间消耗在哪里。分析后发现,200ms的延时,都是在B测。即一个tcp连接建立过程在A侧和交换机侧几乎没有什么时间消耗。

第四步:B侧多台分区共用一个物理机。猜测是否是分区过多导致。当只有一个LPAR启动的时候,没有ping的延时,当启动一部分LPAR时候,延时较小,当所有LPAR均启动,ping 延时较大。

问题根本原因:此时,问题水落石出,原来是由于分区过多导致了B回复A的ping有了延时。那么为什么会出现这种情况呢?一个物理机上CPU资源是有限的(本环境中是3颗),即使只有一个LPAR,其上面的N个进程也会去轮流使用CPU,何况此时是M台LPAR,MN个进程去轮流使用这三个CPU,当然调度算法并不是这么简单,这里仅仅是从理论上做个说明。

假设每个CPU时间片是10ms,那么极端情况下,一个进程要等到CPU需要等待(MN-1)*10(ms)/3。

况且,这么多LPAR的进程轮询一遍CPU,CPU里面的cache 数据估计早就被挤走了,重新加载是比较耗时的。

应对方法:之前LPAR也设置了保障的CPU(MIPS数量的保障),但只有数量没有质量(上述提到的CPU cache问题,即亲和性问题)

应对方法是将重要的LPAR分配dedicated CPU,保证CPU资源的质量,保证轮询CPU的客户尽量少,这样CPU cache中的数据尽量不被清走。经验证,ping延时基本消失,方法有效。

本案例是一起看似是网络问题,但实际是资源调度方式的问题。

顺便提一句,很多情况下,客户端的响应时间不稳定都是由服务器端的服务能力不稳定造成的。一般情况下都是应用、数据库的问题造成。而本案例是操作系统层面答复ping出现间歇性延时,很容易误导我们的分析判断。

Image placeholder
buchin
未设置
  16人点赞

没有讨论,发表一下自己的看法吧

推荐文章
解DBA之惑:数据库承载能力评估及优化手段

作为DBA,有时会被挑战类似这样的问题:如果现有业务规模增加10倍、100倍,数据库是否能够支撑?下个月我们搞大促,数据库这边没问题吧?计划进行去O工作,代码逻辑不变,数据库从Oracle切换到MyS

企业应如何进行云迁移?小心这5个陷阱!

  国际数据公司(InternationalDataCorp)表示,到2022年,全球数字化转型支出将达到近2万亿美元。然而,各种各样的迁移事故仍然会对企业数字化转型过程造成阻碍,威胁着企业的生存与发

jquery如何进行字母大小写转换?

jquery如何进行字母大小写转换?1、大写转小写$('#in').val().toLowerCase()2、小写转大写$('#in').val().toUpperCase()使用案例:输入框失去焦点

项目管理最佳实践,企业如何进行有效的项目管理

前言:企业在划分项目时,可按照项目的复杂程度、管理范围等将项目分为三个级别,分别是企业级、部门级和小组级(与目标划分原则相同),然后将每一级的目标与项目对应起来。我们知道,企业制定的目标(OKR),一

拒当透明人,区块链隐私保护该如何进行

前言:隐私是现代社会的产物,也是自由社会的根基。隐私保护也是区块链行业的重要研究方向之一,那么到底如何进行以及实现隐私保护呢?隐私保护的其中一种方式就是零知识证明。其实可以用一句话来概括:“证明者(A

日志监控实践 – 监控Agent集成Lua引擎实现多维度日志采集

作者简介:董涵   百度资深研发工程师负责百度智能运维(Noah)服务管理和分布式监控架构研发工作,在分布式系统和大规模数据处理、可用性工程方向有广泛的实践经验。干货概览对于互联网行业来说,最有价值的

SQL优化案例-定位系统中大量的rollback(十八)

系统中logfilesync比较严重,查看存储都没有问题,logfileparallelwrite很低,时间分布直方图也没问题数据库中提交和回滚操作比较频繁,每秒1000多次,rollback占比1/

大数据如何为影视产业带来颠覆性变化?

电影制作是一个非常复杂的过程,从开始确定成本到制定有针对性的营销活动,涵盖多个流程。在这之中,数据科学几乎可以涉及到每一个步骤,带来创新的改变。而且从另一个角度上讲,从事数据科学工作的专业人员,也可以

Onvif/RTSP海康大华网络安防摄像机网页无插件直播方案EasyNVR如何使用Excel将通道配置简单化?

进入移动互联网时代以来,企业微信公众号已成为除官网以外非常重要的宣传渠道,当3.2亿直播用户与9亿微信用户的势能累加,在微信上开启直播已成为越来越多企业的必然选择。EasyNVR核心在于摄像机的音视频

Kubernetes 未来一年会有哪些变化?

试图预测历史上发展最快的开源项目的未来几乎是徒劳的,从谷歌到社区其他成员的“传承”已经发展成为编排的实际标准,从来没有一个项目以这种方式获得了整个企业社区的集体支持。从CNCF成员的长名单就可以看出,

记一次JVM FullGC引发严重线上事故的定位、分析、解决过程!

这篇文章给大家聊一次线上生产系统事故的解决经历,其背后代表的是线上生产系统的JVMFullGC可能引发的严重故障。一、业务场景介绍先简单说说线上生产系统的一个背景,因为仅仅是文章作为案例来讲,所以弱化

是什么能让 APP 快速精准定位到我们的位置?

本文作者:smallyang,腾讯IEG开发工程师什么是geohash?它的原理是什么?它帮助我们解决了哪些痛点,本文为你娓娓道来。本文包含以下内容,阅读完需要约10分钟:我们日常生活中遇到哪些定位的

css怎么去除定位?

如果没有指定元素的position属性值,也就是默认情况下,元素也是静态定位。只要是支持position属性的html对象都是默认为static。static是position属性的默认值,它表示块保

css怎么定位?

position属性规定元素的定位类型。这个属性定义建立元素布局所用的定位机制。任何元素都可以定位,不过绝对或固定元素会生成一个块级框,而不论该元素本身是什么类型。相对定位元素会相对于它在正常流中的默

css定位(position)属性怎么用?

position属性规定元素的定位类型。说明position属性定义建立元素布局所用的定位机制。任何元素都可以定位,不过绝对或固定元素会生成一个块级框,而不论该元素本身是什么类型。相对定位元素会相对于

css中ul怎么定位

css中ul怎么定位css中所有的元素默认都是static定位,要改变ul的定位方式,我们只需要指定元素的cssposition属性即可。关于定位的几种方式1、static定位(普通流定位)--默认定

CSS粘性定位(position: sticky)是怎样工作的?

浏览器对CSS粘性定位有着非常好的支持,但很多开发者都没有用过它。究其原因有两个: ● 第一,受到浏览器的良好支持需要漫长的等待:浏览器的支持往往需要很长的时间才能完成,到时候它的功能已经被人们遗忘了

css怎么设置粘性定位?

css怎么设置粘性定位?粘性定位的设置方法是给元素添加position:sticky;,sticky是css定位新增属性,类似static(没有定位)和固定定位fixed的结合。它主要用在对scrol

css定位怎么实现居中?

css定位怎么实现居中?使用绝对定位absolute是一种常用、兼容性很好的方式。.element{ width:600px;height:400px; position:absolute; left

从理论到案例,请收下这篇 Nginx 监控运维干货

Nginx(“enginex”)是一个开源、免费、高性能的HTTP和反向代理服务器,也可以用于IMAP/POP3代理服务器。充分利用Nginx的特性,可以有效解决流量高并发请求、cc攻击等问题。本文

在云、AI时代,传统应用性能监控方案过时了吗?

近年来,企业云对IT复杂性产生巨大影响,越来越多的企业需要能够解决云复杂性上升或加速数字化转型的有效方案,而人工智能正在成为解决这些问题的不二之选。在全球智能运维浪潮下,不少公司都选择重写代码,颠覆自

最流行的十大开源云监控工具

Linux系统在企业中的应用程度已经非常广泛,人们听到过太多关于Docker和Kubernetes的消息,以至于忘记了监控和日志记录也是同样重要的任务。Docker持续发展,随之而来的是围绕它构建的服

基于时序数据库做监控,这里有超流行的开源方案

在微服务架构下,我们对服务进行了拆分,所以用户的每次请求不再是由某一个服务独立完成了,而是变成了多个服务一起配合完成。这种情况下,一旦请求出现异常,我们必须得知道是在哪个服务环节出了故障,就需要对每一

开源监控系统Prometheus的前世今生

Prometheus是SoundCloud公司开源的监控系统,同时也是继Kubernetes之后,第二个加入CNCF的项目。Prometheus是一个优秀的监控系统,沃趣围绕着Prometheus先后

Kubernetes监控在小米的落地

本文介绍了高可用、持久存储、可动态调整的Kubernetes监控方案的实现过程。小米的弹性调度平台(Ocean)以及容器平台主要基于开源容器自动化管理平台kubernetes(简称k8s)来提供服务,