1 结论
通过本次性能优化，总结了几条经验。
■频繁的加解锁会提高系统空间的CPU占用率
锁在内核的实现是通过队列来实现的，加锁操作把线程放入等待队列，解锁操作是才能够等待队列获取一个线程来获取锁。所以频繁的加解锁CPU的开销是非常大的。
■锁和线程的数量是两个矛盾体。
对于固定数量的锁，线程的数量并非越多越好。我们需要在两者之间找平衡点。如何来找？通过测试找出最优值。
■多CPU环境下的CPU瓶颈问题的定位
在多CPU环境中，如果某个CPU占用率接近100%，可以得出这样的结论，某个线程的粒度太大照成了CPU使用率不均衡，可以通过减小线程粒度来解决这个问题。
如果每个CPU的占用率远小于100%，不能得出CPU不是瓶颈的结论，本文就是一个典型的案例。当处理某个任务的线程数量不够，且线程有等待的操作(比如：加锁动作，sleep动作)，等待的操作可以使得线程在各个CPU之间均衡的调度，从而使得我们看到各个CPU的占用率分布均衡并且比较低。这种性能问题只能通过结合应用代码来进行定位，在本文中通过观察队列的大小来的得出CPU是瓶颈的结论。这种问题的解决方案是增加线程数量。
2 问题的提出
PROCESSOR进程运行在12G内存，12个CPU的服务器上，性能运行参数如下：
CPU total%
扫描二维码关注公众号，回复：
1523027 查看本文章
|
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命令的显示