“三方演义”与性能优化

最新推荐文章于 2021-10-19 01:10:31 发布

csdnw1018

最新推荐文章于 2021-10-19 01:10:31 发布

阅读量224

点赞数

文章标签：数据库运维测试

Normal 0 7.8 磅 0 2 false false false EN-US ZH-CN X-NONE 性能优化为什么这么难？

一个IT系统建设的过程，其实就是“三方演义”的过程。这里的三方，就是客户方、开发商和IBM原厂，通常是客户提需求，开发商负责应用设计和开发，IBM提供软硬件产品，系统完成开发后，由客户或者第三方公司运行维护。一个IT系统的好坏，取决于这三方能否紧密合作，能否发挥各自独特的优势，从而实现1+1+1>3的效果。

类似于IT系统建设，一个上规模的性能优化项目，也是“三方演义”的互动过程。我经历过一些烂尾项目，这种项目在启动的时候，大家坐在一起指点江山，高谈政治，拍脑袋做决定，当出现性能问题的时候非常浮躁，不能冷静客观的分析问题和解决问题，而是叫喊着用更高档的硬件，缺乏严谨、务实、执着和求真的精神，缺乏对性能优化项目最起码的敬畏感。

首先是客户方。钱是客户出的，客户是真正的甲方，所以客户总是最强势，客户领导经常在会议上发号施令，当遇到问题的时候把开发商骂得一塌糊涂：“看看你们写的垃圾代码，还想让我们购买更好的硬件？”或者骂原厂：“你们说过DB2提供的自动维护特性不需要DBA过多干预，但为啥根本不是那么回事呢？”骂归骂，出了问题其实客户也是有责任的，你为啥不弯下身段，真正参与到系统的设计、开发和维护的整个过程呢，这样即使出了问题，心里也有底了呀。但是，现实中又很难，因为这和客户内部的体制有关，通常在一个项目的不同阶段，各个部门就象“铁路警察，各管一段”，开发部门只管开发，运维部门只负责上线维护，运维部门和开发部门是各自为战，当出了问题后，相互踢皮球，协调起来非常困难。例如，金融业的客户，一般拥有自己专门的开发部门和运维部门，两个部门独立，不存在上下级隶属关系，遇到困难后很容易相互扯皮。至于电信业和政府，出了系统性问题更难协调：电信业的客户，通常只负责系统维护工作，应用开发通常由第三方的开发商负责；政府客户，只负责需求、系统规划和管理工作，开发和维护都是由第三方公司承担的。

接下来谈谈开发商。开发商是挨客户骂最多的了，但并不妨碍他们喜欢拍胸脯，啥都敢承诺，啥都敢做，毕竟有其独特优势。开发商有人力资源的优势，手中有大量的开发人员可供使用；开发商还有对业务理解的优势，毕竟开发商长期和行业客户在一起，积累了很多业务经验和知识；通常开发商还有关系的优势，毕竟从客户那拿项目，是要和客户关系融洽、有信誉才行。但是，开发商也有技术硬伤，那就是对系统软件，包括硬件、数据库、中间件等的使用水平还停留在安装配置的层面，缺乏对其内部机制的了解，所以在架构规划、数据库优化、高可用性测试、可扩展性测试等方面技术上做不到甚至没有这方面的意识，更不可能实施了。

最后谈谈原厂。原厂的人员也会挨骂，也会被开发商拿来当挡箭牌，这不新鲜。原厂有自己的核心优势，那就是对自身产品的深入理解，以及跨金融、电信、政府等各行业应用所积累的实施优势，这必将在架构规划，数据库优化、扩展性测试等需要技术深度和经验的领域发挥重要作用，也可以为客户和开发人员在设计、开发和运维等工作上提供至为重要的技术支持。但是，原厂也有做的不够好的地方，其实也是体制上的原因，那就是以围绕产品的技术支持为主，如果在推动最新的技术和产品给客户的同时能愿意多倾听客户的真正需求，如果能积极主动参与到项目规划、设计、开发、测试和运维的整个阶段，那将对IT系统质量的提升发挥重要作用。

