vb.net服务器启动后cpu占用了70_企业服务器资源使用率方面的一些思考

随着企业信息化的发展，数据中心的规模也越来越大。在2010年美国环境保护署(US EPA)的一一份报告中指出，美国总能耗的3％是数据中心的功耗，而2012年纽约时报的一项分析指出，当年全球数据中心能耗突破每小时300亿瓦，相当于12个大型核电站的发电量。随着云计算、大数据、人工智能、移动互联的发展，数据中心能耗还将进一步加大。2017年，瑞典研究人员Anders Andrae预测，到2025年，数据中心将占到全球能耗的最大份额，占33％。在地主家也要节约粮食的时代，数据中心如何提高运行效率成为数据中心运营的十分关键的问题，也是大型企业IT管理中的重要工作。对于传统企业来说，提高数据中心运行效率和互联网企业是完全不同的。互联网企业的信息系统标准化程度高，同类型负载的服务器数量较大，比较容易按照规则进行统一管理。而传统行业的大型企业系统建设较为分散，不同系统之间的差异性较大，进行“瘦身健体”的难度高于互联网企业。对于传统企业来说，提高服务器的综合资源使用率，淘汰老旧设备，进行性能优化都是提升企业数据中心运行效率，降低数据中心综合能耗的有效手段。从淘汰老旧设备上来看，十多年前的设备的能耗比远远高于现有设备。以往我们只是考虑腾退老设备后给一些非关键业务系统使用，而没有考虑其综合使用成本。比如说我们把一套老系统从一台功耗8000瓦的小型机上迁移到一台X86服务器上，那么我们继续在这台小型机上运行一些非关键业务系统划算还是直接把这台小型机关机下线划算呢？如果我们按照这台小型机的实际功率是4000瓦计算，每年耗电大约3万5千瓦，光电费一项就可能高达5万元，再算上占用机架的成本，直接下线这台小型机，购买一台1路或者2路服务器来替它肯定是更划算的买卖。十多年前老白曾经帮助一个客户把100多M的数据从一台90年代初购买的VAX 6510的RDB数据库迁移到一台X86服务器的oracle数据库中，当时客户高兴的立马请老白吃了一顿海鲜大餐。据那个数据中心主任说，单单这台服务器，每年的电费就高达十多万，关闭了这台服务器后，数据中心的电费开支就少了1/4。除了下线老旧设备，数据中心提质增效的另外一个法宝就是云化和资源池化。云化就不做过多的讨论了，目前绝大多数企业都已经形成了对云平台的正面评价，能够上云的模块尽可能上云已经是企业的共同认知。而对于一些暂时无法上云的系统模块或者组件，特别是一些大型的数据库系统，采用资源池化的建设可以有效的提高资源的使用率。以国家电网为例，2015年开始推广数据库资源池技术，在一台服务器上运行多个数据库实例，使服务器的综合资源使用率达到一个较为合理的水平。 这些年的数据库资源池建设 确实已经节约了大量的 资源，根据 不完全统计， 在 某一期的 数据库资源池建设中， 将原本部署在313台 服务器上的数据库整合到了 83台服务器的资源池中，节约服务器2 30台，节约服务器 采购成本超过1000万。 不过随着“瘦身健体”工作的进一步深入，需要进一步榨干数据库资源池中的水分。池化环境中大多数系统的负载依然很低，于是在新的阶段中，国网提出了实例再合并，授权再压缩，功能再整合的要求，进一步优化数据库资源池，提高综合资源使用率。 资源池进入深水区和初步建立资源池的技术要求完全不同。原有的资源池建设，整合后的整体系统负载也不高，CPU使用率在10%-20%之间，IO吞吐量不过1000-2000 IOPS。随着三个再的要求具体落实，资源使用率将大幅提升。随着进一步的整合工作开展，系统负载将从相对较低向相对较高变化，负载提高后，系统运行稳定性、多个数据库实例之间的资源隔离、数据中心能耗变化、数据中心环境温度控制等都将面临新的挑战。如果不预先进行一些科学的分析，盲目提高资源使用率的风险是十分大的。 首先我们来看CPU使用率的问题，CPU使用率多少比较合适呢？在进行数据库资源池建设之前，我们分析过很多用户的数据库服务器，一些小系统的数据库服务器CPU使用率日均值都低于1%，没错，不是10%而是1%。那么资源池化后的目标是什么呢？10多年前老白参与平安保险的IT容量管理项目，当时提出的目标是数据库资源池的CPU使用率不低于30%，不高于70%。当时提出的CPU使用率是业务最高峰期间的1小时平均值，而不是日平均。目前的互联网公司的数据中心CPU使用率的日平均值一般在20-40%之间。 首先我们来看看CPU使用率和能耗之间的关系，如果CPU使用率和能耗之间是较为线性的，那么我们就不需要考虑能耗的问题了，重点考虑CPU使用率与系统稳定运行之间的关系。不同的业务负载下，CPU使用率与功耗的关系是不同的。

