性能调优

性能调优（精选9篇）

性能调优 篇1

0 引言

Tomcat是目前比较流行的Web应用服务器, 最新的Servlet和JSP规范总能在其中得到体现, 深受Java爱好者的喜爱并得到了部分软件开发商的认可。Tomcat在默认配置情况下, 性能难以充分发挥。为了提高处理HT-TP请求的并发能力, 应用在生产环境中, 需要对Tomcat进行性能监视和调优。

1 Tomcat性能监视

为了进行性能调优, 首先要进行性能监视, 找出生产环境下Tomcat的各种参数配置效果, 确定性能瓶颈, 调整资源的分配, 提高并发量。

1.1 性能监视思路

可以通过发送大量HTTP的请求来模拟多用户对Tomcat的并发访问, 使其承受不切实际数量的负荷, 获得错误的情况。也许是Web服务器拒绝连接、或是Java虚拟机耗光内存、或是数据库连接失败、或是其它方面错误, 从而定位系统瓶颈。要选择资源消耗大的代码执行路径, 比如有复杂的业务处理、频繁数据库的交互、大量数据的传递、文件的读写等, 逐步增加并发访问量, 监视Tomcat的状态, 查看实际被处理请求的线程并发数、堆栈内存使用情况、数据库连接是否正常等。

1.2 性能监视工具

JMeter是Apache组织开发的一个用于压力测试和性能测量工具, 可用于对服务器、网络或对象等模拟繁重的负载来测试它们的强度或分析不同压力类型下的整体性能, 有助于性能的调整。为了方便, 本文中把数据库服务器、Tomcat6、JMeter等安装在一台操作系统为XP的电脑上, 虽然不同的软硬件环境测试的数据结果会有大的差异, 但不影响测试效果。

1.3 实施步骤

(1) 建立测试计划。使用JMeter添加线程组、添加取样器、添加监视器, 测试结果如图1。

(2) 性能监视。利用Tomcat自带的Manager控制台进行性能监视, 查看JVM参数、处理http请求线程数等情况, 如图2。说明默认状态下, Tomcat的JVM最大值为64M, 可以并发处理的最大线程数为40。

(3) 增加负载测试。增加请求线程数为600, 在JMeter的Summary Report中发现Error%为4.02%, 表明服务器端已经来不及处理所有请求, 丢弃了4.02%的http请求。通过Tomcat监视器查看, 发现并发的请求数已达到最大的数值40, 堆内存也几乎使用完。既然有请求的丢弃, 说明实际并发的请求数已经超过了能承受的Max threads数。

急剧增加并发的请求数, 将线程数增加为6 000, JMeter和Tomcat的控制台分别出现了错误, Summary Report的错误率急剧上升到100%。JMeter控制台错误说明其所需的栈空间已经严重不足, 大量并发的请求需要多个线程栈。Tomcat控制台错误说明服务器运行所需的JVM堆内存已经严重不足, 最终拖垮Tomcat。错误提示主要有以下几种:

错误提示一:uncaught Exception java.lang.OutofMemoryError:unable to create new native thread.

原因:操作系统没有足够的内存资源来产生线程, 需要开辟的栈空间不够。

解决方法:相应增加线程默认的总栈空间大小, 以便能生产更多的线程。

错误提示二:java.lang.OutOfMemoryError:Java heap space.

原因:JVM可使用的堆内存不够分配。在大量并发请求时, 实际需要的内存超出堆的最大值时, 虚拟机就会提示内存溢出, 严重时会导致应用服务崩溃。解决办法:相应增加JVM可使用的堆内存。

错误提示三:java.lang.OutOfMemoryError:PermGen space.

原因:JVM可使用的PermGen内存不够分配, 该内存是永久保存区域, 主要JVM用于存放Class和Meta信息。

解决方法:相应增加可使用的永久存储区内存。

2 Tomcat性能优化

性能优化需要逐步调整各方面参数, 不断查看测试效果, 使软硬件整体性能充分发挥, 达到整体最优。

2.1 JVM参数调优

JVM参数的调整需要结合操作系统和Web程序对内存的实际使用情况, 在堆、栈和永久存储区之间合理分配, 使它们协调。可以在startup.bat文件头中试探性修改, 如下:

set CATALINA_OPTS=-Xms512m-Xmx1 024m–Xss128k

-XX:PermSize=16m-XX:MaxPermSize=32m

使用同样的sample进行测试, 发现Jmeter和Tomcat端不再报异常了, 只是Error%错误率比较大, 测试结果如图3, 监视结果如图4。同时还使用指令jstat查看PermGen永久保存区的分配情况以及JDK自带的jconsole监视服务器整体状态。结果表明调整JVM参数起到了效果, 堆的大小对性能影响较大, 但服务HTTP请求的线程数量不够。

2.2 调整线程池

服务器来不及响应大量并发请求, 会丢弃部分请求, 需要修改连接器的并发线程数。在server.xml的http连接器节点下配置maxThreads="800", 发现请求的丢失比调整前相比少很多, 即Error%的值变小了, 如图5和图6, 表明提高线程池的并发量起效果了。

2.3 调整数据库连接池

如果数据库连接池的最大连接数严重不足, 也会产生“Cannot get a connection”错误。每个线程都可能要访问数据库, 调整好JVM的参数和连接器的并发数, 还需适当增大数据库连接池的并发数。由原来的maxActive="40"变为maxActive="100", 发现错误率降为8.90%, 表明数据库连接池参数的调整, 对性能也有着重要的作用。但是如果过多地增加maxActive的值, 比如为800, 和线程池的maxThreads值一致, 发现错误率反而上升了。因为与数据库交互时, 速度受磁盘转速物理条件的限制, 比在内存中创建线程的速度要慢, 所以如果数据库连接池容量设置过大, 会导致磁盘来不及响应服务连接的请求, 操作系统所需内存的资源也会相应增加, 反而会降低系统整体的性能。

3 结语

Tomcat的性能调优需要结合服务器硬件、操作系统和Web程序对资源的需求, 从堆、栈、线程池、连接池等多方面进行调整, 需要不断地测试, 才能找到合理的参数配置。使用测试工具查看测试结果, 监视工具监视服务器端状态, 分配的各种参数要协调, 使各个环节相对平衡, 这样才能发挥整体性能, 提高并发量。比如, 虽然堆内存中存放着JAVA对象, 需要较多的空间, 但是如果单方面将堆内存设置过大, 反而会使Tomcat的运行变慢, 因为操作系统会缺乏必要的内存资源, 其它参数对应的功能所需的资源也得不到满足, 过度的堆内存反而会白白浪费掉, 线程池、连接池等的设置也是同样的道理。还可以精简配置, 释放不必要的资源和功能, 比如关闭AJP Connector、DNS查询等。

摘要：为使Tomcat能更好地服务大量的并发请求, 提出了不断地进行性能监视、调优、再监视、再调优, 直至系统的各个环节达到相对平衡的思路。可以使用测试工具查看测试结果、监视工具监视服务器端状态, 结合服务器硬件以及操作系统和Web程序对资源的需求, 从堆、栈、线程池、连接池等多方面进行整体调整。实验结果表明, 该方法可以有效提高Tomcat的性能。

关键词：Tomcat,性能监视,系统调优,测试工具,监视工具

参考文献

[1]李萍.浅谈TOMCAT之性能优化[J].科技情报开发与经济, 2011 (12) .

[2]赵岗耀.用Lambda Probe监控Tomcat实例的内存使用[J].软件导刊, 2009 (3) .

[3]高张, 康小军.提高Tomcat服务器运行性能的研究[J].计算机与数字工程, 2008.

[4]JASON BRITTAIN, IAN F DARWIN.Tomcat权威指南[M].第2版.北京:中国电力出版社, 2009.

[5]VIVEK CHOPRA, SING LI.Apache Tomcat高级编程[M].北京:人民邮电出版社, 2009.

性能调优 篇2

数据库的逻辑设计、包括表与表之间的关系是优化关系型数据库性能的核心，一个好的逻辑数据库设计可以为优化数据库和应用程序打下良好的基础。

标准化的数据库逻辑设计包括用多的、有相互关系的窄表来代替很多列的长数据表。下面是一些使用标准化表的一些好处。

A:由于表窄，因此可以使排序和建立索引更为迅速

B:由于多表，所以多镞的索引成为可能

C:更窄更紧凑的索引

D:每个表中可以有少一些的索引，因此可以提高insert update delete等的速度，因为这些操作在索引多的情况下会对系统性能产生很大的影响

E:更少的空值和更少的多余值，增加了数据库的紧凑性由于标准化，所以会增加了在获取数据时引用表的数目和其间的连接关系的复杂性。太多的表和复杂的连接关系会降低服务器的性能，因此在这两者之间需要综合考虑。

定义具有相关关系的主键和外来键时应该注意的事项主要是:用于连接多表的主键和参考的键要有相同的数据类型。

2 索引的设计

A:尽量避免表扫描

检查你的查询语句的where子句，因为这是优化器重要关注的地方。包含在where里面的每一列(column)都是可能的侯选索引，为能达到最优的性能，考虑在下面给出的例子:对于在where子句中给出了column1这个列。

下面的两个条件可以提高索引的优化查询性能!

第一:在表中的column1列上有一个单索引

第二:在表中有多索引，但是column1是第一个索引的列

避免定义多索引而column1是第二个或后面的索引，这样的索引不能优化服务器性能

例如:下面的例子用了pubs数据库。

SELECT au_id, au_lname, au_fname FROM authors

WHERE au_lname = ’White’

按下面几个列上建立的索引将会是对优化器有用的索引

?au_lname

?au_lname, au_fname

而在下面几个列上建立的索引将不会对优化器起到好的作用

?au_address

?au_fname, au_lname

考虑使用窄的索引在一个或两个列上，窄索引比多索引和复合索引更能有效。用窄的索引，在每一页上将会有更多的行和更少的索引级别(相对与多索引和复合索引而言)，这将推进系统性能。

