中国人民银行清算总中心性能测试团队负责人谈CPU资源虚拟化

概括

虚拟化技术可以帮助企业在保证正常生产运营的同时，提高现有资源的利用率，提高资源管理的便捷性，降低数据中心成本。 虚拟化解决方案逐渐成为各行业新建数据中心项目的首选解决方案。 然而，虚拟化技术在提高资源利用率的同时，也对系统性能产生影响。 本文介绍了金融行业常用的CPU资源虚拟化，并结合生产和测试情况对核心交易系统的虚拟化进行深入分析。 分层环境中的计算资源规划和性能调整。

1、计算资源虚拟化简介（一）简介

它是在基于IBM POWER处理器的硬件平台上提供的虚拟化解决方案。 它是IBM Power系统上一系列硬件和软件功能的统一品牌，包括逻辑分区（LPAR）、微分区、虚拟I/O服务器、共享处理器池、动态逻辑分区、Live等许多功能和技术。

(2)CPU机制介绍

在各类计算机物理资源虚拟化中，最受企业关注的是计算资源虚拟化，即CPU资源虚拟化。

IBM Power系统的CPU虚拟化通过IBM POWER对物理CPU进行抽象，并将其作为虚拟CPU显示给微分区操作系统。 操作系统只能看到虚拟CPU。

逻辑分区可以有独占CPU模式或共享CPU模式（即微分区）。 共享CPU模式下的逻辑分区从指定的CPU池中分配CPU资源。

(3)CPU虚拟化中的配置参数及其对性能的影响

虚拟CPU（CPU，简称VP）、并发多线程（SMT）、逻辑CPU（CPU）、标称计算能力（以下简称EC）、运行时物理CPU（CPU）、上限/无限制（/） ，折叠的 VP ( )，展开的 VP ( VPs)。

关于这些概念及其对性能影响的详细解释，请参见作者的另一篇文章：

性能指标：资源指标：CPU配置参数对性能的影响（参见公众号“性能测试与调优”或社区专栏）

2、虚拟化趋势下如何部署核心交易系统

基于资源共享的虚拟化的实施，必然会影响核心交易系统的性能。 核心交易系统往往对响应时间等性能指标有非常高的要求。 过去，他们不仅独占CPU，有时甚至要把进程绑定到物理CPU上。 那么，在虚拟化浪潮中，核心交易系统如何部署？

核心交易系统（或有响应时间要求的业务）可以通过以下方式部署：

1）不纳入资源池，仍然保持之前的独占资源方式。 概括地说，就是IT双模。 系统一部分是传统方法，另一部分是虚拟化方法。

2）不同的核心交易系统放置在不同的资源池中，放置在同一资源池中的其他系统都是计算资源消耗很少的系统； 这样可以避免关键业务被同一资源池中的其他高压业务压垮。

3）如果必须放入同一个资源池，则必须对CPU、内存、IO等资源设置保障计划。

例如，在AIX上，某个LPAR的CPU资源是有保证的（比如设置为10，相当于10个CPU核的容量，只要这个分区需要，就会提供10个核，并且是一个亲和力好的核心。但如果业务此时无法使用10个核心，那么10C的CPU资源将部分借给其他分区）。

另外，从内存的角度来看，例如，平台可以使用内存保护。 从存储层面来说，部分存储服务器可以对某个LUN的磁盘IO进行QoS。 从网络层面来说，网络IO的Qos也可以做。

但CPU资源保障并不能通过一项设置就完全解决。 本文重点探讨和分析CPU资源保障。

3、问题出现：使用虚拟化后交易系统性能明显下降（1）性能下降

某核心系统应用服务器采用虚拟化方式上线后，一线工作人员反映新服务器单项业务响应时间是原服务器（独占CPU的分区）的2倍）。 例如，某个高峰时段独占CPU的服务器的响应时间为80毫秒，而虚拟化资源池中的服务器响应时间为160毫秒。

（二）设备基本配置

主服务器EC设置为12，保证LPAR可以获得12C的物理CPU。 根据IBM的最佳实践手册，VP设置为EC的1.5倍（即18），这意味着活动服务器最多可以占用18C的物理CPU。 中央处理器。

(3)初步分析