在这样一个“三方演义”的架构下，要想完成性能优化工作有时候超越了技术本身，它更多的需要设计开发人员和运维人员的紧密配合。当我发现SQL语句的问题，需要开发人员支持和配合的时候，却被告知项目已经被开发商交付给客户了，没有办法找到开发人员了。有时候我即使找到了开发人员，他们却对SQL语句的最终运行环境一点都不关注，他们只是强调SQL语句是业务逻辑的需要。于是，我不得不找运维人员寻求支持，但是运维人员让我更吃惊，他们只关注主机、操作系统和数据库本身，对上层应用缺乏了解，也不关注上层SQL语句是怎么写的。

这可能是国内IT系统建设的一个缩影吧，所以在此我仅提出一条呼吁性质的建议：在客户的推动下，设计开发人员和运维人员定期举行技术交流，多交流硬件、数据库、中间件以及应用开发中遇到的性能痛点，拿出一套行之有效的办法在当前项目中试点并在其他项目中加以推广。

某银行性能优化的真实案例

2012年12月15日是星期六，那天早上8点钟，本人衣冠楚楚，匆匆出门，打算去参加一个老同学的婚礼。刚上出租车，就接到了公司销售的电话，说是国内某银行客户的DB2数据库上线试运行后出现了非常严重的性能问题，希望我赶赴浙江宁波现场做一下性能调优工作。前几年如果周末接到这种电话，我内心肯定会抱怨一番的，周末了都不让人好好休息，不过经历的多了也就适应了，也慢慢练就了乱云飞渡仍从容的气度。老同学的婚礼该参加还是继续参加，该喝酒还是继续喝酒，该定去宁波的机票还是继续定。

我是12月16日晚上抵达宁波香格里拉酒店的，到了后和客户领导郑总约了第二天也就是12月17日早上9点在现场召开会议。

第二天也就是星期一上午8点50分，我刚到了客户会议室门口，就听见一个人在满腔怒火的训斥，从声音可以听出来这个训人者就是昨天和我通电话的客户领导郑总。等我刚踏入会议室，发现场面非常隆重，里面坐了很多人，除了客户领导外，还有客户方DBA小李、第三方顾问公司的架构师老张、以及来自几家应用开发商的大队开发人员，可谓各路英豪齐聚一堂啊。作为原厂的唯一代表，本人孤独的坐在了角落里。会议几乎在争吵中度过的，下面是我对大家发言概要的整理。

郑总发言：“这个项目是银监会重点督导的项目，具有重要的政治意义，如果这个项目在宁波试点成功了，那么可以推广到华东甚至是全国。但是，开发商在开发阶段就屡次拖延工期，这次上线试运行后，又暴露了严重的性能问题，业务人员没法使用，对此我是非常不满意的，需要拿出彻底的整改办法来。”

开发商代表发言：“首先，接受领导的批判。但是，这个项目的业务需求改动了好几次，另外我们的队伍对Weblogic应用服务器和Oracle数据库非常熟悉，但是对DB2数据库开发和优化的技术积累非常薄弱啊，没有原厂的支持是不行的。”

郑总发言：“原厂的工程师已经到了，王工，你终于出山了，昨天从北京过来的吧，你可是DB2领域的领军人物了，解决这个性能问题可以说是举手之劳啊。。。”

我发言：“多谢大家的信任，初来乍到，我先了解一下情况再发表建议吧。”

客户方DBA小李发言（发言非常激烈）：“这个应用上线试运行后，正常情况下还好，但是一旦达到了1000并发用户时，系统的平均响应时间从1s一下急剧增加到4s左右，业务人员根本就没法用，要知道现在的硬件可是16内核的双机Power 740了！”

开发商代表接着发言（已经快哭了）：“现在双机Power 740配置太低了，难以满足性能需要，请按业务最高峰值配置硬件资源，使用最高档Power 780，另外存储设备也要升级，用IBM V7000！”

郑总发言：“这算什么回事？不是国庆节前后刚从x3850升级到Power 740啊，当时你们可是告诉我，Power 740肯定够用了，现在又要到Power 780，你们真好意思说出口！”

开发商代表小声说：“这个不会是DB2的Bug导致的吧。。。”