对于多列索引，SQL Server维持一个在所有列的索引上的密度统计(用于联合)和在第一个索引上的histogram(柱状图)统计。根据统计结果，如果在复合索引上的第一个索引很少被选择使用，那么优化器对很多查询请求将不会使用索引。

有用的索引会提高select语句的性能，包括insert,uodate,delete。

但是，由于改变一个表的内容，将会影响索引。每一个insert,update,delete语句将会使性能下降一些。实验表明，不要在一个单表上用大量的索引，不要在共享的列上(指在多表中用了参考约束)使用重叠的索引。

在某一列上检查唯一的数据的个数，比较它与表中数据的行数做一个比较。这就是数据的选择性，这比较结果将会帮助你决定是否将某一列作为侯选的索引列，如果需要，建哪一种索引。你可以用下面的查询语句返回某一列的不同值的数目。

select count(distinct cloumn_name) from table_name

假设column_name是一个10000行的表，则看column_name返回值来决定是否应该使用，及应该使用什么索引。

Unique values Index

5000 Nonclustered index

20 Clustered index

3 No index

镞索引和非镞索引的选择

<1:>镞索引是行的物理顺序和索引的顺序是一致的。页级，低层等索引的各个级别上都包含实际的数据页。一个表只能是有一个镞索引。由于update,delete语句要求相对多一些的读操作，因此镞索引常常能加速这样

恒温箱温度计量性能参数的调优 篇3

目前, 恒温箱配套的温控仪表多为智能数字仪表, 参数调优可通过调整温控仪表的内置参数值或采用其他措施来实现。 恒温箱参数调优分为单一参数调优和多参数调优。

1 单一参数调优

单一参数调优指恒温箱的三个温度计量性能参数中只有一个参数超出要求范围, 需要进行调优。

1.1 温度偏差Δtd调优

温度偏差是恒温箱在稳定状态下, 显示温度平均值与工作空间中心点实测温度平均值的差值。 引起温度偏差过大的原因有: 1) 测温探头示值误差偏大; 2) 温控仪表示值误差偏大; 3) 测温探头置恒温箱内的角落, 其温度与中心点温度相差较大。

措施: 1) 更换准确度高的测温探头, 减小控温装置的综合误差;2) 改变温控仪表温度示值修正值 ( 零点修正值) 或通过修正温度示值曲线 ( 斜率值) , 使 Δtd满足使用要求; 3) 改变测温探头的位置, 在不影响样品放置前提下, 使测温探头接近恒温箱工作区域中心点。 在不改变测温探头位置的情况下, 通过置换大网格的搁架板, 或加装强制对流风扇, 改善恒温箱内气体流动状况, 减小角落与中心点的温度差值。

1.2 温度波动度Δtt调优

温度波动度是恒温箱在稳定状态下, 工作空间中心点温度随时间的变化量。 引起温度波动度过大的原因有: 1) 温度控制质量不好; 2) 电加热功率不匹配。

措施: 1) 参考PID参数整定的相关方法或根据经验恰当地选择温控仪表P、 I、 D值, 也可启动仪表自整定功能, 自动确定P、 I、 D值, 使温度曲线平滑, 减小温度波动幅度; 2) 改变加热功率为匹配功率, 对加热功率可调的恒温箱, 根据温度设定值的高低, 合理选择加热功率, 减少温度调节的过冲量和波动幅度。

1.3 温度均匀度 Δtu调优

温度均匀度是恒温箱在稳定状态下, 在规定时间内多次测试中实测最高温度与最低温度之差的算术平均值。 温度均匀度过大的原因有:1) 热对流通道不通畅; 2) 强制对流功能变差或关闭。

措施: 温度均匀度取决于恒温箱内气流循环的充分程度, 温控仪表参数的调整只能改变恒温箱的温度偏差 Δtd、 温度波动度 Δtt, 对温度均匀度 Δtu的改善不明显。 要改善温度均匀度 Δtu只能采用其他措施。

1) 自然对流的恒温箱, 可置换大网格的搁架板, 清理气体流动通道或加装强制对流风扇, 改善气体流动状况; 2) 配备风扇的恒温箱, 置风扇于运转状态, 检查风扇转速是否正常, 风扇叶片是否变形, 如有异常应修复, 使强制对流功能恢复正常。

2 多参数调优

多参数调优指恒温箱的三个温度计量性能参数中有一个以上参数超出要求范围, 需要进行参数调优。

由于温控仪表参数的调整比较容易改变恒温箱的温度偏差 Δtd、 温度波动度 Δtt, 对温度均匀度 Δtu的改善不明显, 采用其他措施改变均匀度 Δtu, 会或多或少地影响温度偏差 Δtd和温度波动度 Δtt。 因此, 多参数调优通常按温度均匀度 Δtu→温度波动度 Δtt→温度偏差 Δtd调优的顺序进行。 先调优温度均匀度 Δtu, 缩小恒温箱内工作空间温度的相差幅值, 再整定P、 I、 D值, 调优温度波动度 Δtt, 降低恒温箱内工作空间温度的波动幅度, 最后, 进行温度偏差 Δtd的调优, 减小恒温箱温度显示值与工作空间中心实际温度值的差值。 具体操作按单一参数调优的方法进行。

3 几点说明

1) 恒温箱参数调优措施的实行, 应遵循效果优先先易后难先简后繁的原则。 在单一参数调优和多参数调优的措施中, 存在难易程度的不同; 存在成本的高低; 存在操作简单与复杂程度的不同。 在调优实践中, 应认真分析原因, 积累经验, 采用针对性措施, 高效又低耗地解决问题。

2) 恒温箱的温度计量性能参数, 一般是恒温箱在空载条件下, 达到稳定状态时的校准结果, 其数值容易复现。 如果是根据用户需要, 在负载条件下的校准结果, 其数值随着负载的不同而变化, 不能据此校准结果判定恒温箱是否需要进行参数调优。

3) 用户正确配备恒温箱时, 试验对恒温箱参数的要求与J J F1101- 2003 一致, 可依据J J F1101- 2003 叛定恒温箱是否适合试验使用。 但在用户“ 高配” 选择恒温箱时, JJF1101- 2003 的要求明显高于试验的要求, 不可依据JJF1101- 2003 叛定恒温箱不适合试验使用, 恒温箱参数是否需要调优, 本文不予置评。

4) 恒温箱经过参数调优, 温度计量性能参数通常都会回复到规范要求的范围内, 满足使用要求。 如果仍存在温度偏差 Δtd不满足要求, 可给出温度偏差 Δtd值, 供用户修正温度设定值和温度显示值, 恒温箱带修正值继续使用; 如果仍存在温度均匀度 Δtu或温度波动度 Δtt不满足试验的要求, 建议用户停用该恒温箱。

5) 加装强制对流风扇, 改善箱内气体流动状况, 应根据恒温箱工作空间的大小和使用情况, 合理选择风扇电机功率和叶片尺寸, 并考虑耐高温和防潮湿能力, 安装位置的选择以改善箱内气体流动效果为先, 且不影响正常使用和不影响样品的放置为宜。

参考文献

调优种植结构 实现提质增效 篇4

实现提质增效

—农业服务中心（农技站）2017年终工作总结

一、2017年主要工作情况

2017年，农业服务中心（农技站）根据镇党委、镇政府提出的“加快实现农业现代化大突破”的总要求，立足自身职能，围绕生态农业，突出绿色发展，实现全镇农业工作取得新成效。

1、品种结构优化。抓住市委、市政府打造“兴化大米”品牌的这一契机，大力推广优质食味水稻品种南粳9108，种植面积占全镇水稻面积的85%以上，建立13600多亩优质水稻生产基地，实行订单生产，全程监管，通过质量、品牌的提升实现农民增收。

2、推广高效模式。大力推广生态立体种养模式，全镇“稻虾共作”、“稻鸭共作”面积达450亩，“水稻+香葱”、“水稻+洋葱”、“水稻+草莓”等特色高效种植面积达200多亩。

3、打造信息高速。大力实施互联网+农业，建设覆盖全镇各村的益农信息社，并对信息员开展培训，构建覆盖全镇、立足农业、服务农民的“信息高速公路”，为农民推送政策法规、生产技术等服务，实现优质农产品销售线上线下的融合。

4、完成目标任务。强化中心(农技站)的日常管理，全面完成各项市交任务，农产品检测合格率98%以上；举办种植大户培训班5期，培训360人次，完成持证农民培训600人；超额完成市交机插秧面积和集中育供秧池面积，主要公路沿线及通村公路实现机插秧全覆盖。

二、2018年主要工作目标

我镇地处兴化南大门，耕地面积大，土地流转率高，但与兴泰公路沿线的其它乡镇相比，农业发展特色不明、基地规模偏小、产品品牌较少，尤其是现代高效设施农业发展缓慢，使得兴化农业的南大门不靓。进入2018年，作为农业职能部门，我们将在镇党委、镇政府的坚强领导下，立足新形势、理清新思路、努力新作为、争取新业绩，突出“四个强化”，加快实现全镇农业再上新台阶。

一是强化规划引领。认真贯彻落实镇党委、镇政府的决策、部署，积极组织开展全镇现代农业发展规划的编制，引领全镇农业转型升级，做靓兴化农业的南大门。

二是强化上争招引。发挥资源优势，积极上争农业项目，并强化招商引资，实行人人有责、全员招商，着力培育新型经营主体3个以上，力争创办田园综合体1个，新增高效设施农业面积200亩以上。

三是强化绿色发展。建成2万亩优质稻谷生产基地，扩大生态立体种养面积，其中稻鸭共作2000亩、稻虾及稻渔共作800亩，全镇统防统治、测土配方施肥的面积达80%以上，申报绿色农产品2个，全镇“三品”数量占可食用农产品总量的70%以上。

性能调优 篇5

1 数据库性能的评价依据