无论是旧服务器还是新虚拟化服务器，高峰期CPU利用率都只有30%左右。 按理说，设置EC=12就可以完全支撑当前的吞吐量，应该不会有性能下降。 那么问题出在哪里呢？ 我们必须对虚拟化配置进行一一分析，并在实验室环境中进行分析。

4、CPU参数调优讨论（1）是否设置VP折叠

1、原理分析

为了让LPAR充分利用共享处理器池中未使用的处理器资源，LPAR需要有足够的VP来占用物理CPU资源，但当VP空闲时，它仍然会消耗一些系统资源。 下面的LPAR有一个称为“VP折叠”的功能。 开启VP折叠功能后，当系统负载较低时，AIX系统会自动休眠部分VP，以减少调度开销，提高系统性能。 当CPU折叠功能关闭时，VP不折叠。

当系统负载较大时，为了让LPAR抢占足够的物理CPU资源，VP不会被折叠，而“开启VP折叠功能”本身就需要条件判断，会消耗系统资源。 因此，从这个角度来看，当生产环境系统负载较重时，关闭“VP折叠功能”实际上有助于提高系统效率。

从另一个角度来看，关闭VP折叠功能后，LPAR拥有更多的VP，有利于运行时获得更多的物理CPU资源。 随着物理CPU数量的增加，真正意义上可以并发调度更多的进程。

2. 实际结果

在生产环境中关闭“VP折叠功能”后，达到了一定的调优效果。 新服务器与原服务器的响应时间比从2倍减少到1.25倍。 例如，在同一时间段内，新服务器的响应时间减少到1.25倍。 服务器平均响应时间为157毫秒，原服务器平均响应时间为126毫秒。

但新服务器的响应时间仍然比原服务器长，因此我们需要对CPU虚拟化配置组合进行进一步分析。

(2) VP与EC比例引起的性能差异

1、原理分析

在“VP折叠”一节中，我们提到在一定条件下，AIX系统可以休眠部分VP以提高系统性能。 这背后的原因不仅是因为空闲的VP需要消耗一些系统资源，而且还需要消耗一些系统资源。 从某个角度来看，减少VP会减少系统的调度开销。

操作系统调度进程在CPU上运行。 对于虚拟化平台，操作系统调度进程在VP上运行； 并负责调度VP（本质上是一个进程）在物理CPU上运行。 即虚拟化系统中存在两层进程调度机制，每一层调度都可能产生上下文切换开销。 减少VP会直接减少调度开销。 而且，进程调度机制会具有亲和性特征，即系统会倾向于将进程调度到最后使用的CPU上，以减少上下文切换。 虚拟化系统中的两层进程调度机制是互不兼容的。 进程经过两层调度后，很容易失去CPU亲和性特性。

2.降低VP的调优效果

为了验证上述推测，在实验室进行了如下实验： 使用压力测试工具向服务器批量发送消息（每秒60条消息）。 在相同EC值设置下，比较不同VP号的系统响应时间和中间消息。 软件MQ等待时间的差异。

从上面的分析可以看出，当VP与EC的比例越小时，上下文切换开销越小，性能越好； 当VP数量与物理CPU数量相等时，性能最佳。

当EC值能够保障业务压力时，VP与EC的比值本质上是展开的VP与运行时获得的物理CPU的比值。 该比率越小，性能越好。

但并不意味着展开VP与物理CPU的比例越小，在任何场景下性能就越好。 后续章节将介绍反例。

(3)关闭VP折叠与减少VP的比较

既然关闭VP折叠和减少VP都可以提高系统性能，我们来比较一下两者的效果。

在实验室中使用相同的测试场景来测试不同的参数组合。 以EC=5、VP=10、折叠打开（案例A2）为基准场景，测试“仅关闭折叠功能”和“仅降低VP”的效果。 不同之处。

运行时单位物理CPU利用率=EC利用率*EC/物理CPU数量

1、响应时间的差异

仅关闭折叠功能时（案例A4），响应时间减少6.2%；

当仅减少VP时（情况A1，VP从10减少到5），响应时间减少了24.2%。

在上述具体场景下，大幅降低VP值对于提升系统性能的效果更为明显。 也就是说，当VP过大时，对系统性能的影响更为严重。

2、CPU占用率差异