2016年维尔茨堡大学的Jóakim von Kistowski、HP公司的Klaus-Dieter Lange等六位科学家进行了一项关于各种负载下CPU使用率与服务器功耗之间的关系的研究，发表了论文Variations in CPU Power Consumption(DOI: 10.1145/2851553.2851567)。他们采用LINPACK、LU、SOR、SHA256等多种负载对服务器的功耗与CPU使用率进行了全面的分析，获得了大量十分值得我们关注的数据。

从论文中的数据看，这几种负载下的CPU使用率与功耗之间关系的拟合曲线存在一定的不同，不过从总体上看还是线性的，不存在某个拐点后功耗突然变高的情况。从这一点我们可以放心的提高CPU的使用率了，CPU使用率提高并不会存在功耗浪费的问题。上述数据的实验环境是一台富士通的X86服务器，CPU是Xeon E5-2680 v3 。

该图显示了每个工作负载的功耗(瓦特)负载水平范围。与其他工作负载相比，Idle和LINPACK各自仅具有一个负载级别。空闲功率是最小的消耗者，而LINPACK是，最大的消费者，其次是LU满负荷。工作负荷在整个负荷水平上几乎呈线性比例。另外一个对我们十分有价值的数据是关于CPU TURBO的分析：

从CV分析上看，启动turbo模式后IDLE时的的CV高达33.17%，而在节能模式下，只有0.84%。追求高性能带来的服务器空转功耗的巨大提高。在早些年我们为了追求性能，大部分企业都在服务器上架时关闭节能模式，这会导致数据中心能耗的巨大浪费。关于CPU使用率的最佳范围，由于和企业的应用系统关系很大，并且缺乏足够的专业分析，因此只能做一些初步的估算。互联网企业的日均20-40%的成果也可以作为一个重要的参考因素。前几天老白有一篇涉及到LINUX的CPU使用率与CPU资源的使用率之间差异的文章，其中有一个观点是，单纯从CPU使用率上看，在X86+LINUX的环境下，和CPU实际的资源占用比例之间大约有2/3的偏差。当CPU使用率达到60%的时候，服务器的CPU处理能力已经接近满负荷了，长时间超过这个指标，则CPU硬件资源会长期处于不足的状态，对于一些CPU时间敏感的应用，会明显感受到响应时间变长。不过对于大多数系统，包括数据库服务来说，前端的感受相对不是很明显，因为在IO、锁、并发控制方面的等待时间可能会更长。因此来说，纯粹从资源的情况来看，将CPU使用率定在40以上甚至50以上，对于数据库资源池来说完全是没问题的。从多年的运维经验来看，随着负载的增加，运维的难度也会有所增加。不过整体运维难度不仅仅与CPU相关，而是和整体的内存使用情况，IO负载等的组合体相关。针对不同的运维对象，我们构建了反映出其负载的负载模型，该模型与一系列运维对象的运行指标有关。在负载模型中，我们的设计是，当负载指数超过80(满分100)后，运维对象的故障率就会变大，运维难度也随之增加。我们构建的服务器综合资源使用率是基于CPU/内存/IO等方面的系统资源的，负载模型是基于运维对象的关键指标的，这两个完全不同的指标体系中因为运行于共同的硬件资源，因此其间是存在一定的关联的。通过大量的生产数据的分析我们发现，当服务器的综合资源使用率不超过60%的情况下，系统负载指标大概在60-70之间。因此我们考虑在数据库资源池建设的初期，服务器综合资源使用率确定在40-50%存在的风险较小，同时资源使用率又较高。随着资源池运维管理水平的提高，再进一步提升这个指标的下限是比较科学的。针对企业数据库资源池而言，另外一个影响因素是数据库优化。以往数据库优化是从提高系统稳定性，改善用户使用的角度出发的。而从瘦身健体的角度来看，优化可以降低数据库服务器的综合资源使用率，降低服务器的能耗开销。因此在数据库资源池建设过程中，开展常态化优化工作是十分必要的。这个工作使IT健康管理与瘦身健体两项工作紧密的结合在一起了。通过IT健康管理，一方面采用自动化智能化的手段协助开展常态化优化工作(在2019年的IT健康管理试点工作中，曾经尝试了一名DBA同时对40多套数据库系统开展常态化优化工作，在一个月内完成了近200个消缺工作)，另外一方面，IT健康管理的深度数据分析工作又可以为数据库资源池的健康运行提供大量的定量分析数据(比如负载评估、性能评估)。本来想写个短文，没想到零零碎碎写了这么多。好像这个问题还没有谈透，确实这是一个大课题，值得多花点时间来研究。关于这方面的一些深入分析，留待以后慢慢写吧。