优化数据库系统的性能, 通常是采取相应措施, 既减少对磁盘的访问而又能获得用户所需要的相关数据, 以达到降低系统对用户的响应时间、提高数据吞吐量、提升数据库的可用性的目标。评价一个数据库的性能是否优异的一些通用准则如下所述。

1.1 系统响应时间

系统响应时间是指从用户按下提交按钮到数据显示在输出设备上所花费的时间。系统响应时间是评价数据库性能的一项重要指标, 很多客户对系统响应时间都有严格的要求, 因此缩短系统响应时间非常重要。

1.2 数据加载时间

为满足加载数据的时间需求, 管理员可调整计算机的I/O子系统缩短数据加载时间, 而系统其他方面的性能会由此受到影响。此时可分别调整系统的数据库运行性能和数据加载性能, 将影响减至最小。

1.3 系统实际吞吐量

吞吐量是指在给定单位时间内传送的位 (bit) 数量。实际吞吐量是指在给定间隔内接收到的用户数据量减去必须重新传输的字节数后的吞吐量。提高系统吞吐量的方法为:1) 减少系统总的响应时间;2) 减少服务时间。

1.4 对用户支持能力

另一个评价系统性能的重要因素是系统对用户的支持能力。要使系统能支持更多的用户, 必须对系统在相关方面进行配置和调整。

2 影响数据库系统性能的主要因素

通过对数据库性能评价依据的分析, 发现很多因素都会影响Oracle 10g的性能。比如:数据库服务器、CPU、内存、网络、I/O、应用程序性能以及由用户所产生的数据库负载等。

下面列出的是一些导致系统性能下降的主要因素:

1) 数据库服务器:数据库服务器由数据库和实例组成, 是整个管理系统的核心。数据库的主要功能是保存数据, 其存储结构分为逻辑存储结构和物理存储结构。物理存储结构描述Oracle外部及其所处的操作系统环境中文件组织和管理数据的方式, 逻辑存储结构描述Oracle内部组织和管理数据的方式。

Oracle实例是指数据库服务器的内存及相关后台进程, 又称为Oracle数据库引擎。启动数据库后, 由实例来访问和控制磁盘中的数据文件。实例由SGA (System Global Area, 系统全局区) 和后台处理进程组成。

2) CPU:如某个数据库事务或其它应用占用了CPU资源, 其它数据库事务运行将可能会停滞, 从而延迟对数据库的响应。

3) 操作系统:操作系统控制和管理各种资源, 合理组织计算机系统的工作流程, 帮助用户合理利用和分配资源, 为用户提供方便的工作环境, 为多个用户提供安全高效的计算机资源共享。

4) 网络系统:系统的吞吐量和响应时间过长, 有可能是网络方面存在问题。数据库服务器与应用程序之间的交互是通过网络来进行的。在整个网络系统中, 影响较大的是网络I/O。I/O子系统如果超载, 系统输入输出量加大, 系统获得数据的等待时间延长, 从而影响整个系统的运行性能。

5) 实现应用程序:对数据库性能影响比较大的因素还包括实现应用程序的方法。如连接数据库的方式、SQL语句的灵活运用、使用数据库对象的情况以及数据库端程序设计等。

3 数据库系统性能调配优化的方法

通过对影响Oracle数据库性能的因素进行分析, 我们可以从以下几个方面对数据库系统进行配置, 以调整和优化系统的运行性能。

3.1 合理设计数据库

数据库的设计在系统设计中是一个非常重要的环节, 从根本上来说就是要实现数据的共享和安全存取。一个优秀的数据库设计必须要实现用户对于数据的要求, 而同时又要实现对数据的关联性、安全性、可移植性和可扩容性的要求等。

1) 明确系统所属的数据库类型。

在进行数据库设计时, 先要分清楚数据库所属的类型, 常见的有在线分析系统 (OLAP) 和在线事务处理系统 (OLTP) 。数据库的内存效率, 内存各种指标的命中率、并发操作控制等, 是在设计OLTP系统时特别要注意的。而数据分析、SQL执行时间、磁盘I/O及强调分区等。在设计OLAP系统的设计时要特别强调。现在购买火车票使用的网上订票系统, 就是一个典型的OLTP系统。如并发操作考虑不充分, 当遇到春节期间在线购票的用户太多时, 有可能导致系统近于瘫痪。

根据自己的经验设计数据库, 将系统资源分配给相关的用户, 尽量限制应用程序的用户数量, 对系统资源的使用情况密切监控, 了解用户所使用的资源数, 重视监控系统, 对系统调整及其结果做好详细记录。

2) 创建适用的数据文件。

每个Oracle数据库都有一个或多个数据文件, 数据库的主要作用是来保存在这些相关的数据文件。通过使用命令:select status, bytes, name from v$datafile, 可以查看数据文件的存放位置、大小和状态。OLTP系统是SQL语句提交和数据块变化都非常频繁的系统。为减少重复的SQL解析和物理I/O, 可采用变量绑定技术实现SQL的重用, 同时让数据块尽可能的保存在内存中, 以改善和提高数据库的性能。

3) 正确使用索引。

正确创建和正确使用索引具有很多优势。如在快速存取数据、实施数据的唯一性和参照完整性、多表检索查询数据时, 利用索引可以减少排序和分组的时间, 减少系统开销。对于Oracle系统来讲, 并不是创建了索引就一定会使用索引, 当Oracle自动搜集了表和索引的统计信息之后, 才会确定是否要使用索引, 只有高选择性的索引才会比全表扫描更有效率。因此, 对于规模比较小的表、频繁进行更新的表、在查询中很少用到的列等, 建议不要创建索引。

索引建立后会将占用磁盘空间, 当对数据进行插入、更新和删除等操作等操作后, 系统将重建索引, 延长了数据修改的时间, 所以, 应在需要的时候才创建索引, 在不需要索引时将其删除。适合建立索引的字段列一般为:主键列、表的外键、经常用于查询或多表连接的字段列、经常用于WHERE子句、ORDER BY子句、或GROUP BY子句的字段列等, 在这些字段列上创建索引, 会加快检索的速度。而对于在查询中很少使用的列、在表中具有较多重复值的字段列、数据需要频繁变更的字段列则不宜创建索引。因为在这类字段列上建立索引, 其检索性能会远远小于其修改性能, 得不偿失。

3.2 调整与优化内存管理

Oracle的内存结构包含两个部分:系统全局区 (SGA) 和程序全局区 (PGA) 。SGA主要包括了以下的数据结构:数据缓冲、重做日志缓冲、共享池、Java池、大池、流池、数据字典缓存及其他信息等, 这些部分的分配是否合理直接影响数据库的性能。

内存不足将减少数据的缓冲区空间, 影响系统访问最近存放的数据, 从而导致操作系统进行页面交换时频繁使用虚拟内存, 使计算机系统增加额外的I/O开销。

对那些支持大量连接的系统, 为保证计算机系统的可用资源能适用不同的用户对系统的资源需求, 要对内存做好详细计划, 严格控制与网络和连接用户有关的操作系统资源。

3.2.1 数据缓冲区

Oracle系统最近使用过的数据库数据块存放在数据缓冲区中。当用户下一次访问相同的数据时, 系统直接从数据缓冲区中读取数据返回给用户, 缩短查询时间。如果用户请求的数据不在数据缓冲区中, 则服务器进程要再次到数据文件中去读取数据给用户, 查询时间将延长。因此, 尽可能多的将用户请求数据保存在缓冲区中, 能较大的提高数据的操作性能。

许多大小相同的缓冲块组成了数据缓冲区。Oracle的数据缓冲区的大小直接由初始化参数文件中的db_cache_size参数决定。Oracle允许指定不同的数据块大小, 其中标准块的大小由db_block_size定义, 而非标准块的数据缓存区大小由db_nK_cache_size定义, 其中n为2、4、6、8、16或32。标准块和非标准块大小之和构成了数据缓冲区的实际大小。如, 假设在某个初始化参数文件中具有如下设置:

以上说明数据库标准块的大小为4KB, 具有标准块的大小的数据缓冲区为1024M, 除此之外还有块大小为2KB的数据缓冲256MB, 块大小为8KB的数据缓冲512MB。

使用较大的数据缓冲区, 可以提高数据库的访问性能。但数据缓冲区过大, 会给有限的系统物理内存带来压力, 数据库和操作系统其他方面的性能将受到影响。如果要查询数据缓冲区的大小, 可以使用具有DBA权限的用户按如下方法查看:SQL>show parameter db。

检查数据库缓冲区大小还可以通过查看数据缓冲区空闲率 (Free Ratio) 以及命中率 (Hit Ratio) 来实现。

1) 空闲率的检查方法

查询数据字典v$latch_children可以检测数据缓冲区是否有空闲, 得到的空闲冲突比例应该接近于0, 否则可以减少数据缓冲区大小。

2) 查询数据高速缓冲区的命中率的方法

计算公式:Hit Ratio=1- (physical reads/ (db block gets+consisten gets) ) 。

若命中率低可以加大INITXXX.ORA中DB_BLOCK_BUFFER的值。如果发现命中率低于90%, 则应该调整应用, 考虑是否增大数据缓冲区。

3.2.2 共享池

库缓冲区和数据字典缓冲区组成了系统的共享池, 可对SQL、PL/SQL程序进行语法分析、编译、执行。库缓冲主要用于存放已经解释并执行过的SQL语句和PL/SQL程序代码及其分析、执行计划等信息;数据字典缓存主要用于存放数据库对象表、索引、列定义以及用户权限等信息。必须合理设置共享池大小, 使共享池中保存较多的信息, 降低重复执行相同的SQL语句和PL/SQL程序的相同开销, 提高数据库的性能, 提高SQL或PL/SQL程序的执行效率。

共享池的大小由初始化参数shared_pool_size决定, 运行过程中使用alter system语句修改共享池的大小, 例如:SQL>alter sys-tem set shared_pool_size=20M;。

用以下方法查询共享池的大小:

可以通过共享池的空闲率、库缓存命中率以及数据字典缓存命中率来检查共享池设置是否合适。

1) 共享池内存空闲率