另一个需要注意的问题是，仅关闭折叠功能后（案例A4），虽然响应时间减少了，但运行时占用的物理CPU数量却增加了。 也就是说，通过占用物理CPU来减少响应时间。 以增加为代价，即运行时物理CPU增加后，可以真正意义上并发调度更多的消息主控（进程），从而减少响应时间。

仅减少VP后（案例A1，VP从10减少到5），不仅响应时间更短，而且运行时占用的物理CPU也略有减少。 进一步分析原因是由于运行时单位CPU利用率增加，即充分利用已经获得的物理CPU（增加用户态和系统态的CPU时间，减少空闲和等待CPU时间） ，而不是占用过多的物理CPU并使其闲置。

从尽量减少共享CPU池的占用的角度来看，减少VP也是一个更好的提高性能的方法。

(4) VP与EC的比值为最大值10，表示灾难性性能

根据以上分析，VP与EC的比值越大，性能可能越差。 可以设置的最大 VP 与 EC 比率为 10，因此让我们验证一下这种情况下的性能。

在实验室进行如下实验，使用性能测试工具每秒向服务器发起100个事务。

消息响应时间为242.48毫秒，消息在MQ队列中平均等待时间为1分钟，服务器每秒只能处理80条消息，消息堆积严重。

此时CPU池还有可用的CPU资源。 尽管数据包已累积，但 LPAR 并未分配更多物理 CPU 资源。 我们发现当时LPAR的物理CPU利用率是68.73%，并不算太高，所以我们可能没有在此基础上进一步增加物理CPU资源。

（5）EC过低时关闭CPU折叠，有提高运行时物理CPU、减少响应时间的效果。

与上述场景相比，VP折叠功能关闭，其他测试条件不变。

关闭VP折叠功能后，展开的VP数量始终保持在18个。一方面，随着展开的VP数量的增加，抢占物理CPU的能力增强；另一方面，随着展开的VP数量的增加，抢占物理CPU的能力也随之增强。 另一方面，系统似乎试图将展开的VP与物理CPU的比率维持在一定范围内。 实测结果中，物理CPU明显提升，LPAR CPU得到的物理CPU为8.2。 关闭VP折叠功能后，没有数据包堆积，响应时间相比“开启折叠功能”明显缩短（从242.48毫秒降至136.33毫秒）。 不过是否是最优效果，我们还是从VP数量的角度来继续分析。

(6) 当EC太低时，降低VP会导致性能变差。

根据上述场景的经验，减少VP可以提高性能。 那么基于目前EC=1.8的低配置，降低VP能不能提升性能呢？ 在关闭VP折叠的基础上，我们降低VP，并用相同的测试场景验证效果。

与案例B​​3/B4相比，VP从18下降到12，但响应时间从130ms增加到239ms。 原因是系统倾向于将展开的VP与物理CPU的比率维持在一定范围内。 减少VP后，动态获取的物理CPU也相应减少，导致CPU调度进程不足，响应时间延长。

可见，当EC值设置过小时，单纯减小VP会增加响应时间。 因此，“VP与EC的比例越小，响应时间越短”或者“展开VP与运行时物理CPU的比例越小，响应时间越短”并不是在任何场景下都成立的规则。

接下来，我们将进一步分析是什么原因导致上述规则不适用。

(7)运行时抢占的物理CPU性能较差

因为当EC值高时，降低VP对性能提升有很大帮助，而当EC值低时，结果恰恰相反。 然后我们比较其他参数相同、仅EC值不同时的系统性能。 。

两种场景每秒处理 100 条消息，运行时获得的物理 CPU 几乎相同（6.3 vs 6.1）。 当 EC 值为 1.8 时，不仅 CPU 利用率更高，而且响应时间也延长了一倍多（101.89 vs 239.39）。

在案例B5中，6.3个物理CPU中有5个由EC保证，而在案例B4中，6.1个物理CPU中只有1.8个由EC保证，这表明物理CPU通过动态抢占的性能效果。 远不如EC保证的CPU。 这就是打破“VP与EC的比值越小，响应时间越短”这一规律的根本原因。 因此，降低VP以提高性能的前提是提高EC。

动态抢占CPU资源有以下两个缺点：一是CPU亲和力比较差，借用的CPU可能不是来自同一个槽位，甚至不是同一个主机柜； 第二，物理源不固定，可能当前时间片被CPU1抢占，下一个时间片又被CPU2抢占，导致上下文切换的成本增加。

