以性能视角聚焦AIX6.1到AIX7.2升级之路

字数 3784阅读 8866评论 6赞 18

【作者简介】
杨建旭
中国人民银行清算总中心高级技术经理
师从中国工程院院士陈纯教授，拥有授权发明专利10余项、SCI/EI索引及核心期刊论文20余篇，性能优化团队及工具开发团队负责人。
# 摘要
对于AIX的用户来说，AIX7.2并不是什么新闻，然而并不是所有用户都应用了较新的7.2版本，那么在从AIX6.1到AIX7.2的升级之路上，我们能够得到什么、应该关注什么、适时修改什么，本文将一一展开，同时，本文重点介绍了如何比较AIX不同版本的性能差异、分析的思路以及不同版本性能的优劣。

# 一、	升级原因
对于大多数信息系统的运维者、应用的开发者来说，并不太关心自己的AIX操作系统是什么版本，似乎升不升级并不是一件必须的事情。毕竟，当前的应用系统运行稳定，我为什么要花功夫升级呢？升级反而会引入版本不兼容的风险，并且，新版本似乎也没什么看得见的我必须要用的功能。
好吧，的确是事实。大多数用户升级AIX的原因只是厂商的EOS（End of Service，终止服务），也就是说，厂商以后不维护这个版本了，有什么bug也不修复了。对于一些用户来说，可以接受有bug待维护的新版本，但手里拿着不再维护的旧版本就心里发慌，于是，硬着头皮升吧。
# 二、	升级路径
操作系统升级不可能是在线升级，只能是替换的方式，因此，我们往往选择新上系统采用新版的AIX版本；对应稳定运行的老系统需要择机在替换新硬件的时候更换操作系统。
操作系统EOS的时候，往往伴随着一些系统软件（消息中间件MQ、交易中间件CICS）的EOS。升级操作系统不易，那么索性连系统软件一起升级得了。例如，MQ7升级到MQ8或MQ9，CICS7（TXSeries）升级到CICS8。所以，升级往往是一系列软件的整体升级。
升级操作系统时另一个需要决策是事情是：应用程序要不要重新编译。事实上，一些应用的确不需要重新编译，也可以在新的OS上面跑起来，但我们往往还是选择“原汤化原食”的做法去重新编译。而将“未重新编译的老应用跑在新OS上”作为一种对比的参照物，后面会详细介绍。
对于紧跟AIX步伐的客户，升级路径大概是这样的：6.X->7.1->7.2。当然也可以一步到位6.1->7.2。下文中，我将以6.1->7.1->7.2这个路径为例介绍升级操作系统的关注点以及我们获得了什么。
# 三、	升级关注重点
由于多数情况下的升级是软件系统没有变化下的被动升级，并没有用OS的什么新功能，或者说，压根儿就没打听过OS有什么新功能，那么，剩下的关注点在哪呢？
无非就是，1）功能上，更换的OS、重新编译或者没有重新编译的软件还能不能正常跑起来；2）性能上，会不会响应时间变长，或者资源利用率变高。3）稳定性，会不会跑着跑着挂了？新版本有没有bug？4）安全性，有没有引入新的安全漏洞，我要不要重新做漏洞扫描，新的安全机制会不会影响我的正常使用？事实上，在安全这个问题上，传统厂商走的离用户越来越远，因为安全和便利是相反的方向，我就因为家里的招行网银安全到登都登不上而放弃了招行。MQ也有这个问题，MQ8新的安全机制是个什么鬼？我连报文都发不了了。反观支付宝、微信等涉及到大众账户的产品，我们并没有觉得他们不好用，但他们在网络安全竞赛CTF（Capture The Flag，夺旗赛）中能拿到前两名，因为对待安全的思路不同（研究用户行为）、投入也不同。好了，回到话题。
下面一一介绍功能、性能和稳定性。
## (一)	能跑起来吗？
不做重新编译直接扔到新OS上，或者重新编译，都会有这个疑问，功能上有没有问题？能跑起来吗？
笔者接触的几个项目当中，还真有跑不起来的。
某系统A从AIX6.1升级到AIX7.1之后，某些交易不能正常处理，报错“数字签名(RAW)无效！”。
这些失败的交易对应的报文中带有二进制格式的加签字段，加签和核签均由对二进制字段计算出MD5码作为签名原文，而在AIX71平台上，对报文中二进制加签串核签的时候算出来的MD5码值不对。
原因是在AIX71平台编译时底层库编译选项中使用了-O（Optimize）优化选项（默认优化级别为2级，即-O=-O2），而新的编译器在使用此级别的优化时，优化处理过程与老版本不一致，导致底层库中计算MD5值的函数得出了错误的计算结果。因此，去掉-O选项后，谢天谢地，运行正常了。
这个例子中，我们可以看到，应用虽然跑起来，但并不是所有的功能细节都运行正常，因此，升级之后的全面测试是一个必选项。
## (二)	性能差异
如何对比不同版本的性能
在相同硬件环境、相同测试场景下（相同的吞吐量情况下）对比业务处理的响应时间和资源利用率（尤其是CPU利用率）的差异。
下面以两个系统为例，分别介绍AIX6.1->7.1和AIX7.1->7.2的升级前后的差异。
###1.	AIX6.1-7.1
还是以系统A举例
![5idfmx0ie1x](/home/attachment/201906/12/898849_156031066361327.png)
1)	对比！场景1-2
从表格中可以看到，AIX从6.1升级到7.1（应用程序进行了重新编译）后，场景2和场景1对比，CPU利用率飙升（52.55-38.24）/ 38.24%=37%。这是非常吃惊的结果。
2)	场景3的问题定位
AIX的新版本往往会从优化性能的角度来设计，出现性能恶化的比例并不大（虽然也存在）。因此我们首先想到的是应用程序的编译问题。在场景3中，我们将AIX6.1上的应用直接放在AIX7上运行，这时，CPU利用率已经和场景1一致了。这就说明，一定的应用编译在作怪。
那么我们会按照这个结论，把AIX6.1上的应用直接放在AIX7上万事大吉了吗？
不能！
3)	编译优化！场景4
既然是编译的问题，我们是不是有更优的编译结果呢？let’s try。
重新尝试在AIX71平台编译时采用编译选项-O（Optimize）做优化。但默认的选项会导致库函数中的某个计算函数得出了错误的计算结果。分析后发现，原因是库函数中使用的别名不符合ANSI规范，而AIX71上的编译器优化时默认代码均符合ANSI规范，导致优化器处理后结果与预期不一致。解决方案是使用-O2–qalias=noansi选项使编译器优化时允许不符合ANSI规范的别名引用。
编译优化后再测进行测试，场景4中CPU利用率仅有31.73%，比AIX6的场景足足节省了（31.73%-38.24%）/38.24%=17%的CPU。
另，一位专家给出建议，如果是硬件平台也升级了，可以考虑修改-qarch 和 –qtune选项，来指定硬件平台。不过以我们目前的经历，从来没有过编译绑定硬件平台，并且以我们现状（不知是不是普遍情况），也不可能去绑定。因为在生产环境同一个系统的服务器集群也会因为多年下来的改造而出现不同机型，生产环境的机型和测试环境的机型很可能也是不同的，甚至一些项目在开发编译的时候，并不知道这个软件未来会安装在哪个机型上面。因此，在应用发版的时候，不可能针对每个机型做一次发版，这虽然节省了一点点硬件资源的成本，但会增加人员、沟通、管理的成本。
编译的优化选项非常多，笔者并没有仔细研究过，事实上，也没有精力来做这件事，如果确定是编译的问题，可以请原厂的专家来做支持。
###2.	AIX7.1-7.2
某系统B
![6z63039vki5](/home/attachment/201906/12/898849_156031072538276.png)
可以看出，AIX7.2比7.1在相同场景下，不但CPU利用率有不小的降幅，并且响应时间也有不小的降幅。
## (三)	稳定性如何？
新的系统是原厂经过测试的，我们能默认它能稳定运行而不去测试压力和稳定性吗？
这个问题笔者认为主要看自身的测试能力。如果是较大的机构，测稳定性（或者说在一定压力下的稳定性）是必选项，毕竟这个世界上还不存在没有bug的软件。如果实在没条件测也就算了。
在笔者接触的AIX6.1->7.1的升级过程中，AIX倒是没出幺蛾子，但附带升级的软件CICS8->9却出现了跑一段时间就挂掉的bug，好在原厂分析和修复都比较及时，没有耽误我们的项目上线。
# 四、	总结
从上面的描述可以看出，升级一个操作系统版本，事实上，影响因素不仅仅是运行的操作系统本身。因为，中间件的版本可能也进行了同步的升级，应用也进行了重新编译，甚至物理机型也更新了等等多种干扰因素。对比两个操作系统版本的优劣实际上是非常困难的，或者说我们很难知道真相是什么。
然而，其中非常重要的一个因素需要我们关注 – 应用编译。在AIX6.1-7.1的升级过程中介绍到，应用在不同编译器的编译结果下，结果迥然不同，应用在相同编译器的不同编译选项下的结果也是迥然不同，而“编译”，往往并不在操作系统升级中被重视，大家往往觉得只要编译通过就OK了。

总结一下，只要使用得当，应用在AIX7.1的性能是不会低于AIX6.1的，AIX7.2的性能明显优于AIX7.1。如果编译得当，往往会得到超过预期的性能表现。

aix性能调优 aix系统升级 AIX Power服务器

著作权归作者所有

如果觉得我的文章对您有用，请点赞。您的支持将鼓励我继续创作！