第三方顾问公司的架构师老张发言：“现在是双机Power 740，一台运行Weblogic应用服务器，一台运行DB2，使用HACMP来实现HA，当出现故障时，一台机器接管另外一台。现在DB2有新的技术了，可以用DB2 pureScale试试，如果还不行的话，可以考虑DB2一体机方案pureData，应用跑上去肯定快几倍！”

我寻思着，首先感谢这个架构师对IBM新技术新产品的信任，不过他也有点太着急了，目前是响应时间慢的问题，不是事务吞吐量遇到瓶颈的问题，在没有真正分析客户的性能瓶颈之前，这样去硬着推销DB2 pureScale或者pureData一体机，不仅不会给客户留下好感，有时候反而让客户对这些新技术或者新产品产生强烈的逆反心理。

会开到这个份上，其实已经陷入了僵局，我坐在角落里，大脑里反复出现郑总的话，经验告诉我，当客户遇到危难猛夸我的时候，其实已经把我推到了风口上了，因为终于有了可以堵枪眼的人了。当然，我也在考虑解决办法，内心也发出这样的感慨：相当一部分客户和开发商，什么都敢用，但是都用的不够专业，不够精细，这样一旦出现性能问题时，他们就只能高谈政治意义，随后习惯性的拍脑袋做决定，很难冷静客观的分析问题和解决问题。

快到中午了，郑总下午还有其他日常安排，开发商提出的用最高档Power 780的建议即将被一锤定音的时候，我赶紧发言，把我想说的用最快的速度说了出去：首先，我认为这个系统目前不应使用Power 780和IBM V7000存储，那是一种对资源的浪费，Power 740跑这样的负载绰绰有余；其次，我认为DB2还有优化空间，我有办法调整一些参数让DB2把硬件的能力发挥出来；最后，也是最重要的是，应用软件还有很大优化空间，至少在1000并发用户的情况下，响应速度急剧变慢，就和应用有关。

我说出上面的话后，整个会议室突然宁静了下来，开发商的人员面面相觑，客户领导这时反而笑了，笑的我有点发毛，他和蔼的问我：“王工，你有几成把握？这个项目可是非常紧急的，不能意气用事啊”，我内心其实也虚不过还是表面非常镇定的回答：“立足于现有的硬件环境，请给我5天时间吧，当我优化数据库和改造应用的时候，请DBA和开发人员配合我，谢谢！”

可能是外来的和尚会念经吧，另外我估计郑总以前就被那些劝他升级高档硬件Power 780的人吓怕了。非常出人意料，喜欢张嘴骂人的郑总竟然采纳了我的建议，也对我提出的让DBA和开发人员配合这样的要求全部满足。不过，最后他走出会议室的时候，丢下了一句狠话给我：“我现在骂人都骂累了，如果没有搞定，就走人吧。”

星期一：应用自下而上方法学，制定优化计划

立下了军令状，优化工作也就正式开始了。

下午的时候，我和小李以及来自开发商的几个开发人员在会议室进行了深入讨论，确定优化方法和实施计划。开发人员刚要开始给我详细介绍应用逻辑的时候，我立刻拒绝了，现在没有时间听这个。

其实，他们都想知道我葫芦里卖的什么药，想看看我有什么办法解决这个燃眉之急。我内心其实也是有点忐忑的，不过还是先给他们上了一课：“性能优化的方法有两种：自上而下方法学和自下而上方法学。自上而下的思路是早发现早解决，越到后面发现，优化的成本就越高，所以它是贯穿设计、开发和维护的所有阶段的，不过目前已经处于试运行阶段，自上而下显然是不可行了，所以只能采用自下而上方法学。”

我看他们似懂非懂，满脸迷茫的样子，随后接着解释自下而上方法学：“它是一种应急的办法，分别从硬件和应用入手，硬件上通过合理配置让DB2发挥硬件最大能力，这个不难，我用一天时间就能解决好。比较费劲的是应用优化，第一，我没有时间了解应用逻辑的细节，当务之急是需要花时间把最影响性能的模块找出来，再从这个模块里面找出前10大执行时间最长、执行次数最多的SQL语句，分析它们的访问计划，随后运用索引、表连接、分区等技术有效解决它们；第二，在开发应用的时候，开发人员对DB2的锁机制估计考虑的不周，上午小李提到的有1000并发用户时，系统响应时间急剧增加，这个很可能和锁有关，但本质上牵涉到应用代码。”