计算结果小于20%, 应该增大共享池的大小

2) 共享池命中率

Select sum (pinhits) /sum (pins) *100“hit radio”from v$librarycache;

如果共享池的命中率低于95%就要考虑调整应用 (通常是没应用bind var) 或者增加内存。

3) 库缓存命中率

Oracle文档对于数据库缓存命中率的定义为:

使用下列命令可以查询库缓存命中率。

库缓存命中率显示了对实际语句和PL/SQL对象的内存读操作所占的百分比, 库缓存命中率应该高于99%。

终端用户访问加速节点时, 如果该节点有缓存住了要被访问的数据时就叫做命中, 如果没有的话需要回原服务器取, 就是没有命中。取数据的过程与用户访问是同步进行的, 所以即使是重新取的新数据, 用户也不会感觉到有延时。命中率=命中数/ (命中数+没有命中数) , 缓存命中率是判断加速效果好坏的重要因素之一。

4) 数据字典缓存命中率

数据字典缓存命中率显示了对数据字典和其他对象的内存读操作所占的百分比, 其值应该高于90%, 否则需要调整共享池大小。使用下列命令查询数据字典缓存命中率。

select (1- (sum (getmisses) /sum (gets) ) ) *100"Hit Ratio"from v$rowcache;

from v$rowcache;

3.2.3 重做日志缓冲区

重做日志缓冲区用于缓存在对数据进行修改的操作过程中生成的重做记录, 当数据达到一定量时, 由日志写入进程LGWR写入重做日志文件。重做日志缓冲区的大小由log_buffer初始化参数指定, 该参数也可以在数据库运行过程中动态修改。重做日志缓冲区的大小对数据库的性能有很大影响。重做日志缓冲区过小, 会增加写盘的次数, 增加了系统的I/O负担。通常较大的重做日志缓冲区能够减少重做日志文件的I/O次数。

要查询重做日志缓冲区的大小, 可以用以下方法查询:

2) 查询数据字典v$parameter

如果日志缓冲区已满, 但还没有写入日志文件则日志写入处于等待状态即日志缓冲区写入失败。过多的日志写入失败说明日志缓冲区偏小, 影响数据库性能。

失败率的计算方法:

日志缓冲区的写入失败率应该接近于0, 如果失败率大于1%, 则说明日志缓冲区太小, 应该增加LOG-BUFFER的大小。

3.2.4 PGA程序全局区

PGA (Program Global Area程序全局区) 是一块包含有关单个服务器进程或单个后台进程的数据和控制信息的内存区域。PGA在创建进程时分配, 并在终止进程时回收, 不能共享。在专有服务器 (Dedicated Server) 模式下, Oracle会为每个会话启动一个Oracle进程;而在多线程服务 (Multi-Thread Server MTS) 模式下, 由多个会话共享通一个Oracle服务进程。PGA由chunk组成, 大小由pga_aggregate_target参数决定。用下列命令查看PGA的大小。

PGA的排序区设置是否合理对数据库性能有一定的影响。当对数据进行排序时, 数据库系统会将需要排序的数据保存到PGA程序缓存区中的一个排序区内, 然后在这个排序区内对这些数据进行排序。如数据排序与读取的操作都能够在内存中完成, 可在很大程度上提高数据库排序与访问的性能。若发现用户的很多操作都需要用到排序, 设置较大的排序区, 可以提高用户访问数据的效率。

排序区的大小占据PGA程序缓存取的大部分空间。在小型应用中, 数据库管理员可以直接采用其默认的值。在大型的应用中, 管理员需要手工调整这个排序区的大小, 以提高排序的性能。为了提高数据访问与排序的性能, 通过初始化参数SORT_AR-EA_SIZE在适当的情况下调整排序区的大小。

查询内存和磁盘排序命中率。

通常情况下, PGA内存排序率的值应该大于98%。即保证绝大多数的排序操作在内存中进行。否则, 就应该调整排序区大小, 即增加SORT-AREA-SIZE的大小。

3.3 磁盘I/O调整

磁盘I/O操作是数据库性能最重要的方面, 影响Oracle 10g数据库系统性能的主要因素中还有磁盘的I/O速度, 为了避免与I/O相关的性能瓶颈, 采用以下方法优化磁盘I/O。

1) 数据库的物理文件尽量分散到不同磁盘空间, 将数据文件放在独立磁盘上;

2) 为索引创建单独的表空间, 在不同磁盘中存储表数据和索引数据, 减少它们对磁盘存储空间的竞争;

3) 创建不同的表空间以存放不同的应用, 减少不同应用之间对磁盘的竞争;

4) 设置足够大的重做日志文件, 并且要存放在与数据文件不同的磁盘上, 减少日志文件对磁盘的竞争;

5) Oracle的文件和操作系统文件应尽可能地放在不同的磁盘上;

6) 创建专用的表空间和回滚段, 当系统操作出现失败时可以恢复数据;

7) 单独创建表空间存放用户数据, 用户数据不要与系统表空间存放在同一磁盘;

8) 为方便排序操作创建一个临时表空间, 在减少在进行存储空间分配和空间回收时产生的碎片;

9) 一般的应用不要占用系统表空间, 每个应用最好建立一个独立的表空间, 减少普通应用与数据库系统的磁盘竞争;

10) 管理表空间尽量采用本地管理方式, 而存储空间的分配可以自动管理。

3.4 碎片整理

在数据库系统的运行过程中, 数据的存取操作不断进行, 数据库将寻找自由范围最大的表空间来存放数据, 从而形成越来越多的较小的、离散的自由空间, 即生成磁盘碎片。碎片整理就成为了数据库日常维护中的重要的工作环节。一般将碎片分为三级:表空间级、表级、索引级。

表空间级碎片的出现主要是由于DROP TABLE和TRUNCATE等操作引起的。由于一个表空间中的表的EXTENT大小不同, 因此表空间使用一段时间后, 表空间的使用就出现了不连续, 在EXTENT之间会出现一些“洞”, 这种情况称为表空间碎片。设置所有的EXTENT都一样大, 不会出现表空间碎片。

表级碎片是一些零散的存储空间。当对一个表进行删除操作时, 被删除的数据释放出的存储空间不会被插入操作立即重用, 这样就形成了表级碎片。当表级碎片过多时, 导致查询响应时间变慢、产生大量行迁移、行链接导致数据存储不连续、浪费存储空间等。整理表碎片可采用如下步骤:

1) 整理表

SQL>alter table TABLE_NAME shrink space compact;

2) 重置高水位

SQL>alter table TABLE_NAME shrink space;

shrink的优势在于可以进行在线操作, 而且不需要重建索引。

3) 索引和表数据是级联关系的。当表中有建有太多索引, 进行表中数据删除操作的时候, 索引值将频繁变化, 索引条目也会被自动删除, 这样在index leafblock就会产生碎片。当索引的碎片过多时, 会影响执行查询的速度。在OLTP系统中有大量更新的表上建议不要创建大量的索引, 低基数列上也不要创建索引。为快速查找数据, 只在那些数据变化频率较低的列上创建索引。在已建索引的列上出现频繁的数据变化, 拟制索引碎片的产生最好的方法是重建索引。

3.5 CPU性能调整

服务器中一个重要的资源就是CPU。当CPU资源被某个数据库事务占用或被其它应用占用, 可能会影响数据库事务运行, 导致数据库系统响应迟缓。若CPU占用率超过90%, 则说明Oracle服务器CPU资源不足。引起CPU资源不足的原因主要有:锁冲突、低效率的SQL语句、SQL语句的重解析等。查询变慢是CPU资源不足的主要表像, 其实质是严重影响了数据库的性能。

调整CPU, 减少服务器的CPU对数据库性能的不利影响, 提高数据库系统的性能。

1) CPU的技术发展很快, 在Oracle领域要重视CPU并行技术的应用, 在执行事务处理和查询时分别使用不同的CPU处理器。最好分开数据库服务器和应用程序的CPU请求, 或在请求较多时, 实行对服务器请求的转移, 即采用多个服务器请求。

2) 进行数据查询时可使用PQO方式。PQO方式的优势很明显, 当用户需要查询的数据存放在不同的磁盘时, 可将SQL语句的请求分配到多个CPU进行处理, 对彼此独立的进程同时实现数据读取。

3) Oracle数据库与运行在同一台服务器上的其他所有软件共享CPU资源。如果CPU处理能力不足, 减少Oracle或者非Oracle程序的CPU消耗可以改善服务器上所有进程的性能。

对CPU的利用率进行调优实质上就是对每个单独的任务进行调优, 减少完成任务所需要的命令数量。通过负载均衡, SQL调优, 以及改进应用程序的设计等方式来具体完成CPU调优工作。

4 Oracle 10g常用优化工具

Oracle数据库提供了一些优化工具, 包括Oracle数据库在线数据字典、操作系统工具、SQL语言跟踪工具、OEM等。通过查询数据字典、分析动态性能视图, 获取数据库的运行信息, 有效的进行Oracle性能优化的工作。以下是几种常用的Oracle数据库性能优化工具。

1) Oracle数据库在线数据字典

Oracle在线数据字典能够反映出Oracle的动态运行情况, 有利于调整数据库性能。

2) 操作系统工具

如使用Unix操作系统的Vmstat、Iostat等命令可以查看到系统级内存和硬盘I/O的使用情况, 这些工具能够帮助管理员弄清楚系统瓶颈出现在什么地方。

3) SQL语言跟踪工具

Oracle提供了SQL-TRACE工具用于进行SQL语句的跟踪。当启用SQL-TRACE工具后, 系统将很快启动内核跟踪程序, 完整记录会话等相关信息, 同时写到相应的跟踪文件中, 并将结果输出成一个操作系统的文件。

4) TKPROF工具

TKPROF是用于分析oracle跟踪文件, 按需求生成清晰合理的输出结果的可执行工具。当系统的执行效率比较低时, 采用此工具跟踪用户的会话, 分析输出的结果, 找出问题所在, 从而确定解决问题的方法。

