1 结论

通过本次性能优化，总结了几条经验。

■频繁的加解锁会提高系统空间的CPU占用率

锁在内核的实现是通过队列来实现的，加锁操作把线程放入等待队列，解锁操作是才能够等待队列获取一个线程来获取锁。所以频繁的加解锁CPU的开销是非常大的。

■锁和线程的数量是两个矛盾体。

对于固定数量的锁，线程的数量并非越多越好。我们需要在两者之间找平衡点。如何来找？通过测试找出最优值。

■多CPU环境下的CPU瓶颈问题的定位

在多CPU环境中，如果某个CPU占用率接近100%，可以得出这样的结论，某个线程的粒度太大造成了CPU使用率不均衡，可以通过减小线程粒度来解决这个问题。

如果每个CPU的占用率远小于100%，不能得出CPU不是瓶颈的结论，本文就是一个典型的案例。当处理某个任务的线程数量不够，且线程有等待的操作(比如：加锁动作，sleep动作)，等待的操作可以使得线程在各个CPU之间均衡的调度，从而使得我们看到各个CPU的占用率分布均衡并且比较低。这种性能问题只能通过结合应用代码来进行定位，在本文中通过观察队列的大小来的得出CPU是瓶颈的结论。这种问题的解决方案是增加线程数量。

2 问题的提出

PROCESSOR进程运行在12G内存，12个CPU的服务器上，性能运行参数如下：

	CPU total%	CPU sy%	CPU us%	处理消息的能力
优化前	334%	108.1%	224.1%	37000 package/s

图1 优化前的性能参数

优化目标：

1增加CPU的利用率

2降低系统空间CPU率占用率的占比

3 问题分析

如图2所示，PROCESSOR专门处理DISPATCHER分发过来的消息，处理完成之后发送给REDUCER进行合并入库处理。如图3所示，Processor网元采用的流水线架构。每个SubProcessor由一个线程实现，每个subprocessor对应一个单独的队列。subprocessor从自己的队列获取待处理的消息，处理完成之后，若消息还需进一步处理，则会把这个消息放入下个subprocessor的消息队列中。subprocessor在处理消息的过程中，会把相关的统计数据放入内存表。【注：现阶段，MSA仅仅提供了用户/BS/PCF的统计信息】。

图2 组网结构

图3 processor的内部架构

通过测试发现，但DISPATCHER发送的消息到达阀值后，subprocessor-4对应的队列中的消息首先达到其阀值10000，当队列中的消息达到阀值后，会阻塞subprocessor-3向queue-4放入消息，所以随后导致queue-3队列满，以此类推，queue-1队列满，所以PROCESSOR丢弃UDP消息。所以subprocessor-4是系统的瓶颈，我们需要提高subprocessor-4处理消息的能力。

优化措施1：增加subprocessor-4中的线程数量

我们把subprocessor-4对应的线程提供到4个，性能测试结果如下。可以发现，提升幅度非常大。还有没有进一步优化的空间？cache的处理能力为500000次/S，每个消息携带4个service，处理每个service需要操作cache两次，包括一次查询和一次insert。所以500000次/s= 60000 * 8。所以现在cache的处理能力成为了系统的瓶颈。

	CPU total%	CPU sy%	CPU us%	处理消息的能力
优化后	775%	170.5%	576%	60000 package/s

图4 第一步优化后的性能

图5 第一次优化后TOP命令显示CPU占用率详细信息

优化措施2：减少操作cache的次数

我们把subprocessor-4中处理消息的一个service需要两次cache操作压缩到一次。即cache提供insertIfAbsent接口。进行这个优化后，下一个瓶颈在哪里？我们通过跟踪各个subprocessor的队列，发现subprocessor-1的队列首先达到阀值。理所当然，subprocessor-1的处理能力成了系统瓶颈。

优化措施3：增加subprocessor-1中的线程数量

subprocessor-1的任务是对消息队列中的消息进行解码。通过测试发现，subprocessor-1中的线程数量的最优值为6。如果线程数量过高，发现处理消息的能力反而下降。这是由于多个线程都需要从相同的队列中获取消息，消息队列成了热点，线程必须通过互斥锁来解决并发。总所周知，频繁的进行加解锁时非常耗费CPU的，所以线程为6是加解锁开销和消息解码之间的最佳平衡值。

查看图7，你会发现一个非常意外的结果。系统空间CPU占比(sys/us)下降了。这是减少cache操作次数的结果，每次进行cache操作，都需要加解锁。

	CPU total%	CPU sy%	CPU us%	处理消息的能力
优化后	928%	214%	667.9%	97000 package/s

图6 第3步优化后的结果，本的是的输入消息只包含了一个service

图7 第3步优化后的TOP命令的显示

性能调优实践-提升cpu利用率相关推荐

Azure SQL性能调优实践
Azure SQL性能调优实践注:blog具备时效性,所有内容都是在当前时间为准,截止时间2017-6-5 首先,创建了一个测试数据库 MaxAadventureWorkTest 使用了示例数据库 ...
实时数仓入门训练营：Hologres性能调优实践
简介:<实时数仓入门训练营>由阿里云研究员王峰.阿里云高级产品专家刘一鸣等实时计算 Flink 版和 Hologres 的多名技术/产品一线专家齐上阵,合力搭建此次训练营的课程体系,精心打 ...
JVM性能调优实践——G1 垃圾收集器分析、调优篇
前言关于G1 GC以及其他垃圾收集器的介绍可以参考前一篇JVM性能调优实践--G1 垃圾收集器介绍篇.了解了G1垃圾收集器的运行机制之后,就可以针对一些GC相关参数来调整内存分配以及运行策略.下文的 ...
Web2.0网站性能调优实践(引用王宗义)
Web2.0网站性能调优实践当前web2.0革命风起云涌,web2.0强调服务,而服务最基本的要求是速度快和稳定,离开这两个谈功能强大和易用性都没有任何意义.本文介绍一些关于笔者运营一个web2.0 ...
【Elasticsearch】es 5.3.0 bulk index 性能调优实践
1.概述转载:elasticsearch5.3.0 bulk index 性能调优实践一.集群基本信息每天日志量70亿 ES版本: 5.3.0 机器部署 master node: 3台 data ...
【Elasticsearch】eBay上的Elasticsearch性能调优实践
1.概述翻译:eBay上的Elasticsearch性能调优实践中文版:eBay上的Elasticsearch性能调优实践 Elasticsearch 是一个基于 Apache Lucene 的开 ...
中间件业务在网易轻舟容器平台的性能调优实践
随着业务容器化的推进,经常有客户抱怨应用 QPS 无法和在物理机或者云主机上媲美,并且时常会出现 DNS 查询超时.短连接 TIME_OUT.网络丢包等问题,而在容器中进行调优与诊断的效果因为安装工具 ...
Java性能调优实践
作者:张俊城, 郭理勇, 和刘建 https://www.ibm.com/developerworks/cn/java/j-lo-performance-tuning-practice/ind ...
网易轻舟 Serverless 平台 Knative 性能调优实践
作者 | 刘勤龙策划 | 田晓旭首发 | InfoQ Serverless 技术正在获得越来越多的认可.CNCF 2019 年报告显示,41% 的受访者表示已经在使用 Serverless,另外 ...

性能调优实践-提升cpu利用率

1 结论

2 问题的提出

3 问题分析

性能调优实践-提升cpu利用率相关推荐

最新文章

热门文章