有关系统性能调整.docx
《有关系统性能调整.docx》由会员分享,可在线阅读,更多相关《有关系统性能调整.docx(16页珍藏版)》请在冰豆网上搜索。
有关系统性能调整
有关系统性能调整
IBMpSeries系统监控和性能优化简介
科技高度发展的今天,计算机已经被广泛地使用在各行各业的各个领域中,不论是企业还是个人都在享受着计算机所带来的种种便利和好处,对于计算机的直接使用者和购买者来说所关注的不再是我是否能够得到功能足够强大的机器,而是如何充分利用现有的机器设备,或如何利用有限的资金购买最适合的机器为我提供服务.系统性能优化便成为每一个客户所关心的问题.本文就IBMpSeries在关键资源CPU,MEMORY和I/O等方面的性能优化作粗略分析.
在具体分析系统性能之前,首先希望明确本文仅就系统级性能优化进行分析,并不涉及应用级的性能优化分析.系统级优化是指在系统运行某特定应用服务功能程序时,针对该应用的特点和要求如何将服务器的系统资源尽可能均衡地,充分地利用.应用级优化关注的应用程序本身实现特定服务功能的效率,通过简洁的应用系统构架,合理的程序结构设计,良好的程序逻辑关系,一方面实现耗费最少的系统资源完成最多的应用服务功能,另一方面能够尽可能充分利用系统的所有可用资源.本文仅就IBMpSeries在某电信应用实例中的关键资源CPU,MEMORY和I/O等方面的系统级性能优化作粗略分析.
电信行业智能网业务的特点:
智能网业务主要围绕电信用户不同业务的计费资费不同,计费方式不同等完成实时的,准确的计费,为用户提供一系列的电信业务服务功能,它要求系统能够实时的联接后台数据库为有效用户提供及时的,24小时不间断的,稳定的服务.而且,由于绝大多数最终用户的消费习惯原因,同一套系统白天可能需要处理几倍于夜间的业务量,节假日的业务量有时达到平时的几倍甚至几十倍,这更要求系统的CPU处理能力,内存容量,I/O带宽和网络带宽等系统资源有足够的处理余量以及保证在悬殊的业务压力下系统的稳定运行.系统性能优化成为必须的课题.电信业务中系统性能指标往往以每秒钟所能够处理的呼叫联接个数(CAPS)作为系统性能的衡
在CPU资源尚未耗尽的情况下,有近1/3的CPU时间在等待磁盘I/O,可以肯定系统资源调度中I/O存在瓶颈;进而监控I/O使用情况:
#iostat–dhdisk3110
Disks:
%tm_actKbpstpsKb_readKb_wrtn
hdisk352.11086.9262.610252241967060
hdisk393.04704.01121.06364068
hdisk398.01236.0294.0400836
hdisk392.01556.0386.0780776
hdisk381.0760.0178.069664
hdisk389.01032.0252.0824208
hdisk392.01376.0329.0708668
hdisk399.01888.0457.02921596
hdisk398.01436.0356.0660776
hdisk394.01624.0403.0852772
hdisk399.02412.0589.07241688
可以发现hdisk3平均访问率非常高,几乎在90%以上,但从数据传输量来看其真正的数据量并不大,约为1500Kbps,而且读写均衡,说明运行的应用程序的对磁盘访问有小数据量频繁存取的特点(其实即为电信应用中话务呼叫的应用特点);这里可以肯定的是系统整体性能的瓶颈在于hdisk3的过度访问.更进一步分析,使用系统监控命令filemon或lvmstat可以获得以下信息:
#filemon–ofilemon.out;sleep30;trcstop
#vifilemon.out(部分截取)
util#rblk#wblkKB/svolumedescription
------------------------------------------------------------------------
1.00910801081121561.1/dev/workdbslv1raw
0.000407231.9/dev/logiclogdbslvraw
0.008438434.4/dev/tcom_filelv/tcom_file
0.0001200.9/dev/hd4/
0.0001441.1/dev/hd2/usr
0.000880.7/dev/loglv01jfslog
0.0002722.1/dev/tcomlv/tcom
0.000320.3/dev/hd8jfslog
0.0001040.8/dev/loglv00jfslog
0.00080.1/dev/hd3/tmp
MostActivePhysicalVolumes
------------------------------------------------------------------------
util#rblk#wblkKB/svolumedescription
------------------------------------------------------------------------
0.91910881166721628.2/dev/hdisk3SSALogicalDiskDrive
0.0003042.4/dev/hdisk0N/A
0.0003602.8/dev/hdisk4SSALogicalDiskDrive
hdisk3的过分繁忙是由于其中的用于放置数据库表的/dev/workdbslv1裸设备过度繁忙造成的,至此我们可以通过调整裸设备的放置策略和数据库配置参数获得更好的I/O性能:
1.建立workdbslv1时裸设备时使用如下命令调整:
#mklv-yworkdbslv1-traw-exdatavg128hdisk3hdisk4
hdisk3和hdisk4为属于同一个卷组的两个7133RAID逻辑盘。
2.适当调整Informix配置参数,如增加共享内存容量:
BUFFERS200000#Maximumnumberofsharedbuffers
以使数据库I/O读写有更大的内存命中率,从而减轻磁盘I/O的读写压力。
二.CPU性能调优简介
使用于IBMpSeries全线产品的IBM自行设计制造的POWER系列CPU处理器采用了多项业界领先的尖端技术,如铜芯片,绝缘硅技术,MCM设计,三级CACHE缓存技术等等,极大地提高了CPU的处理能力,是公认的性能最优功能最强大的处理器,其处理能力的优越性可以访问www.spec.org网站查询相关参数.但是,服务器即便配备了如此强大的CPU处理器,如果应用过程中未能合理调度CPU资源,它也可能成为系统性能瓶颈.系统性能优化中CPU的性能调优所要做的主要任务是解决如何合理调度CPU资源,使其在合适的时间使用在合适的地方.
案例1,曾有一个用户抱怨,他的应用长期受到困扰:
相同的应用处理同样的计费结算处理,4x500MHz/2GBmem的M80服务器的处理时间是一台1.8GHz/512MbmemPC机的近乎3倍!
而CPU资源有70%多的空闲,I/O并不繁忙,内存也不紧张。
原因分析:
客户和代理商工程师在监控CPU使用情况时仅仅使用了命令:
#sar1100
所得到的结果是CPU很闲但处理速度非常慢.但并没有监控每个CPU的使用情况,如果进一步使用命令:
#sar–PALL1100
即可发现整个应用处理过程中只有一个CPU在处理业务,%idle=0,其它三个CPU%idle=100!
显然,对于单进程单线程应用希望通过运行在多处理器的服务器上以获得更好的性能如同缘木求鱼.
案例2,在进行GSM智能网SCP业务呼叫测试过程中,在测试用例不变,业务流程相同,测试业务压力也相同的情况下,随着测试时间的推移,系统业务处理能力越来越差,呼损越来越大.
分析原因:
#sar15
00:
41:
44%usr%sys%wio%idle
00:
42:
14604035
00:
42:
44605035
00:
43:
14615133
00:
43:
44605035
00:
44:
14604035
Average605035
CPU使用情况并没有明显变化,还有35%的CPU空闲;再使用CPU系统监控工具tprof观察比较不同时间的CPU使用情况,发现CPU资源调度由主要处理应用进程逐渐变为主要处理数据库进程:
#tprof–kes–xsleep20
#vi__prof.all
ProcessPIDTIDTotalKernelUserSharedOther
=======================================
tcom_app558787854712525410691290
tcom_app459402438112267710211280
tcom_app59240522031191789801330
tcom_app32082310491167759591330
tcom_app58224345191139719321360
tcom_app69358651751121739161320
tcom_app51118485131113759071310
tcom_app68460739171043658581200
manager4105648161826320462440
wait10321033504504000
wait12901291480480000
wait516517447447000
wait774775440440000
tcom_appserver33608855911910720
smfagent2628614515107300
tprof366023866563300
oninit353962901340400
syncd95861036133000
swapper0322000
IBM.ERrmd141922477120020
IBM.AuditRMd46782633922000
oninit279903047711000
oninit462763699511000
oninit467864777111000
oninit299585785511000
oninit527226174311000
oninit297486660910100
=======================================
Total120032791812210900
ProcessFREQTotalKernelUserSharedOther
====================================
tcom_app89252568764210420
wait418711871000
manager1826320462440
tcom_appserver11910720
smfagent1107300
oninit7105500
tprof163300
syncd133000
swapper122000
IBM.ERrmd120020
IBM.AuditRMd122000
====================================
Total27120032791812210900
TotalSystemTicks:
12003(usedtocalculatefunctionlevelCPU)
可以猜测,系统处理能力的下降与CPU资源使用情况的变化有关.再使用ps进程监控命令分别观察应用进程和数据库进程的CPU使用情况:
#ps–el|greptcom_app
240801A732082410565874206c9bb120648-20:
49tcom_app
240801A73360841056160201ca4784656-0:
41tcom_appserver
240801A745940410566492206c91b120668-20:
46tcom_app
240801A751118410567195204ca93120632-21:
00tcom_app
240801A7558784105662912068a1a120644-21:
05tcom_app
240801A758224410565286204941120672-20:
43tcom_app
240801A7592404105671952050834120700-20:
36tcom_app
240801A768460410567174206c9fb120724-20:
30tcom_app
240801A7693584105667602064699120728-20:
22tcom_app
#ps–el|greponinit
40801A20337143539606020107e4964832a46a8c-0:
01oninit
40801A20353383539606020607d8954032a469cc-0:
02oninit
40801A203658035396060203474d82203006b684-0:
02oninit
40801A203113843539606020307cc943232a4690c-0:
02oninit
40801A203119823539606020307ac918832a4670c-0:
01oninit
40801A2031297635396060203080c1006432a46d0c-0:
02oninit
40801A2031344635396060204c793899632a4658c-0:
02oninit
40801A2031507835396060203c78f896832a4654c-0:
02oninit
40801A2031512235396060207c0932832a4684c-0:
02oninit
40801A203156283539606020707fc992032a46c0c-0:
01oninit
40801A203194023539606020407d0946832a4694c-0:
01oninit
40801A203230623539606020208081002832a46ccc-0:
02oninit
40801A2032460435396060204c773873232a460cc-0:
02oninit
通过以上数据可以看出,应用运行20分钟后,应用进程tcom_app的运行优先级下降到90左右,而oninit数据库的每个子进程以衡定的系统默认运行优先级60请求CPU时间,(数值越大,优先级越低).究其原因是由于应用程序编码过程中,数据库运行方式是以每个数据库联接都单独启动一个oninit子进程而应用服务进程从应用启动开始就以衡定个数的应用进程完成应用服务处理,而且使用动态分配优先级,根据AIX进程运行管理机制,对于任何长期大量耗费CPU资源的进程将进行降低运行优先级的“惩罚”,随着应用优先级的降低,应用进程申请不到足够的CPU资源,CPU利用率逐渐失衡,表现为系统处理能力下降.解决办法有三种:
1.应用程序中使用setpriority()函数设置其优先级别,使应用进程运行在某一固定运行优先级下运行而不受惩罚机制的约束;
2.修改/usr/samples/kernel/schedtune的参数–d和-r,降低CPU资源使用过程中对进程优先级的惩罚权重;
3.使用nice和renice命令修改进程的基准运行优先级和运行优先级浮动范围。
三.系统内存的监控调优简介
对于系统内存的监控调优的主要任务是分析系统配置的有限内存使用状况,系统中是否存在由于内存使用不当而影响系统整体性能的情况;另一方面,在系统内存不足时借助页交换空间(PAGINGSPACE)更有效地管理内存,寻找更合理的内存分配策略,从而避免影响关键应用程序的正常处理.
内存监控方法有以下几种:
#svmon–G-i13
sizeinusefreepinvirtual
memory104856549740855115757253462693
pgspace10485761710
workpersclntlpage
pin57253000
inuse4625803482800
sizeinusefreepinvirtual
memory104856549743055113557253462696
pgspace10485761710
workpersclntlpage
pin57253000
inuse4625833484700
sizeinusefreepinvirtual
memory104856549744655111957253462696
pgspace10485761710
workpersclntlpage
pin57253000
inuse4625833486300
实时监控系统内存和PAGINGSPACE的总体使用状况,也可以使用不同的命令参数分别针对进程(-P),用户(-U),命令(-C)等进行监控,统计参数的含义可以参阅相关技术资料,这里不再一一赘述.
最常用的内存监控工具是vmstat,它可以时实反馈当前内存使用状况,文件页交换情况,PAGINGSPACE的使用状况,内存刷新过程:
#vmstat16
kthrmemorypagefaultscpu
---------------------------------------------------------------
rbavmfrerepipofrsrcyinsycsussyidwa
31462597552477000000528183162420970
704626015524580000001536226664384747190
504626015524410000001553215823603803170
604626015524390000001547216983837737200
704626015524160000001541226674156757180
104626015524080000001547214953859738190
此例中系统空闲,内存足够.与内存和PAGINGSPACE有关的参数分别表示:
avm:
activevirtualmemory
fo:
filepage_outspersecond
pi:
pagespagedinfrompagingspace
po:
pagespagedouttopagingspace
fr:
freedmemorypages
sr:
scannedbypage_replacementalgorithm
如果进一步跟踪MEMORY&PAGINGSPACE的使用情况,还可以使用ps命令对运行着的每一个进程进行监控:
#psgv
PIDTTYSTATTIMEPGINSIZERSSLIMTSIZTRS%CPU%MEMCOMMAND
0-A1:
4371620372xx0203560.01.0swapper
1-A1:
075118561892xx26360.00.0/etc/init
516-A9167:
4801220368xx02035616.41.0wait
774-A9130:
0101220368xx02035616.41.0wait
其中
SIZE:
thevirtualsizeofthedatasectionofprocesses
TSS:
therealmemorysizeofprocesses
%MEM:
thepercentageofrealmemoryusedbyprocesses
分别标识各进程的内存使用状况.
通过以上系统内存储和交换页的监控,我们其实很少对它们进行直接调整优化,更多的是依据使用状况给予我们在应用程序中更有效利用和分配内存的正确指引.当然,我们也可以通过以上监控信息从系统上对内存使用策略进行一些优化:
#/usr/samples/kernel/vmtune
vmtune:
currentvalues:
-p-P-r-R-f-F-N-W
minpermmaxpermminpgaheadmaxpgaheadminfreemaxfreepd_npagesmaxrandwrt
19928279712828120128655360
-M-w-k-c-b-B-u-l-d