 上传我的文档
 下载
 收藏
该文档贡献者很忙，什么也没留下。
 下载此文档
正在努力加载中...
虚拟机磁盘IO带宽分配机制研究
下载积分：1698
内容提示：虚拟机磁盘IO带宽分配机制研究
文档格式：PDF|
浏览次数：146|
上传日期： 00:59:17|
文档星级：
全文阅读已结束，如果下载本文需要使用
 1698 积分
下载此文档
该用户还上传了这些文档
虚拟机磁盘IO带宽分配机制研究
关注微信公众号1532人阅读
云计算（38）
前面讲了KVM CPU()、内存()的优化，下面接着第三块的内容，KVM磁盘性能方面的调优。磁盘IO我们可以从以下四个方面去着手优化：
磁盘类型选择
缓存模式选择
AIO 异步读写方式选择
磁盘IO调度器选择
磁盘类型选择
磁盘方面，建议是用Virtio模式，在CentOS7.1 中，磁盘的类型有IDE 、SATA 以及virtio 三种。磁盘这块也有完全虚拟化和半虚拟化之分。virtio它就是半虚拟化的，最初是由澳大利亚的一个天才级程序员Rusty Russell编写，是一个在hypervisor之上的抽象API接口，它让客户机知道自己运行在虚拟化环境中，从而与hypervisor一起根据 virtio 标准协作，因此，virtio能让客户机中达到更好的性能（特别是I/O性能）。
关于使用virtio的测试数据，如下图所示，virtio模式的读写能力远高于IDE的：
图上淡紫色的数据条是virtio的数据，红色的是IDE的，性能几乎是相差很大。
所以大家在选择磁盘模式的时候，注意选择virtio模式，特别是在云环境里，你制作的虚拟机模版，最好选择virtio模式。
缓存模式选择
目前KVM这块支持5种磁盘缓存模式，writethrough、writeback、none、directsync或者unsafe。一般用到的就是前面3种，后面两种几乎不会使用。
writethrough：（直写模式）数据直接写入磁盘里，不使用缓存；在数据更新时，同时写入缓存Cache和后端存储。此模式的优点是操作简单；缺点是因为数据修改需要同时写入存储，数据写入速度较慢。
writeback：（回写模式）在数据更新时只写入缓存Cache。只在数据被替换出缓存时，被修改的缓存数据才会被写到后端存储。此模式的优点是数据写入速度快，因为不需要写存储；缺点是一旦更新后的数据未被写入存储时出现系统掉电的情况，数据将无法找回。
none：这种模式作用在Guest OS Pagecache和Physical Disk
Cache中，相当于虚拟机能直接访问宿主机的磁盘，性能不错！
从图中可以看到，writeback采用了guest和host两层的page cache，也就是说同一个文件会存在两份cache，这是没有必要的，none和writethrough都会绕过host层的page cache。
低于QEMU-KVM 1.2 的版本kvm默认的cache方式是writethrouh，这种方式是最安全的，不会造成数据的不一致性，但是性能也是最差的。
总的来说，这三种模式，从安全和性能两角度分析，效果如下：
性能上： writeback & none & writethrough
安全上 ：writeback & none & writethrough
关于这三种模式的测试结果，如下图所示：
其中淡紫色的是 none模式，我们发现它的性能数据几乎很平均，所以选择它是最合适的方式，既安全稳定性能又不错。设置的方法也很简单，直接在XML里定义：
&driver name='qemu' type='qcow2' cache='none'/&
加上cache='none'即可
综合数据的安全性和性能，建议选择none模式，注意CentOS下默认是none。
AIO 异步读写方式选择
aio 这块分为两种，一种是native方式，还有一种是thread方式。
Linux系统上异步IO常见的有两种实现，一种是kernel native AIO，另外一种是threaded aio: user space AIO emulated by posix thread workers。
Kernel native AIO : Kernel的原生态异步IO实现。
Threaded aio : linux用户空间异步IO的实现，其实它不是真正的异步IO，是通过启动一定数量的
blocking IO线程来模拟异步IO。这种实现有不少缺点，毕竟有不少线程开销，还在改进中。
因此，我们KVM里选择AIO这块选择Kernel的原生态的native更好。
开启方式是：
&driver name='qemu' type='qcow2' cache='none' aio='native'/&
磁盘IO调度器选择
目前Linux 磁盘IO调度主要有3种，NOOP ，Deadline ，CFQ 。
Deadline I/O scheduler ：用过期时间来排序io操作顺序，保证先出现的io请求有最短的延迟时间，相对于写操作，给读操作更优先的级别，是比较好的一个调度模式。特别适合于读取较多的环境(比如数据库,Oracle 10G 之类)。
NOOP (elevator=noop)： 这个调度模式会把所有的数据请求直接合并到一个简单的队列里。在有些SAN 环境下，这个选择可能是最好选择。适用于随机存取设备, 不适合有机械结构的存储器。因为没有优化顺序，会增加额外的寻道时间。属于最简单的一个调度模式，无视io操作优先级和复杂性，执行完一个再执行一个，如果读写操作繁多的话，就会造成效率降低。
CFQ I/O scheduler：完全公平队列，是anticipatory模式的替代品，没有过多的做预测性调度，而是根据给定的进程io优先级，直接来分配操作的顺序。这个模式在linux上表现良好，但也许并不是最适合android的io调度模式，太强调均衡，而降低了连续读写数据的性能。适用于有大量进程的多用户系统。
Linux默认是deadline，我们可以通过命令 cat /sys/block/sd*/queue/scheduler 查看：
如果要更改模式，我们就用：
格式：echo {SCHEDULER-NAME} & /sys/block/{DEVICE-NAME}/queue/scheduler
例：echo cfq & /sys/block/sda/queue/scheduler
改成cfq模式
这三种调度方式，得具体看你的虚拟机跑的应用去选择，一般的是选择CFQ模式。
转载自云技术实践微信公众号，作者宝哥。
* 以上用户言论只代表其个人观点，不代表CSDN网站的观点或立场
访问：63090次
积分：1122
积分：1122
排名：千里之外
原创：51篇
转载：31篇
评论：35条
(3)(9)(5)(3)(4)(4)(2)(6)(14)(7)(3)(1)(2)(5)(13)(1)web应用性能优化经验总结 - IT老友 - 博客园
&常见性能优化要求
& & &在我经历的性能优化案例中，常见的问题都是这样开始的：
& & &a) 前台访问很慢，请帮忙分析优化
& & &b) 用户对性能很不满意，再不解决就要投诉
& & &c) 数据库负载很重，请帮忙分析一下
& & &d) XXX功能打开需要1分钟，请帮忙分析一下。而等我访问这个功能的时候，可能几秒钟就返回；等你满怀困惑的找到问题提出人员，如果足够幸运的话，可能他告诉你要选择什么查询条件，问题能够重现；当然另一个可能是他也是转述用户的话。
& & &在接到这些性能优化要求的时候，我都希望能够了解下面的信息以判断问题的类型，而通常情况下，我的工作都是在这些信息并不存在的情况下开始的
& & &a)系统性的问题? 比如CPU利用率，SWAP利用率或者IO过高导致的整体性能下降？
& & &b)功能性问题？ 整体性能良好，个别功能时延很长
& & &c)新出现问题？什么时候开始的，之前系统有哪些变动？（升级或者管理的资源大量增加）
& & &d)不规律问题？有时候快，有时候慢，没有特定规律
& & &还有性能快慢的衡量标准是什么？原来多少秒，现在多少秒，目标是多少秒？
只有上述问题得到了准确的回答，优化工作才能开始。
& & &而获取上述答案的方法就是测量，有可靠的监控工具对用户的访问时延，系统的CPU,IO,SWAP进行准确的测量，当系统发生性能瓶颈时，系统当时的状态，数据库当时的状态进行及时的记录，依赖这些数据才能开始优化。
& & &案例1，天津客户曾经有过投诉，系统经常性的出现整体性能下降，几乎无法访问的情况，而且发生的时间没有任何规律。我部署了监控工具，3周后分析数据，发现访问性能下降之前用户都执行了某一个历史告警查询，而在此之后的数据库性能曲线也急剧下降。研发人员对此功能优化后，问题再也没有出现。
& & &案例2，南京客户某主机经常崩溃，根据监控工具在崩溃前记录的进程列表看，是某个程序挂起导致的进程越积越多，资源耗尽而崩溃，对该程序改进后，故障再未发生。
& & &只所以费这么多笔墨，就是希望能够让各位明白，没有定量的测量，性能优化工作完全是空中楼阁，无法进行。而通过工具的部署和监测，今后我们提出的性能问题可能就是这样：
& & &a) 系统整体负载正常，但/nms/res/devicelist_down.jsp目前经常出现35046毫秒的访问时延，请协助排查一下
& & &b) 系统SWAP利用率经常会超过50%，这时候系统响应很慢，杀掉GetCGFlux.pl后恢复正常，请分析一下
& & &c) 或者数据库服务器目前CPU利用率居高不下，已经持续了一段时间，请分析一下
如果性能优化工作以这样的方式开始的话，这项工作就会变得轻松有趣得多了。
优化分析过程
1. 性能数据收集
& & &这一步是性能优化的基础，如果问题系统之前没有部署监控工具的话，那么就要部署监控工具，收集一段时间的数据后才能开始分析；当然也有例外，幸运的话，性能问题正在发生并且如此显著，比如某个程序长时间无法挂起，或者某个进程把整台主机的CPU都吃掉，或者某个功能查询很慢,次次如此。当然这种问题也就很少需要到我这，你就可以直接找开发人员解决了。
& & &很多情况，问题可能不是那么明显，也不是那么规律，可能也涉及到系统的多项功能，这个时候，我们就必须要借助于工具来进行数据的收集。
2. 性能数据分析
& & &如果没有数据收集，分析工作可能很神秘，完全依赖于专家的个人经验。以前听过一个故事，一个工厂的打印机总是莫名其妙的在某个时间出现故障，后来请了一个专家，搬了把椅子坐在打印机附近，几个星期后，叫工人把地板的某个角修好，之后这个问题再也没有出现。
& & &但是有了之前收集的数据，观察CPU，IO，应用时延，网络性能等不同指标的曲线，观察问题出现的时间点，存在问题的功能，任何一个IT业者，都应该具备从这些数据中发现问题的能力。
例如某台采集机SYSLOG处理经常出现会滞后的情况。而这台机器的网络丢包是这个样子的，那么问题是不是显而易见？
再比如有一个巡检功能，数据某个时段总是大量入库失败，那你看到数据库CPU和连接数在这个时段是这样的，数据库连接数增加，CPU空闲率为0，那么是不是问题也很明显了。
3. 实施优化工作
& & &这一步主要是针对之前发现的问题，采取措施。可能是系统维护人员调整采集负载，让负荷更均匀；或者调整主机或数据库参数；当然更多的可能是程序需要优化
4. 评估优化效果
& & &譬如上述第二个例子，采取优化措施后，无论是网络连接数还是数据库主机负载，都已经很平稳，而问题也不再出现。
如果没有达到，则不断重复上述四步，继续优化。
我的工具箱
这个工具箱是我常用的性能分析工具，曾协助我解决了很多的性能优化难题
a) web访问时延监控工具AssayFilter
& & &部署在主应用上
& & &部署后可以在resin/logs/AssayFilter.log里面看到访问时间，访问的用户，访问的URL，时延毫秒，来源IP，据此我们就可以将用户的感知定量化，数据化
& & &07 zengguojin /nms/res/devicelist_down.jsp .159.77.116 ms
& & &13 zengguojin /nms/res/devicelist_down.jsp .159.77.116 ms
& & &从这两条数据里我们可以知道这个用户在访问这个功能时候遭遇过多次等待300多秒的情况,他又会有怎样的满意度呢？
& & &针对这个工具可能有人怀疑是否准确，是否统计时延过高是网络延迟导致。这里解释一下他的工作机制，
如下图：& & &AssayFilter作为一个拦截器，统计的是访问请求进入resin之后和应答离开resin之前的时长，访问时延=resin处理时长+主应用到数据库网络时延+oracle的SQL执行时长
& & 主应用到数据库都在一个交换机上，所以主应用到数据库网络时延可以忽略不计。
& & & & & & & & & & & & & & & & & & & & [图1]
& & &所以，这个工具完全避免了网络延迟对访问时延统计的影响，让我们的精力完全聚焦在WEB应用自身的性能上.
b) 主机监控探针wd_probe
& & &部署在主机上
& & &这个监控探针除了能起到主机告警通知的作用，也是一个我依赖的性能分析工具，他能够记录各个时间点的CPU,SWAP,磁盘IO,网络性能，进程数量，网络连接数量的性能数据，当CPU超过预设阀值时会输出系统当时的进程快照用于事后的分析。
& & &在探针主目录的data/perf下有性能数据，在data/tmp下有系统进程快照
c) 数据库超长SQL收集工具
& & &部署在主应用上，可以在cron里每分钟执行一次
& & &这个程序会不断捕捉执行时间超过6秒的sql,记录进 /tmp/sql.csv文件中，运行结果如下：
& & &从发起端看可分为两类，通常从APP发起的JDBC程序就是用户前台访问执行的SQL,而这种SQL执行时间超过6秒就是我们需要优化的SQL.
perl@unknown (TNS V1-V3)
fuuk7dbrmsk47
select probeid,cfgfiledir,cfgfilename,to_char(lastgottime,'YYYYMMDDHH24MISS'),resid from cfgfilelist
JDBC Thin Client@pon-gx-app
db6b71unjzah1
INSERT INTO RCHECKRESGROUPRES (PLANID,GROUPID,RESID,IPADDRESSA,RESNAME,NODECODE,NODENAME,NODEFULLCODE,
系统基础问题检查
1. &主机基础故障问题
& & &磁盘空间是否空闲为0？
& & &SWAP利用率是否超过40%?
& & &CPU利用率是否长时间超过85%？
& & &网络是否持续丢包？
& & &工作磁盘IO的利用率是否持续100%?
& & &上述状况通常意味着系统有较严重问题，需要进一步从程序或者数据库上查找原因。
2. resin的JVM检查
Web应用的前台程序jsp和class都是运行在resin的JVM里，JVM(Java虚拟机)类似于oracle数据库，jsp和class类似于SQL,都可以看作一个系统软件，那么仅仅是看java进程在不在，前台能不能访问是不够的。就像没有sqlplus,PLSQL我们就无法维护数据库，同样的JVM也有相应的维护工具,，都在JAVA_HOME/bin下
a. 查看JVM的内存占用情况
& & &jstat -gcutil &pid& 3s 5 & & &&
& & &这条命令间隔3秒钟查看JVM的内存利用率，取样5次，
& & &S0&&&& S1&&&& E&&&&& O&&&&& P&&&& YGC&&&& YGCT&&& FGC&&& FGCT&&&& GCT&&& 0.00& 98.51& 44.95& 39.41& 63.43&&&&& 9&&& 0.070&&&& 2&&& 0.195&&& 0.266
& & &永久内存区利用率63.43%, Elden和old区分别是44.95%和39.41%
b. 查看JVM的堆栈调用情况
& & &jstack &pid&
& & &这条命令把当前JVM里所有的线程调用堆栈输出。在前台访问无响应的时候，排查故障根源时特别有用。
上述Thread-831被38f06e88的线程所阻塞，而根据调用堆栈，可以准确的定位到执行程序，进行排查。
c. 查看错误日志是否有内存溢出错误
& & &日志在resin/logs/error.log或者resin/log/jvm-default.log
& & &如果有java.lang.OutOfMemoryError: PermGen space 说明JVM的永久内存区不足
& & & & & & & &&-XX:MaxPermSize=256m & & 可根据永久内存区利用率调整到256M
& & & & & & & &java.lang.OutOfMemoryError说明JVM的堆内存不足
& & & & & & & &-Xmx2048m -Xms2048m & & 把堆内存调大到2048G
& & &如果把Xmx加到2G，仍然会出现上述错误，那可能是有内存泄漏，需要开发人员排查
3. &数据库检查
oracle排查比较复杂，我只能从两方面简单举几个例子。
a) &系统参数层面优化
& & &1) sga是否充分利用了系统内存，sga可以配系统内存的一半. 而我遇到过主机64G内存，sga_target设置为5G
& & &2)&db_cache_size最好在sga_target-3G，因为我们的程序很多没有使用绑定变量,如果不设置db_cache_size,则渐渐的SGA都有被share_pool占用的趋势，数据被缓存的越来越少，获取数据需要从磁盘读取，这样整体性能肯定会下降。
& & & 3)&shared_servers设置为0，让数据库运行在专有模式而不是共享服务器模式
& & 虽然系统参数调整会在整体上带来一定的性能改善，但相比于糟糕的SQL或者程序设计以及失效的索引和过期的统计数据对性能起到的作用，还是很有限的。
b) &应用优化层面
& & &1) 定位问题SQL
& & & & &这个SQL能够列出数据库当前正在执行的所有SQL,
select distinct s.sid,s.serial#,s.blocking_session,p.spid PID,to_char(s.logon_time,'YYYY-MM-DD HH24:MI:SS') logontime ,substr(s.machine,1,15) smachine,substr(s.program,1,20) sprogram,q.sql_id,substr(q.sql_text,1,200) sql from v$sql q,v$session s,v$process pwhere q.hash_value=s.sql_hash_value and q.address=s.sql_address& and p.addr=s.paddr
& & & & &基于两个判断标准我们能很快的找到问题SQL
& & & & 第一种是某个进程执行的SQL占用的CPU非常高，CPU利用率从Top命令获得，进程ID即PID
& & & & 第二种是某类进程执行的SQL非常多，单个CPU不高，但合并起来就非常高了。
& & & & 针对SQL就可以找支撑人员进一步判断是否需要找开发人员优化。
& & &2) 是否存在session被其他session阻塞的情况
& & & & & 查看上一SQL结果的blocking_session字段，如果被阻塞的进程都被某一会话锁定，需要把该session杀掉
& & & & & alter system kill session 'sid,serail#';
& & & & & 遇到过几次系统非常慢的情况，经查看都是开发或者维护用plsql把某表锁住，导致相关会话都被阻塞
& & &3) 对该SQL所涉及的表进行表分析，更新其统计信息
性能优化非常精深，很多东西我也在学习，这篇文字，供大家分享。
阅读(...) 评论()2017版：KVM 性能优化之磁盘IO优化
接着第三块的内容，KVM磁盘性能方面的调优。磁盘IO方面我们可以从以下四个方面去着手优化：
磁盘类型选择
缓存模式选择
AIO 异步读写方式选择
磁盘IO调度器选择
1. 磁盘类型选择
磁盘方面，建议是用Virtio模式，在CentOS7.1 中，磁盘的类型有IDE 、SATA 以及virtio 三种。磁盘这块也有完全虚拟化和半虚拟化之分。virtio它就是半虚拟化的，最初是由澳大利亚的一个天才级程序员Rusty Russell编写，是一个在hypervisor之上的抽象API接口，它让客户机知道自己运行在虚拟化环境中，从而与hypervisor一起根据 virtio 标准协作，因此，virtio能让客户机中达到更好的性能（特别是I/O性能）。
关于使用virtio的测试数据，如下图所示，virtio模式的读写能力远高于IDE的：
图上淡紫色的数据条是virtio的数据，红色的是IDE的，性能几乎是相差很大。
所以大家在选择磁盘模式的时候，注意选择virtio模式，特别是在云环境里，你制作的虚拟机模版，最好选择virtio模式。
2. 缓存模式选择
目前KVM这块支持5种磁盘缓存模式，writethrough、writeback、none、directsync或者unsafe。一般用到的就是前面3种，后面两种几乎不会使用。
writethrough：（直写模式）数据直接写入磁盘里，不使用缓存；在数据更新时，同时写入缓存Cache和后端存储。此模式的优点是操作简单；缺点是因为数据修改需要同时写入存储，数据写入速度较慢。
writeback：（回写模式）在数据更新时只写入缓存Cache。只在数据被替换出缓存时，被修改的缓存数据才会被写到后端存储。此模式的优点是数据写入速度快，因为不需要写存储；缺点是一旦更新后的数据未被写入存储时出现系统掉电的情况，数据将无法找回。
none：这种模式作用在Guest OS Pagecache和Physical Disk Cache中，相当于虚拟机能直接访问宿主机的磁盘，性能不错！
从图中可以看到，writeback采用了guest和host两层的page cache，也就是说同一个文件会存在两份cache，这是没有必要的，none和writethrough都会绕过host层的page cache。
低于QEMU-KVM1.2的版本kvm默认的cache方式是writethrouh，这种方式是最安全的，不会造成数据的不一致性，但是性能也是最差的。
总的来说，这三种模式，从安全和性能两角度分析，效果如下：
性能上： writeback & none & writethrough
安全上 ：writeback & none & writethrough
关于这三种模式的测试结果，如下图所示：
其中淡紫色的是 none模式，我们发现它的性能数据几乎很平均，所以选择它是最合适的方式，既安全稳定性能又不错。设置的方法也很简单，直接在XML里定义：&driver name='qemu' type='qcow2' cache='none'/& 加上cache='none'即可
综合数据的安全性和性能，建议选择none模式，注意CentOS下默认是none。
3. AIO 异步读写方式选择
aio 这块分为两种，一种是native方式，还有一种是thread方式。
Linux系统上异步IO常见的有两种实现，一种是kernel native AIO，另外一种是threaded aio: user space AIO emulated by posix thread workers。
Kernel native AIO : Kernel的原生态异步IO实现。
Threaded aio : linux用户空间异步IO的实现，其实它不是真正的异步IO，是通过启动一定数量的 blocking IO线程来模拟异步IO。这种实现有不少缺点，毕竟有不少线程开销，还在改进中。
因此，我们KVM里选择AIO这块选择Kernel的原生态的native更好。
开启方式是：
&driver name='qemu' type='qcow2' cache='none' aio='native'/&
4. 磁盘IO调度器选择
目前Linux 磁盘IO调度主要有3种，NOOP ，Deadline ，CFQ 。
Deadline I/O scheduler ：用过期时间来排序io操作顺序，保证先出现的io请求有最短的延迟时间，相对于写操作，给读操作更优先的级别，是比较好的一个调度模式。特别适合于读取较多的环境(比如数据库,Oracle 10G 之类)。
NOOP (elevator=noop)： 这个调度模式会把所有的数据请求直接合并到一个简单的队列里。在有些SAN 环境下，这个选择可能是最好选择。适用于随机存取设备, 不适合有机械结构的存储器。因为没有优化顺序，会增加额外的寻道时间。属于最简单的一个调度模式，无视io操作优先级和复杂性，执行完一个再执行一个，如果读写操作繁多的话，就会造成效率降低。
CFQ I/O scheduler：完全公平队列，是anticipatory模式的替代品，没有过多的做预测性调度，而是根据给定的进程io优先级，直接来分配操作的顺序。这个模式在linux上表现良好，但也许并不是最适合android的io调度模式，太强调均衡，而降低了连续读写数据的性能。适用于有大量进程的多用户系统。
Linux默认是deadline，我们可以通过命令cat /sys/block/sd*/queue/scheduler查看：
如果要更改模式，我们就用：
格式：echo {SCHEDULER-NAME} & /sys/block/{DEVICE-NAME}/queue/scheduler
例：echo cfq & /sys/block/sda/queue/scheduler 改成cfq模式
这三种调度方式，得具体看你的虚拟机跑的应用去选择，一般的是选择CFQ模式。
参考链接：
https://segmentfault.com/a/9553
http://www.php-oa.com//linux-io-elevator.html
相关阅读：
加入中国最活跃的OpenStack技术讨论QQ群，加群主QQ：，并注明城市、行业、技术方向。
交流 分享 提升
云技术社区成立于2014年，国内最大的云技术交流平台，分享在云计算/虚拟化项目实施中的资讯、经验和技术，坚持干货。旗下运营：云技术实践、云技术、桌面云之云潮涌动等公众号，以及相关的微信群和QQ群，覆盖云计算领域的技术人群，加入云技术社区微信、QQ群请点击订阅号菜单“群和活动”。
责任编辑：
声明：本文由入驻搜狐号的作者撰写，除搜狐官方账号外，观点仅代表作者本人，不代表搜狐立场。
今日搜狐热点