于是，大家一起制定了优化计划：星期二，调整参数，发挥硬件的处理能力；星期三，优化执行时间最长、执行次数最多的SQL语句；星期四和星期五，从应用角度解决锁问题。

星期二：调整参数，发挥硬件处理能力

我和小李来到了客户机房，一进到机房，让我大吃一惊。作为一名常年在客户现场服务的DB2工程师，我去过北上广很多大客户的机房，包括最大电信运营商的和最大银行的，这个客户在宁波，我原以为硬件投入上比不上北上广那些客户，但是没想到进去后，全是清一色的IBM服务器、HP服务器，还有EMC存储服务器，足有100多台。我忍不住一声叹息，都这么多硬件了，还想忽悠客户继续升级硬件，这也太浮躁了。

言归正传，考虑到业务系统的性能不仅仅由数据库决定，它涉及存储、主机、DB2数据库和Weblogic应用服务器，所以，需要对这些内容都要进行性能监控。

首先监控了Weblogic应用服务器的运行情况。主机的CPU和内存利用率一切正常，这个也是开发商的强项，他们对Weblogic非常熟悉，所以没有问题也是意料之中的事。

其次是存储规划。这块是小李搭建的，一共16块盘，每块盘300GB左右，划分为4个RAID组，每个RAID组是3D+1P，其中两个RAID组存放数据，一个RAID组存放索引，最后一个RAID组存放事务日志，这是一种教科书式的规划。我通过SSH命令登录到DB2服务器上，使用dd命令对每个RAID组的I/O吞吐能力进行了测速，可以达到200 M/s以上，暂时没有调整的必要。

dd if=/dev/zero f=/data1/test.file bs=8192 count=5000000

5000000+0 records in

5000000+0 records out

40960000000 bytes (41 GB) copied, 179.411 seconds, 228 MB/s

接着是CPU利用率。在1000并发用户的情况下，拥有16个内核的Power 740的CPU利用率也就是20%左右，显然是足够了。

最后是监控内存。使用get snapshot命令抓取了数据库快照和应用快照，发现缓冲池的命中率竟然只有60%，而且有大量的排序溢出和编目缓存溢出。我仔细检查了一下，发现服务器总的物理内存为64GB，平时可用内存大约48GB左右，但是发现DB2仅仅申请了2G内存，用于缓冲池、排序堆、包缓存、编目缓存、锁列表等！把这么多内存空余下来想干啥？这是最大的浪费啊，而且缓冲池命中率这么低。想想也觉得这没有什么奇怪的，很多DBA只知道DB2提供的STMM内存自调优，但并不了解STMM对并发访问量非常大的交易系统的自调整有一定的滞后，而且它本身也有一定的开销。

凭借我的技术和经验，我对下面的参数进行了手工调整。其实真正调整的就是下面几条语句，但就是这几条语句，客户、开发商和第三方顾问公司要求我写书面的调整建议书，随后反复评估了整个下午，先在测试环境验证，最后我和小李在晚上负载低的时候进行了正式实施。

调整缓冲池大小，将DataBuf设置为102400个页面，由于页面大小为16K,所以总大小为16GB，IndexBuf设置为512000，即8GB，再次监控，缓冲池命中率达到了99%！

--pagesize为16K

ALTER BUFFERPOOL DataBuf IMMEDIATE size 1024000

ALTER BUFFERPOOL IndexBuf IMMEDIATE size 512000

增加sortheap大小直到不出现排序溢出为止，最终调整为819200。

update dbm cfg using SHEAPTHRES 0

update db cfg using sheapthres_shr 1638400

update db cfg using sortheap 819200

同样的办法，增大CATALOGCACHE_SZ直到编目缓存不出现溢出为止，最终调整为102400。

update db cfg using CATALOGCACHE_SZ 102400

同样的办法，增大PCKCACHESZ直到包缓存不出现溢出为止，最终调整为102400。

update db cfg using PCKCACHESZ 102400

星期三：优化前10大执行时间最长、执行次数最多的SQL语句

这一天是我过的最开心的一天，也是最顺利的一天。早上刚到机房，小李就把昨晚的对比结果发出来了：经过参数调整后，在1000并发用户的情况下，系统的响应时间从4s减少到了2s。