5) Oracle Enterprise Manager (Oracle企业管理器)

Oracle企业管理器是一个图形管理界面, 使用Oracle企业管理器可以方便地实现对数据库的管理, 简化操作, 特别适合初学者使用。许多通过命令能够完成的操作都可以使用Oracle企业管理器来完成, 如管理表、管理视图、管理表空间、管理索引等。

6) 优化SQL语句

使用这个命令可以帮助程序员写出高效的SQL语言。

7) DBMS-PROFILER (DBMS分析器)

代码的性能瓶颈在进行数据库调优时至关重要, 若要方便的发现代码的瓶颈所在之处, 使用Oracle数据库提供的DBMS_PRO-FILER包是比较好的选择。它可以对函数、触发器、存储过程及PL/SQL程序等进行测试, 发现影响程序性能的地方, 以及时进行改进。

说明:DBMS_PROFILER需要先安装再使用。

8) ADDM

ADDM是Oracle 10g新增的性能优化工具, 是植入Oracle数据库的一个自诊断引擎。ADDM通过检查和分析AWR获取的数据来判断Oracle数据库中可能的问题, 而STA则根据这些数据, 给出优化建议。ADDM能发现的问题主要有:负载导致的CPU瓶颈问题、过多的连接、过多的软解析、过多的commit和rollback事件以及由于shared pool过小、解析失败原因引起的过多硬解析问题等。

5 结束语

Oracle10g数据库系统性能调优是复杂繁琐的系统工程, 其工作贯穿于整个数据库系统开发的过程。从系统配置入手, 包括内存分配调整、磁盘I/O调整、操作系统调整以及磁盘碎片整理等, 整个过程是一个有机的整体, 缺一不可。数据库系统的性能调优应该充分利用各种能优化性能的资源, 正确使用调整工具进行反复的调整、以获得系统的最优性能。

参考文献

[1]朱亚兴.Oracle数据库系统应用开发实用教程[M].北京:高等教育出版社, 2012.

[2]文平.Oracle数据库性能优化的艺术[M].北京:机械工业出版社, 2012.

[3]姚世军.Oracle原理与应用[M].北京:中国铁道出版社, 2010.

[4]孙凤栋, 闫海珍.Oracle10g数据库系统性能优化与调整[M].计算机技术与发展2009 (2) .

[5]魏亚楠, 宋义秋.Oracle数据库应用系统的性能优化[J].制造业自动化, 2010 (8) .

[6]罗瑞明.Oracle数据库的性能优化方法研究[J].信息安全与技术, 2012 (5) .

数据库系统性能调优的研究与实践 篇6

在甘肃烟草商业全省大集中的业务信息系统数据库性能调优工作实践中, 笔者认为在系统调优的具体工作中, 须综合考虑数据库系统缓冲池大小、数据结构、锁争用和应用程序需求间的复杂关联, 通过一系列的调优以达到控制内存的使用、避免过度消耗CPU、提高磁盘的效率、减少网络通讯开销。

1 原因分析与应对

造成数据库系统性能下降的原因很多, 但是由于对系统配置或使用不当, 而造成的系统性能下降情况较为普遍, 以下是对调优工作中遇到的一些具体情况。

1.1 对大型表重复排序

在对大型表进行重复的排序时, 通常都会对数据库系统造成很大的性能负担。如果能够利用索引自动以适当的次序产生输出时, 可以避免排序的步骤。

1.2 索引使用不当

使用索引可以快速、直接、有序的存取数据。索引的建立虽然加快了查询, 另一方面却将低了数据更新的速度, 因为新数据不仅要增加到表中, 也要增加到索引中, 索引还需要额外的磁盘空间和维护开销。

1.3 distinct使用不当

使用distinct是为了保证在结果集中不出现重复值, 但是distinct会产生一张工作表, 并进行排序来删除重复记录, 这会大大增加查询和I/O的操作次数。应避免使用distinct关键字。

1.4 负逻辑使用不当

负逻辑如!=、<>、not in等, 都会导致数据库用表扫描来完成查询。当表较大时, 会严重影响系统性能。

1.5 通配符匹配使用不当

在SQL语句中, LIKE关键字支持通配符匹配, 但这种匹配特别耗费时间。如果采用顺序扫描的方式, 需要表中的记录一一比较。如果把语句查询条件改为“>”或“<”等, 在执行查询时就会利用索引来查询, 显然会大大提高速度。

1.6 数据类型使用不当

主键用字符型的比较开销要比整型的比较开销大很多, 用字符型数据作主键会使数据插入、更新与查询的效率降低。

2 系统调优方法与实践

2.1 创建索引

在经常进行连接, 但是没有指定为外键的属性列上建立索引, 如果待排序的列有多个, 可以在这些列上建立复合索引 (compound index) , 即索引由多个字段复合而成。

案例一, 在电子商务系统运行过程中发现一张查询订单的报表随着数据量的增大, 查询越来越来慢, 性能问题日益严重, 于是抽取出sql, 进行了优化分析。

Sql内容如下:

SELECT ORG_ID, REF_TYPE, REF_ID, ITEM_ID, PUT_LIMIT, POWER_UP, POWER_DOWN, PRIORITY FROM SRM_CUST_ITEM_MON_LIMIT WHERE ORG_ID='000000000010374' AND REF_TYPE!='02' ORDER BY PRIORITY ASC

利用分析工具Quest Central for DB2对sql进行分析, 得到如图1所示的分析结果, 整个sql的花费为1708.97, 其瓶颈出现在SRM_CUST_ITEM_MON_LIMIT表上不存在ORG_ID列的索引而产生了全表扫描, 该步花费为1702.98, 占整个sql花费的99%, 并且上图中括号标出了该步所花的代价, 解决该问题只有优化第一步, 即通过在该表创建ORG_ID列的索引。

创建索引

通过分析在优化后整个sql的花费值降为377.47 (见图2) , 该sql的优化成功完成。

2.2 优化查询

在SQL语言中, 一个查询块可以作为另一个查询块中谓词的一个操作数。因此, SQL查询可以层层嵌套, 但嵌套查询代码编制不当, 将会带来数据库系统性能问题。

案例二, 在数据库系统中, 有订单表Order、订单信息表OrderDetail, 在需要两表关联查询, 且一个列的标签同时在主查询和where子句中的查询中出现时, 很可能当主查询中的列值改变之后, 子查询必须重新查询一次。查询嵌套层次越多, 效率越低, 因此应当尽量避免子查询。如果子查询不可避免, 那么要在子查询中过滤掉尽可能多的行。

2.3 清理临时表

在复杂查询中使用临时表 (使用临时表时数据库会在磁盘中建立相应的数据结构) 时, 中间结果会被导入到临时表中, 这种磁盘操作会大大降低查询效率, 在进行复杂查询时最好不要使用临时表。

2.4 避免表死锁

DB2数据库中可以对表空间、表、表列和索引加锁。锁的粒度越大, 锁越简单, 开销小, 并发度低;粒度小, 锁机制复杂, 开销大, 并发度高。并发处理中如果遇到所要分配的资源处于锁定状态, 系统会把进程挂起等待。

案例三, 电子商务系统实际运行过程中, 多次遇到一个很耗时的查询操作工作于一个使用频度较高的表上, 导致由行级锁升级为表级锁, 出现锁表现象, 只能通过人为终止 (kill) 持有锁的进程, 方可释放资源。

出现锁表现象时, 首先抓取数据库快照, 在快照文件中检索关键字:Name of table holding lock, 可以查询到持有锁的进程, 通常情况下, 解决方法可能涉及到两个方面, 一是需要分析sql语句, 通过优化sql;二是直接的解决方法, 调大数据库locklist和maxlocks参数的值。

2.5 分离数据库

电子商务系统在运行一段时间之后, 随着数据量成倍增加, 查询所带来的物理I/O, 以及各方面压力会越来越大。在电子商务系统中, 为解决该问题, 部署了交易业务数据库 (TD) 和历史查询数据库 (HD) , 数据库采用联合体技术进行查询访问。从表级别上进行规划业务库和历史库, 而存储上是物理分离的, 有效地进行负载分担。

2.6 设置应用系统日志

案例四, 电子商务系统每次垃圾收集时间间隔范围为60-80秒左右, 每次垃圾收集占用时间为250毫秒左右, JVM垃圾收集等情况比较正常。而在出现内存异常生成javacore文件的时候, 内存申请异常的大, 达到了15.4MB。虽然JVM中还有65% (1024MB) 的空闲内存, 但是由于连续空间不能满足这一次的巨大申请, 造成了连续的垃圾回收, 最终导致了内存溢出现象的发生。

分析当时正在运行的线程, 内存溢出就可能是该线程一次申请内存过大引起的。经检查程序, 发现日志输出级别为debug级, 输出很大, JVM负担较重。随后, 检查其中日志操作的合理性, 修改应用程序包, 调整日志级别, 删除不必要的日志操作, 减少对字符串 (String) 追加操作的使用, 尤其是和Collection类型对象的追加操作的使用, 问题得到了解决。

3 结束语

系统调优是信息系统运行过程中的一项长期要做的工作, 在进行系统调优的工作时, 确定好调优目标, 明确要分析的信息, 要使用什么类型的监控工具, 采集监控数据, 分析监控信息, 制定解决方案, 实施解决方案, 有的放矢的稳步进行数据库系统性能调优, 才能使其性能得到持续提高。

摘要：文章从影响数据库系统性能的主要因素开始讨论, 列举了数据库事务处理、索引、表结构、应用系统接口四个常见的对数据库系统性能产生影响的因素, 并针对这些因素分析了系统性能不佳的具体原因, 结合甘肃烟草商业电子商务系统调优实践, 从创建索引、优化查询、清理临时表、避免表死锁、分离数据库、设置应用系统日志六个方面, 引用实际案例, 对数据库系统性能调优的基本方法进行了论述。本文希望能够为从事数据库系统管理工作的人员提供有益的经验和参考。