关于亲和力的概念、定量读数以及调整优化，可以参考作者的另外两篇文章：

性能指标：资源指标CPU亲和力调整与优化

介绍性能指标的资源指标的CPU亲和性原理以及如何量化读数

（参见公众号“性能测试与调优”或社区专栏）

(8) 高VP与高EC性能对比

从运行时物理CPU的角度来看，提高系统性能（主要指响应时间）有两种方式：

方案一：设置较高的VP并关闭VP折叠功能。 该方法通过增加运行时的物理CPU数量来实现性能提升。

选项 2：设置更高的 EC 值。 这种方法通过提高运行时物理 CPU 的质量来实现性能改进。

比较case B3（较高的VP）和case B5（较高的EC）可以看出，虽然case B3（较高的VP）获得了更多的物理CPU数量（7.3个），但响应时间仍然较长（130.63毫秒）； 情况B5（EC较高）获得的物理CPU较少（6.3），但运行时物理CPU的质量较高，响应时间较短（101.80毫秒）。

5. 总结

在EC值足够的前提下，减小展开VP应该可以缩短数据包的平均响应时间。 当服务器关闭VP折叠功能时，VP不折叠。 减少展开VP的方法是减少LPAR的VP值。

当EC值不足以应对业务高峰时，需要从资源池中动态抢占物理CPU。 即使VP参数和参数满足借用资源的条件，资源池中剩余的可用资源也是未知变量。 因此，如果EC太低，则无法保证LPAR能够动态获取足够的物理CPU。 一旦物理CPU资源不足，响应时间可能会延长。 甚至还存在数据包大量堆积的问题。 而且动态抢占的物理CPU的CPU亲和力较差，性能远不如EC保证的CPU。 因此，为了保证核心交易系统安全稳定运行，必须提高EC值以满足高峰运行要求。

如果EC不足时减小VP值，系统响应时间可能会变长。

从上面的讨论可以看出，系统容量规划不仅需要考虑日常业务量、峰值业务量和系统业务类型，还需要考虑虚拟化环境中的许多参数配置。

对于实时性要求较高的核心交易系统，在CPU资源充足的情况下，可以通过提高EC、降低VP、关闭VP折叠等设置来保证交易响应时间。

对于实时性要求不高、占用临时或周期性计算资源的分析系统，可以设置低EC、高VP，以节省资源，提高整个物理服务器的资源利用率。 同时，对重要系统进行容量规划测试也是保证系统稳定运行的一个思路。

（注意下面）

复活节彩蛋来啦~

计算资源通常是物理资源中最昂贵的资源。 因此，充分合理地利用现有计算资源，有效减少应用程序对系统资源的消耗是节省预算的重要组成部分。 然而，在虚拟化整合过程中，交易系统的性能很容易被所谓的资源池、资源整合等概念和趋势所损害。 如何从策略和执行层面有效保障交易系统的性能？

12月16日，我们将在线举办“虚拟化过程中核心交易系统性能维护”专题交流会。

本次研讨会旨在深入探讨CPU虚拟化原理，并利用原理解决虚拟化实践中遇到的各种性能问题。 事实上，每一个“最佳实践”背后都有一个支持其“最佳”的理由。 有时厂商的安装部署手册中给出了最佳实践安排，但往往这样的安排适用于一般场景，而不一定适用于客户的具体业务需求，而且如果不了解其背后的逻辑，很容易陷入误解。

着力解决问题：

1）核心交易系统是否需要与其他非核心系统保持IT双模？

2) 为什么核心交易系统迁移到虚拟化平台后响应时间变长？ 如何优化？

3）当基于资源池设置LPAR时，根据IBM的最佳实践手册，VP=ECx1.5，为什么我没有得到最佳的性能结果？

4）在生产备份环境或HA备份机中，标称计算能力（EC）可以设置小一些，虚拟CPU设置大一些吗？ 对性能有何影响？

5）长期使用虚拟化环境后，DLPAR等操作会导致CPU亲和力恶化，性能下降。 如何优化？

本文作者杨建旭将担任本次活动的演讲嘉宾

开始时间：12月16日14:00

结束时间：12月16日16:00