接下来按照计划开始了优化SQL语句。本来以为能抓住什么能装满好几页的SQL语句，假如我自己解决不了的话，可以请教加拿大多伦多实验室的SQL专家，但没想到我从snapdyn_sql管理视图里面抓出的前10大执行时间最长的SQL语句竟然都非常简单，但是执行次数非常多，达到了上亿次！

select TOTAL_EXEC_TIME, NUM_EXECUTIONS,STMT_TEXT from sysibmadm.snapdyn_sql order by TOTAL_EXEC_TIME desc fetch first 10 rows only

NUM_EXECUTIONS TOTAL_EXEC_TIME STMT_TEXT

3292321 293118181

SELECT ORDERID, ORDERTIME FROM BANK.ORDER WHERE ORDERNumber = ? AND ORDERTIME > ? AND ORDERTIME <= ? ORDER BY ORDERTIME DESC

... ... ...

首先来看第1条执行时间最长的SQL语句。这个SQL语句很简单，就是对表ORDER上的一个动态查询，ORDER这个表有3亿多条记录，它竟然执行了3292321秒，执行了293118181次！

解决办法是什么？其实很简单，为这条语句创建如下索引，这样不用再对ORDER表进行表扫描，可以通过索引扫描取得结果：

CREATE INDEX "BANK"."IQUERY" ON "BANK"." ORDER"

("ORDERNumber" ASC,

"ORDERTIME" ASC)

MINPCTUSED 10

ALLOW REVERSE SCANS

创建完毕后，运行runstats命令，重新收集统计信息，这样优化器在生成访问计划的时候就可以用上索引了。

其他9条执行时间最长的SQL语句，也是通过索引技术进行了优化。随后，我整理了报告发给了客户、开发商和第三方顾问公司供他们评估使用。很快，他们就做了答复，同意先在测试环境验证。完成验证后，已经夜深人静了，最后我喝着咖啡指导小李在生产库上进行了成功实施。

星期四：解决锁问题

早上来的时候，路上堵车，晚到了20分钟。当我刚到机房门口就听见郑总在用非常洪亮的声音给小李和开发商的开发人员讲话。他刚看到我就说：“王工，这几天工作成果很显著嘛，听小李说，现在平均响应时间已经优化到1s左右了，看样子大功告成了，晚上请你吃宁波菜！”

看样子郑总的心情不错，但是，我知道还有优化空间，因为星期二调整参数的时候发现了大量的锁等待。凭借我的经验，锁问题的产生通常是由于表的不合理设计或者事务对表的不合理访问导致的，这才是影响并发的关键所在。我告诉郑总，革命尚未成功，宜将余勇追穷寇，我再加把劲，看看能否再提升一下。

于是，在小李的配合下，我多次使用db2pd工具分析锁，发现在高并发的情况下，应用会千万次的执行同一事务逻辑，即查询热表SALESDATA中的某一行，随后再修改这个热表中的同样的行，这样当多个事务争抢同一行时，就会出现大量的锁等待。

通过抓取应用快照，发现这些同一事务的业务逻辑也不复杂，就是两条SQL语句，都是对表SALESDATA操作的，这个表有8000万左右的记录数。

--开始事务

业务逻辑代码...

--对表SALESDATA进行查询

SELECT ARRIVALATTENDED, ARRIVALFIRCODE, ARRIVALHOLIDAYSURCHARGE, NIGHTARRIVAL,

VICINITYAPPROACHCOUNTVFR, VICINITYDEPARTURECOUNTVFR, WORKSTATIONIDENTIFIER FROM BANK.SALESDATA WHERE FLIGHTIDENTIFIER = ? AND RECORDTYPE = ?

业务逻辑代码...

--对表SALESDATA进行更新

UPDATE BANK.SALESDATA SET ARRIVALATTENDED = ?, ARRIVALFIRCODE = ?, ARRIVALHOLIDAYSURCHARGE = ?, NIGHTARRIVAL = ?, VICINITYAPPROACHCOUNTVFR = ?, VICINITYDEPARTURECOUNTVFR = ?, WORKSTATIONIDENTIFIER = ? WHERE FLIGHTIDENTIFIER = ? AND RECORDTYPE = ?