关键词：软件维护,系统性能,调优,方法,索引,死锁,日志

参考文献

[1]Dennis Shasha (美) , Philippe Bonnet (美) 著;孟小峰, 李战怀等译.数据库性能调优——原理与技术[M].电子工业出版社2004.

[2]Don Chamberlain A Complete Guide to DB2 UnibersalDatabase[M].Morgan Kauf mann, 1998.

[3]Serge Abiteboul, Richard Hull, and Victor Vianu.Foundations of Databases[M].Addison-Wesley, 1995.

DB2数据库性能监控和调优实践 篇7

1、DB2数据库性能监控介绍

DB2数据库具有很高的实用价值, 在大型服务器的管理中使用比较广泛, 数据库具有逻辑数据设计分析能力, 可以根据已知数据关系制作图表框架, 在各领域的应用都能够根据用户的需求对数据进行直观反映。

数据库数据采集方面, 需要使用者从数据收集的方向进行数据设计, 明确数据使用的需求, 如物理数据分析需要对标准量单位进行拟定, 根据公式将已知数据进行录入, 以达到运算的目的。在办公方面, 需要工作人员将客户的需求以特定编码形式存在, 数据库可以根据录入编码进行解析, 分析客户的需求倾向, 对客户信息进行管理。数据库的设计是以人性化为研发导向, 以使用者的需求为数据库管理的条件, 以使用者的视角设计数据处理方式。就目前DB2数据库的使用情况来看, 数据库可以根据动态数据模拟出用户的规划和需求, 只要使用者确保关联数据的全程输入, 不遗漏关键信息, 数据模型的建立就比较完善。

DB2数据库还具有模拟逻辑和物理运算功能, 数据库根据使用者采样实体进行数据填充, 确立数据之间的关系, 由此建立数学逻辑分析模型, 直观地反映出变量的关系;另一方面, 通过数据储存和模型图表的记录过程, 对不同数据类型、编码长度进行区分储存, 更为人性化的是数据库能够做到实时的数据更新, 将使用者常用的数据及关联资料独立分为一类, 将不常用的数据进行备份, 通过设置关键数据检索, 可以很快找到使用者需要的数据, 在数据备份方面能够保证数据以及数据关系的完整性。数据库逻辑数据处理清晰, 对数据关系以及变量关系能够自动区分, 数值的时间变量可以根据使用者对数据的填充进行自动排列, 方便数据的整体采集。如果在一个数据表中对某变量的使用规模比较大, 使用频率也比较高, 对于数据关键信息点的查询要素也会比较全面;另外, 历史数据备份可以把不常用的数据进行分割, 以某个常用数据做为变量关系的焦点, 不常用数据以数据关系的形态隐藏在常用数据之中, 使用者在对常用数据的清理过程中就可以发现不常用变量与常用数据之间的关系, 这对于逻辑数据备份、分析效率的提高都具有明显作用。数据图表的建立需要遵循数据逻辑性原则, 变量的取值范围有规定的限度, 这就对于采样数据的选择方面具有明确的要求。

DB2数据库的软件应用也比较广泛, 其中包括:数据库编程软件、储存优化应用工具、语句/编码优化工具以及数据检索等功能,

2、DB数据库优化目标

DB数据库的优化是对数据库组件性能的改进和提升, 以达到数据库容量的扩展和数据运算速度的提高, 另一方面, 数据库的优化也是提高数据库人性化水平, 使之更加适应使用者的操作需求。

对于DB2数据库的优化目标需要建立一个可行性的量化标准, 明确数据库需要优化的组件有哪些, 组件的优化又分别需要增强什么方面的性能, 优化的参数取值范围是多少等等, 数据库的优化必须依照可行性原则进行分析, 在数据库进行优化设计之前做好相关数据的执行效果的评估, 首先要对数据库目前存在的问题进行了解, 对于数据库使用性能方面的提升要慎重考虑, 由于数据库具有自身独特的设计理念, 对于数据处理功能都是经过多次试验之后才进行设计的, 因此数据库功能可能是数据库技术的“瓶颈”, 需要理智去看待性能提升问题, 避免不合理提升对源代码的损坏, 在数据库优化方案取样过程中, 要关注数据库存在问题的表现形式, 避免无目标设计对数据库的性能带来的负面影响。

一般说来, 数据库优化主要对以下方面进行分析:

(1) 对于数据库在系统中占用内存进行分析, 使数据库的使用能够达到目前硬件所能接受的标准;

(2) I/O处理能力提升, 要根据数据库应用类型进行设计, 对I/O处理能力的等级进行可调控性划分;

(3) 研究数据库网络加载能力, 尤其是服务器数据库需要满足大型网络加载水平;

(4) 数据组合信息的设定, 对于数据填充公式尽量采用新型公式运算法则, 避免运算法则不同带来的麻烦;

(5) 数据库检索信息系统的升级, 要根据数据库等级规模确定检索系统的检索能力, 提高数据库检索效率。

3、DB2数据库的优化

在数据库处理过程中, 处理速度是数据库性能的重要表现, 因此对于数据库的优化要尽可能使数据库少占用系统资源, 从提高数据库的读取性能方面入手。

数据库结构优化。数据库的储存方式和储存性能是数据库结构性能的重要体现, 数据一般储存在硬盘、内存或者二级缓存内, 因此, 数据库的结构优化要从储存空间的占用情况来进行分析。DB2数据表格是建立在磁盘驱动器上的, 一般数据库使用的驱动器越多, 储存效果越好, 对于储存空间的扩展也能够提升数据库的效能。对I/O内存计算模式的优化, 较少资源的占用率, 在数据分析运行时, 可以借助系统缓存进行优化, 把系统内存留给运算程序, 而数据库的缓存方案可以横跨多个磁盘驱动器, 减少每个磁盘的分区的负载负担;对于页面类型的设定可以采用独立的运行范围, 把使用表格页面和不活动页面的运行状态进行区分, 减少内存资源的占用;设置驱动器缓存清理插件, DB2数据库在同一页面上能够显示255行的数据信息, 但剩余数据信息以及数据隐藏关系也会被重新启用, 这势必会造成更多内存的占用, 对于数据库缓存优化可以借用系统缓冲区进行数据交换, 备份信息储存在系统缓冲区内。

DB2数据库逻辑计算能力的优化。逻辑数据计算需要整合数据与变量之间的关系, 从整体上讨论数据形成情况, 因此在数据的逻辑计算过程中, 要减少关联数据的排列情况, 另外可以采用转码形式将过长的数据进行分割转码, 在没有变量的运算过程中, 原数据保持一致, 转码数据可以进行隐藏。这样可以减少数据的排列对运算过程的复杂化, 减少关联索引对数据空间的占用, 在提高DB2数据库的计算速度。

对数据库内存的优化。数据库通过系统内存对数据处理、储存以及逻辑关系判定进行资源共享, 这就增加了应用程序对系统内存的占用。对于数据库内存处理参数可以进行优先设定, 把数据运算放在内存最优先处理的位置, 巧妙应用缓存以及虚拟内存分担数据库的数据处理负担, 必要情况下可以启动缓存清理插件对数据库运行资源进行优化, 对操作频繁的数据通过缓存进行备份, 待数据变量过程完成之后再进行磁盘储存。

SQL语句关系优化。客户需求分析是通过SQL的逻辑处理进行归类整合的, SQL同时还具备索引搜索功能, 对搜索结果进行优化筛选处理。因此BD2数据库对于SQL的优化体现出技术核心, SQL语句根据一定的语法规则和逻辑顺序进行识别认证, 提高SQL识别的准确性能够有效提升系统分析能力, 高效的SQL识别系统能够对于客户需求的方向有更准确的定位, 但SQL语言需要使用大量资源进行模拟。在数据检索方面, SQL索引可以包括WHERE句子的所有排列进行规范搜索, 避免ORDER BY句式在检索过程中的重复搜索, 对于检索条件的筛选进行优化。

DB2数据库图表分区的优化。DB2图表在系统分区上会占用过多的内存资源, 如果数据分布过于集中, 加大了运算难度, 这也就会造成系统运行缓慢。DB2图表的优化可以从大型图表中进行系统分割, 将数据进行分条备份储存, 减少空间的占用, 提高图表的运算效率, 。根据已有的数据表资源分区, 可以使每个备份资源都有独立的储存空间, 数据库引擎同时覆盖多个系统分区, 加快了数据的储存效率。

参考文献

[1]林子雨, 左思强, 赖永炫等.DB&IR系统研究综述[J].计算机研究与发展, 2010, 47 (z1)

[2]杨立平, 王小蕾.数据库中间件技术及在三层客户机/服务器模型中的实现[J].小型微型计算机系统, 2001, 22 (4)

[3]刘文涛.OLE DB技术及其在VC数据库开发中的应用[J].计算机工程与设计, 2008, 29 (2)

[4]王聪华.ADO访问数据库实例剖析[J].计算机应用研究, 2002, 19 (5)

[5]刘良俊.基于Oracle XML DB的XML文档存取技术[J].计算机应用研究, 2004, 21 (12)

[6]张黎明, 苏厚勤.Oracle DB动态SQL应用方法的研究与实践[J].计算机应用与软件, 2008, 25 (1)

流媒体服务器性能调优关键点分析 篇8

流媒体通常指音视频等多媒体技术在互联网上的传输, 典型的流媒体服务涵盖了音视频等媒体信息的存储、编解码、分发、传输等多种技术。流媒体服务器的性能指标既包括了并发、吞吐、响应时间等常见参数, 也包括音视频服务质量、直播切换时间等比较有特色的元素。

流媒体服务器系统售价通常以并发和吞吐为衡量指标, 考虑到当前的硬件成本逐渐下降, 主流流媒体服务器已经开始采用较高配置的硬件, 多CPU、高内存、光口的2U/4U设备已经被广泛引入[1], 基于这些新硬件的性能调优和以往也有了较大的区别, 而基于新硬件的性能调优讨论比较少, 本文将基于新硬件进行讨论, 致力于补充这个方向的实践积累。

