有关系统性能调整文档格式.docx
《有关系统性能调整文档格式.docx》由会员分享，可在线阅读，更多相关《有关系统性能调整文档格式.docx（15页珍藏版）》请在冰点文库上搜索。
对于磁盘I/O的性能我们可以使用以下系统监控工具来分析:
#sar15
01:
24:
21%usr%sys%wio%idle
514652821
25:
214652920
514753020
26:
214452922
514552822
Average4652921
在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
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
42:
14604035
44605035
43:
14615133
44:
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:
40801A203113843539606020307cc943232a4690c-0:
40801A203119823539606020307ac918832a4670c-0:
40801A2031297635396060203080c1006432a46d0c-0:
40801A2031344635396060204c793899632a4658c-0:
40801A2031507835396060203c78f896832a4654c-0:
40801A2031512235396060207c0932832a4684c-0:
40801A203156283539606020707fc992032a46c0c-0:
40801A203194023539606020407d0946832a4694c-0:
40801A203230623539606020208081002832a46ccc-0:
40801A2032460435396060204c773873232a460cc-0:
通过以上数据可以看出,应用运行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
memory104856549743055113557253462696
inuse4625833484700
memory104856549744655111957253462696
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
PIDTTYSTATTIMEPGINSIZERSSL
升级会员 