--结束事务

遇到这种情况，只能和开发人员沟通一下了。开发人员告诉我，这是业务逻辑的要求，没有办法修改代码的，所以他们建议调整一下锁有关的参数而不是修改代码。我知道这么做，只是治标不治本，不过调整也能取得一定的效果，也就答应了。

最终将LOCKTIMEOUT从90调整为30，这里的单位是秒，90秒的时间太长了，设置为30秒比较合理，这样锁等待超过30秒后，就会回滚事务并报锁超时，从而提升事务吞吐量。

update db cfg using LOCKTIMEOUT 30

将LOCKLIST调大为40960，MAXLOCK调大为60，这样为锁分配更多的内存资源。

update db cfg using LOCKLIST 40960

update db cfg using MAXLOCKS 60

这个事务的频繁执行，会写大量的日志到磁盘上，分别增大了日志缓冲区（LOGBUFSZ）、日志文件大小（LOGFILSIZ）、主日志文件个数（LOGPRIMARY）和辅助日志文件个数（LOGSECOND）。

update db cfg using LOGBUFSZ 10240;

update db cfg using LOGFILSIZ 102400;

update db cfg using LOGPRIMARY 50;

update db cfg using LOGSECOND 30;

晚上，郑总开车过来，带着我、小李和几个开发人员一起去了一家著名的宁波菜馆。由于1s的平均响应时间已经达到了，所以大家也比较放松，吃的不错，也喝了酒。我借着酒劲，告诉郑总，越到后面，调优的成本越高，但我还要再猛攻一下，看看能否达到0.9s左右，至少要把锁等待消灭一批才行。

星期五：应用改造

早上来到机房，小李告诉我，昨天对锁参数的调整效果不大，但是预定的目标已经达到了，这个时候停下来客郑总是可以接受的，不过我可不能这样就草率放弃的。

Oracle的DBA一般遇到问题，第一时间想到的是Metalink网站，对DB2来说就是信息中心了。我到DB2信息中心网站上检索了一下，原来这两条语句是这样加锁的，第一条SELECT语句根据where条件获取某一行上的NS锁，这条语句可以立即获得NS锁，不会出现锁等待；但是，第二条update语句会试图将该行上的NS锁升级为X锁，这个时候就有可能发生锁等待。

--开始事务

业务逻辑代码...

--对表SALESDATA进行查询

--这条select语句会根据where字句的条件获取指定行的NS锁

SELECT ARRIVALATTENDED, ARRIVALFIRCODE, ARRIVALHOLIDAYSURCHARGE, NIGHTARRIVAL,

VICINITYAPPROACHCOUNTVFR, VICINITYDEPARTURECOUNTVFR, WORKSTATIONIDENTIFIER FROM BANK.SALESDATA WHERE FLIGHTIDENTIFIER = ? AND RECORDTYPE = ?

业务逻辑代码...

--对表SALESDATA进行更新

--这条update语句会将该行上的NS锁试图升级为X锁

--结束事务

那么有什么变通的办法呢？根据DB2信息中心的提示，我做了下面的改动，第一条SELECT语句后面加入“with RS USE AND KEEP EXCLUSIVE LOCKS”子句，这样可以直接获取指定行上的X锁，当然这个时候也会出现一定数量的锁等待；等到update语句执行的时候，无需从NS锁到X锁的转换了，也就不会再出现锁等待了。

--开始事务

业务逻辑代码...

--对表SALESDATA进行查询

--这条select语句会根据where字句的条件直接获取指定行的X锁

SELECT ARRIVALATTENDED, ARRIVALFIRCODE, ARRIVALHOLIDAYSURCHARGE, NIGHTARRIVAL,

VICINITYAPPROACHCOUNTVFR, VICINITYDEPARTURECOUNTVFR, WORKSTATIONIDENTIFIER FROM BANK.SALESDATA WHERE FLIGHTIDENTIFIER = ? AND RECORDTYPE = ? with RS USE AND KEEP EXCLUSIVE LOCKS

业务逻辑代码...

--对表SALESDATA进行更新

--该行上已经是X锁了，不需要从NS到X的锁转换了