1 性能瓶颈分析

流媒体服务是一种资源消耗集中的服务, 流媒体服务器性能调优通常会碰到多种资源使用瓶颈, 性能瓶颈的分析是性能调优的基础, 为性能调优提供方向, 并为调优策略的有效性提供数据支持。

流媒体服务器一般采用Linux系统, 而Linux提供了丰富的性能监控计数器, 基于这些计数器收集到的数据, 可以分析和定位服务器性能瓶颈, 本章节将重点从CPU、内存、磁盘、网络等角度深入分析各种瓶颈出现的表征。

1.1 CPU

常用CPU监控命令是top[2]和mpstat[2], top启动后可以在交互区输入“1”来查看多CPU服务器的各个CPU的负载详情, 而mpstat直接查看各个CPU的资源使用情况。CPU占用率信息基本样式如下:Cpu0:0.0%us, 0.2%sy, 0.0%ni, 98.3%id, 1.4%wa, 0.0%hi, 0.0%si, 0.0%st, 该部分数据基于Linux的/proc/stat文件, 更新单位是ticks, ticks就是系统时钟中断的时间间隔, ticks和内核中的HZ值有关, 在内核编译时可配置, Cent OS 6.4, HZ=1 000, ticks=1/HZ=1 ms。Top/mpstat看到的CPU, 其中:%us= (User time+Nice time) ×100%/CPU时间, %sy= (System time+Hard Irq time+software IRQ time) /CPU时间[3]。

监控数据时, 首先看%id, 它表征了空闲CPU时间比例。若%id接近0, 表示CPU即将耗尽, 在此基础上可以继续分析各个类型的CPU比例是否存在异常以及是否还有优化空间, 比较重要的有%us, %sy, %wa, %si四个, 分别代表用户、系统、IO、软中断的CPU占用情况;若%id超过10%, 表示CPU有较多空闲, 基本可以判定CPU不构成瓶颈。

对于多核CPU而言, 需要观察每个CPU的情况, 任意一个CPU耗尽都会构成性能瓶颈, 另外CPU 0很关键, 由它来负责多个CPU间的调度, 若CPU 0比较高, 则会影响多核的调度, 从而降低整体CPU性能, 通常而言, 应用程序尽量避免对CPU 0的占用。

1.2 磁盘

磁盘监控使用iostat/iotop[2]等命令, iostat可以看到每个磁盘的使用情况, iotop可以看到IO消耗从高到低的列表。Iostat看到的基本参数包括:rrqm/s, wrqm/s, r/s, w/s, rk B/s, wk B/s, avgrq-sz, avgqu-sz, await, svctm, %util, 其中rrqm/s和wrqm/s表示单位时间内的读写IO请求, avgrq-sz表征了平均每次IO请求的块大小, avgqu-sz表征了单位时间内的IO队列长度, await代表平均每次IO请求的等待时间, svctm表示了平均每次IO请求的服务时间, %util则表示磁盘使用率。

首先观察%util值, 若%util远低于100%, 则表示在统计时间内磁盘负载比较低, 不构成性能瓶颈, 这时候可以观察一下其他参数是否有异常, 比如svctm, 有时候即使是轻负载, 若磁盘老化或异常, 也会使服务时间过高。

若%util接近或达到100%, 需要继续观察其他属性, 以定位资源耗尽的原因, 若rrqm/s+wrqm/s很大, 代表收到的IO请求频繁, 可以考虑通过减少请求频率来优化, 这种情况下avgqu-sz和await应该也都比较大;若svctm比较大, 则表示磁盘的服务时间较长, 可能是磁盘老化故障, 也有可能是请求数据过多 (avgrq-sz比较大) ;avgrq-sz和吞吐成正比, 和响应时间成反比, 应用层调整每次请求的文件块大小, 可以影响到这个值的大小, 同时影响到吞吐和响应时间。

机械磁盘的性能由寻址时间、旋转时间和读写时间三部分决定, 磁盘内外磁道的寻址时间有明显差别, 而对于数据密集性的多媒体服务器而言, 为了充分利用硬件, 存储比例通常达到硬盘容量的70%以上, 因此性能测试及调优时需要同时考虑到内外磁道的性能区别。

1.3 内存

内存监控可以使用free, top和vmstat命令[2], 其中swap代表磁盘上交换分区的使用情况, 一旦产生了swap, 若非必要或机器重启, swap不会清零, 因此内存瓶颈或耗尽的表征不是swap不为0, 而是swap不断增大。若从vmstat监控来看, si/so表示每秒从磁盘读入虚拟内存的大小或从虚拟内存写入磁盘的大小, 如果两个值在一段时间内都大于0, 表示物理内存不够用或者内存泄露了, 需要频繁地使用到swap空间。

1.4 网络

使用sar可以查看网卡使用情况, 根据网卡的使用率可以判定网卡硬件瓶颈。对于传输层瓶颈, 可以使用netstat[2]和tcpdump[2]来看, 比如查看netstat Recv-Q和Send-Q, 若发送队列和接收队列比较大, 且持续增加, 代表了应用层网络发送或接收出现了阻塞, 而使用tcpdump可以观察到TCP传输层的问题, 若出现了ZeroWindow, 表示发送或接收缓存区已满, 导致TCP流控启动。

1.5 文件句柄

使用lsof[2]和ulimit[2]命令, 查看每个进程开启的文件句柄和系统的文件打开限制数, 若进程开启文件句柄大于配置的阈值, 则进程运行就会出错。

2 性能调优案例分析

2.1 系统配置

硬件采用超微4U Server, 配置如下:intel Xeon2.00 GHz×24, Disk:7 500转;软件流服务模块采用Python Twister框架, 数据库使用mysql, 文件系统使用类GFS[4]的分布是文件系统DFS, 操作系统使用Cent OS6.4版本, ext4虚拟文件系统。

2.2 调优策略

2.2.1 CPU调优

性能测试时出现过以下几种CPU的问题, 并给出了对应的解决方法:

1) 多核CPU使用不均衡

(1) 让出CPU 0, 尽量少使用CPU 0;

(2) 静态绑定不同进程或进程中的不同线程到不同的CPU上。

2) 部分CPU si/sys过高

(1) si过高为多个网卡的软中断分配不均衡, 为系统软中断调度缺陷, 静态绑定软中断可以解决;

(2) sys过高是系统调用太多引起, 使用strace命令, 跟踪查看系统调用情况, 找出使用较多并耗时较多的系统调用, 比如fopen/read/write/fseek等, 改进应用层设计, 减少系统调用。

2.2.2 磁盘调优

寻址时间比重在60%~70%之间, 顺序读写避免了这部分消耗, 因此磁盘的随机度性能远低于磁盘的顺序读性能。考虑到流媒体服务一般是100 Mbyte以上的视频文件, 具备顺序读的可能性, 若想提升磁盘吞吐, 必须考虑到尽量减少随机读比例。

磁盘调优实际就是结合应用场景, 找出一个适合的磁盘使用方法, 也就是在吞吐、时延、并发三个指标之间找一个均衡点。本案例采用两个策略来优化磁盘性能:1) 调大每次提交的读写块大小, 由原有的64 kbyte, 提高到256 kbyte;2) 加入预读机制, 预先读取1 Mbyte数据。实践结果表明, 这两种策略促使性能提升了20%左右。

2.2.3 网络调优

1) 网卡绑定模式

高性能的流媒体服务器硬件通常采用高性能的服务器配置, 4~12个千兆网卡, 或2~4个万兆网卡, 为提高网卡利用率, 需要采用系统支持的网卡bonding技术, bonding模式有多种, 各种模式的应用方向和性能有区别, 一般采用mode 0, mode 2和mode 6, mode 2具有IP亲缘性, 容易引起网卡负载失衡, mode 6在大压力情况下, 经常出现丢包问题, 实践证明mode 0最为稳定和高效, 缺陷需要在交换机上进行相应的配置。

2) 传输协议层

分布式文件系统DFS和流服务应用程序之间采用的也是基于TCP的网络传输, TCP使用滑动窗口机制实现流控, 测试时发现由于发送和接收速度不匹配, 导致TCP窗口经常变为0, 极大地影响了二者之间的传输效率。改进方法有两个: (1) 在二者之间进行适配, 这种方法实现比较困难, 且不利于在DFS层面实现预读; (2) 在二者之间添加一个适配层, 使用一个内存buffer做缓存, 这种方法实现容易, 效率较高。实际改进时使用了方法2, 实践证明, 缓存适配层的引入有效解决了zero-window的问题。

2.2.4 流服务层调优

该流媒体服务系统提供了支持多种终端 (PC/pad/phone/STB) Http Live Steaming[5]服务, 为增加服务的适配性, 减少文件系统开销, 在服务器端使用的是虚拟切片技术, 即磁盘存储的是完整的ts文件, 由应用程序在内存中完成切片。

由于HLS服务采用的是TCP短连接, 上下片段间无任何关联, 而每次请求ts片段 (片段长度默认是10 s) 服务器就需要去重新fopen文件, 读取完毕再fclose文件, 时间消耗和CPU消耗都比较大, 为了降低这种消耗, 本文引入了文件句柄池, 设计一张hash表在内存中缓存打开过的文件句柄, 根据最后访问时间和更新时间等信息定时更新缓存表数据, 保证较高的命中率。经过这种改进, HLS vod性能接近普通vod性能的80%。

2.2.5 其他

在性能测试时, 还遇到了两种情况:1) CPU虚高, %us消耗和实际的计算量不匹配, 分析应用程序的设计, 发现由轮询间隔太小引发, CPU空转严重, 增加轮询间隔或更改轮询机制, CPU使用降低了30%;2) 从性能计数器分析, 看不出明显的性能瓶颈, 但响应时间很大, 并发数无法维持, 播放出现卡顿, 经过分析是由并发调度中不恰当的互斥引起的。

3 结论

