香港IXXXXX项目交付总结

项目背景：IXXXXX是香港金融解决方案的领头企业，第一次选择国内厂商设备（云基础设施）作为其金融解决方案的基础平台。拟为其提供虚拟化平台，数据库（ORACLE平台）。

业务分层：虚拟化平台+虚拟机+金融服务软件，所有软件共享一个ORACLE数据库，我们提供两个计算结点供其部署ORACLE RAC双结点为提供可靠性。数据库使用的底层存储由虚拟化存储池提供，即只在DB计算结点上部署机头。

 

现状：设备环境已搭建，客户业务已经部署，客户自己的研发团队会不断更新版本，并在我们产品平台调测性能，客户测试发现性能非常低，向公司投拆。

 

投诉原因探究（后话）：前面维护人员接到客户IT人员的测试问题反馈，定位怀疑防火墙问题，结果客户负责防火墙的IT人员被激怒，和其ORACLE负责人（对我们产品一开始就有抵触，加上偏见和其部门墙）在DELL测试过防火墙的性能数据，远高于我们产品，最后向其IT主管投诉。

 

一、性能问题定位

1、第一阶段

现象：JMETER测试结果（客户模拟其核心业务提交订单） RAC双结点只有，50 orders/s。

定位思路：排查计算、存储、网络。

定位结果：CPU占用率很低，内存未占满，IO压力很小时延很小，网络负载很低，并且发现RAC两个节点CPU占用率不均。排查工具，发现工具线程池配置、连接串配置问题，修改连接串并配置本地hosts，重新测试DB结点负载均匀，单点性能达到1000 orders/s，双点500 orders/s。

 

进一步排查：CPU占用率达100%，CPU成为瓶颈，经确认，配置的CPU为2609（究其原因为前期SA和客户沟通问题），下一步更换更高级别CPU。

 

2、第二阶段

操作：更换CPU 2609->2680并开启超线程（经验）。

现象：单点性能达到2000 orders/s，双点1500 orders/s。

定位：CPU占用达70%+，但IO时延很低。

思路：从ORACLE层面定位，查看AWR报告看时间消耗在哪。

定位结果：发现时间消耗在mutex表，分析其存储过程和客户交流，客户在DB这一层设计一个约束，即同一用户同一时间只能分一个ID(sequence)，并且必须有序递增。因此客户通过select这张表加一个互拆锁。

优化措施：sequence加cache，sequence改为无序（让两个rac结点每次申请时不用交互，减少时延）。

 

3、第三阶段

操作：把sequence类型的字段加cache，分别验证20,2000,2w,200w。

现象：单点性能达到2000+，双点3000+。

定位：进一步测试发现客户每次测试都用truncate来清除表（水位直接置为0），导致每次新插入都重新分空间，时延较大。改用delete清除数据后，单点3000+，双点7000+.

分析：此时单双点CPU占用率均达到90%，IO时延较大，究其原因是ORACLE进程占满后，负责IO读写的机头进程抢不到CPU，后继建议绑核。

 

 

二、计划：结合客户验证测试、研发计划和产品诉求，制订满足双方要求的目标、计划。

三、协调资源：找对人，传递压力、重要性。