通过上述几个方向的调优, 流媒体服务器性能得到明显的提升, 使用码率为800 kbit/s的VBR H.264片源测试, 吞吐稳定在8 Gbit/s以上, 平均响应时间≪0.5 s, CPU使用高于90%, 磁盘使用率在70%左右, 基本达到了硬件极限。

分析中发现, 接下来可以考虑两个方向的优化:1) 继续降低CPU user time的使用, 对于流服务而言, 计算量比较小, CPU消耗仍然远高于理论值, 空耗和等待比较多, 仍然有较大优化空间;2) 考虑使用缓存技术, 对于热点节目降低磁盘压力, 提升内存利用率。

摘要：近年来, 随着流媒体业务的普及, 以及基于流媒体服务的硬件和软件平台的发展, 对流媒体服务器的性能调优提出了新的挑战。首先在概述了流媒体服务器发展背景、面临挑战的基础上, 提出性能调优的重要性;然后分析流媒体服务器常见的性能瓶颈表征;最后结合实际案例, 给出常用的性能调优方法和技巧。

关键词：流媒体,性能瓶颈,性能调优,性能数据监控,IO/CPU/内存密集

参考文献

[1]MOLYNEAUX L.The art of application performanced testing[M].3rd ed.[S.l.]:Wiley, 2011.

[2]Linuxmanpages[EB/OL].[2014-03-02].http://www.linuxmanpages.com/.

[3]Linux CPU占用率原理与精确度分析[EB/OL].[2014-03-02].http://ilinuxkernel.com.

[4]GHEMAWAT S, GOBIOFF H, LEUNG S.The google file system[EB/OL].[2014-03-02].http://pan.baidu.com/share/link?shareid=2544600225&uk=3256658338&fid=1071906213170227.

调优MapReduce工作负载 篇9

Map Reduce是处理大规模数据的一个相对年轻的框架, Map Reduce是一个编程模型、一个关联型运行时系统[1]。Hadoop是奠定在原始基础上的最流行的Map Reduce实现的开源框架之一[2], 并应用于大多数公司生产配置阶段的应用程序中。Iaa S云平台允许用户即时的配置集群, 用户仅仅需要为使用时间和所使用的资源付费, 这使得Hadoop工作负载运行更为容易。Hadoop有如下优点:较好的容错能力、本地数据调度、异质环境下的操作能力、错误环境下的执行能力、模块化、可制定的框架等。本文将证明配置参数设置对Map Reduce工作的性能影响。然后, 列举日常中出现的各种各样的优化和调整场景。

2 配置参数设置的影响

Hadoop由190多个配置参数, 而本文目前只考虑其中14种对工作性能的影响[3]。本文所使用的实验对象是Word Count (简称为WC) 、Tera Sort (简称为TS) 。WC处理由Hadoop’s Random Text Writer生成的30GB的数据, TSt处理由Hadoop’s Tera Gen生成的50GB的数据。图1 (a) 、图1 (b) 与图2 (a) 、图2 (a) 分别为测量WC与TS工作执行时间生成的反映面, 其中, 这些图中有3个参数产生了变化, 而其他的工作配置参数保持常量。

参数设置对Map Reduce工作性能的影响依赖于工作、数据、集群等特征:

2.1 工作特征对工作性能的影响:

图1 (a) 和图2 (a) 展示了mapred.reduce.tasks参数设置从不同程度影响了WC、TS。无论io.sort.record.percent怎样变, reduce任务数目的增加对Word Count的性能并没有影响, 却显著提高了TS的性能。WC工作由map控制, map中的计算包括数据文件的解析、组合函数的使用, 而reduce任务只简单合计了字数。

2.2 数据特征对工作性能的影响:

数据特征可以影响有着相同参数设置的、相同Map Reduce程序的工作运行时间。图2 (a) 包含了一个“谷 (valley) ”, 在该“谷”点, io.sort.record.percent设置为0.15。io.sort.record.percent表示map的顶峰规模的分值, 用于描述map输出的元数据存储。由map任务产生的每一个记录要求16字节的元数据及其系列化规模。对于io.sort.record.percent的任何值, 平均的map输出记录的规模将决定是否由于系列化缓存的耗尽或者元数据缓存的耗尽将数据溢出 (spill) 至硬盘。

2.3 集群特征对工作性能的影响:

当reduce任务T的总数量NT比reduce任务执行槽S的总数目NS低时, 所有的reduce任务都将并发运行。当NT≤NS, 改变reduce任务的数目将对工作性能有显著的影响, 假设reduce任务的执行时间与map任务的执行时间是可比的。当NT>NS时, reduce任务将在并行reduce波里运行。从图2 (a) 中可得, reduce任务数目增加, 性能也提升, 但是由于每个并行reduce波的有效并发程度的带宽的限制, 提升率却下降。

2.4 参数间的交互对工作性能的影响:

Hadoop中配置参数的子集显示了一个或多个参数间较强的性能交互。图1 (b) 显示了当io.sort.record.percent设置较低的值时, 改变io.sort.mb对工作性能并没有产生显著的影响;io.sort.record.percent设置较高的值时, 改变io.sort.mb对工作性能产生了很大的影响。图2 (b) 显示了io.sort.record.percent、io.sort.mb间的更强、更复杂的交互。io.sort.record.percent设置不同的值, io.sort.mb变化可能导致性能的变化形式也不同。

3 调整Map Reduce工作负载的用户案例

本文的调优问题是, 对于一个给定的分析工作量, 确定集群资源和Map Reduce工作级配置参数设置, 以满足其执行时间和成本上的要求。本节首先讨论一些出现调优问题的常见场景。

3.1 调整工作级配置参数设置

在Map Reduce框架中运行单个工作, 大量的配置参数必须由用户或系统管理员设置。Map Reduce工作或工作流的性能在反应时间或工作负载的完成时间上不能满足服务级要求。因此, 需要理解工作行为、诊断工作执行期间所用参数设置的瓶颈。

3.2 调整弹性工作负载的集群规模

假设Map Reduce工作在m1.large的10-EC2节点的Hadoop集群上花费了3个小时。控制集群的应用程序或用户可能想知道如果在集群上再增加5个m1.large节点, 工作执行时间将减少多少;用户也可能想知道在集群上再增加多少个m1.large节点运行时间能降至2小时。

3.3 工作负载从发展集群向生产集群过渡

与运行关键任务和时间敏感性工作负载的生产集群相比, 许多企业为程序开发维持了独立的 (可能多样的) 集群。弹性和现买现付特性简化了维持多样集群的任务。开发者首先会在开发集群上测试新的Map Reduce工作, 可能会使用生产集群中的数据中的少量有代表性的样本。在工作被调度至生产集群之前 (通常作为分析工作负载的一部分定期运行在新数据上) , 开发者需要识别Map Reduce工作级配置, 这个工作级配置将提供良好的工作性能。

3.4 多重目标下的集群配置

Iaa S云平台提供了一个集群中所使用节点类型的多种选择。随着这些节点上计算、存储、I/O资源的增加, 每个小时的使用费用也增加。图3 (a) 、图3 (b) 分别显示了运行在EC2上的Hadoop在不同集群配置下的Map Reduce工作负载执行时间、总费用。图3 (a) 和图3 (b) 中的集群使用EC2节点类型中的5种节点;每小时使用费用, 记为cost_ph。计算每个工作负载执行的相关总费用所使用的价格模型是:

这里, num_nodes是集群中的节点数目, exec_time是在大多数云计算平台上完成工作负载的执行时间 (向上舍入到最接近的小时) 。用户可能对工作负载有多种偏好和约束[4], 例如, 用户目标可能是最小化工作负载运行的成本费用, 以最大化忍耐工作负载执行时间为代价。从图3 (a) 、图3 (b) 可以看出, 用户想以执行时间小于45分钟为前提, 最小化成本。

3.5 及时调整工作负载以降低执行成本

公式1的成本模型被用于计算图3 (b) 的成本, 基于所使用的节点类型收取每小时的费用, 其中, 这些节点被称为EC2上的按需实例。Amazon EC2也提供了现场实例。现场实例的价格随时间变化, 通常依赖于云上资源的供求关系, 电价时空变化等其他因素也可以导致云资源使用成本的波动。

综上所述, 图4与图3 (a) 、图3 (b) 的工作负载是相同的, 图4描述了使用EC2现场实例类型的运行情况。在该案例中, 用于计算总成本的定价模式:

其中, cost_ph (i) 代表了每个集群中使用的节点类型第i个小时的费用。比较图3 (b) 和图4, 显而易见, 如果所使用的集群资源不同, 则相同负载的执行费用是不同的。

4 结束语

本文主要首先讲述了配置参数设置对Map Reduce工作性能的影响, 并对云上的Map Reduce做简要介绍, 最后以实际用户案例说明了调整Map Reduce工作负载的常见场景。下一步工作是构造合适的成本模型, 研究基于数据流系统的成本优化和自动调整技术, 期望解决基于成本的优化和自动调整间的差异。

摘要：大规模的数据密集型计算引起了研究界和工业界的广泛关注, Hadoop、MapReduce等的开源实现, 越来越多地应用于大数据分析。针对MapReduce工作负载的调优问题, 通过实验验证了参数配置对MapReduce工作性能的影响, 从5个方面介绍了调整MapReduce工作负载的常见调优场景。

关键词：大数据,MapReduce工作负载,参数配置,调优场景

参考文献

[1]DEAN J, GHEMAWAT S.MapReduce:A Flexible Data Processing Tool[J].Communications of the ACM, 2010, 53 (1) :72-77.

[2]YAO Y, TAI J Z, SHENG B, MI N F.Scheduling heterogeneous MapReduce jobs for efficiency improvement in enterprise cluster[C]//IFIP/IEEE International Symposium.Belgium:2013 IFIP/IEEE, 2013:872-875.

[3]HERODOTOU H, LIM H.Star sh:A Self-tuning System for Big Data Analytics[R].Durham:in Proc of the 5th Biennial Conf on Innovative Data Systems Research.2011.