CPU每个核心的占用率测量

序言

虽然上篇文章中已经分析了广播网关（以下简称B-GW）的最大流量，但是现在还有两个关键的问题需要明确：

• 一个是B-GW“多合一”的必要性。
  也就是有没有这样一种需要，当多台发射机需要多台B-GW传输数据时，我们可以将多台B-GW的功能集中到一台B-GW，处理多台B-GW的数据量。分析这个问题需要结合3.0标准还有现在的电视标准中的链路设备（比如DVB-T2中的T2-MI）来分析，尽管上次参加B-GW PlugFest的几个公司基本都只做了只支持一个B-GW数据量的设备，不管支持4路PLP也好、8路PLP也好，总的数据量都只是一台RF射频发射机所能支持的数据量。从技术上来说，这种“多合一”当然是没有这种限制的，所以主要还是看标准中关于这个问题是如何描述的、实际商用的B-GW设备是否只支持单台发射机的数据量、有没有做成“多合一”B-GW的必要以及没有做成“多合一”B-GW主要的限制和顾虑在什么地方。

• 另一个就是在单台B-GW（目前是在实验室台式机上运行，详细配置也在上篇文章中有过介绍）以满负荷运行时候CPU占用率。
  不仅是总的CPU占用率，由于实验室台式机是多核CPU，所以更重要的是测量满负荷运行时候是否之前测出来的CPU占用率是多核心还是单核心的占用率，这样对于CPU选型才有明确的参考，才能从理论上证明硬件优化的必要和优势。
  

  
  

多核CPU单核占用率测量

1. 理论基础：

• 上次测量的不足之处：

  • 没有运行实际数据处理程序
  • 没有在最大数据量下测量
  • 采用解码软件VLC增加了CPU占用率

• 针对上次出现的问题，做出如下改进：

  • 多端口抓包模拟实测（2-4端口）
  • 使用最大理论数据量（总和）

  • 采用tcpdump抓包工具（只有报文分析没有解码过程模拟实际程序）

  • 注：之所以没有运行实际数据处理程序，一个原因是程序下行通道还没能连通，另一个是时间关系，本次测量需要及时提交测量结果。先模拟测量一下吧。

• tcpdump：可实现对特定网卡特定端口特定地址或特定协议进行抓包。

2. 常用工具和命令：

• top命令： top工具可以显示不同进程CPU的实时占用率，也可以显示每个CPU的平均占用率。但是无法显示每个进程/线程的CPU占用率情况。

  • 某一个线程在其运行期间其所使用的CPU核心可能会发生变化。
  • 在多核的情况下top命令输出的CPU使用率实质是进程在不同核心上占用率之和（见表1和表2）。

• mpstat命令/sar命令：要查看CPU波动情况，尤其是多核机器上。该命令可间隔一定时间采样一次CPU的使用情况，每个核的情况都会显示出来。但是也不能显示特定进程/线程的CPU占用率，如果不需要特别精确的测量，可在没有多少系统进程的情况下减去这些进程的占用率即可(ps命令)。

  • mpstat命令：mpstat -P ALL 1 4 （1：隔1s更新，4：统计4次）
    

    

  • sar命令：sar -P ALL 1 3 （1：隔1s更新，3：统计3次）
    

    

• ps命令：通过ps命令可以查看系统中相关进程/线程的CPU使用率的信息，ps命令算出来的CPU使用率相对于进程启动时的平均值，随着进程运行时间的增大，该值会趋向于平缓。

  • 所以该命令为我们提供了CPU占用率的稳定统计值
  • 还可查看特定进程使用了哪个CPU核心（静态）

• /proc文件系统：/proc文件系统是一个伪文件系统，它只存在内存当中，而不占用外存空间。它以文件系统的方式为内核与进程提供通信的接口。用户和应用程序可以通过/proc得到系统的信息，并可以改变内核的某些参数。由于系统的信息，如进程，是动态改变的，所以用户或应用程序读取/proc目录中的文件时，proc文件系统是动态从系统内核读出所需信息并提交的。/proc目录中有一些以数字命名的目录，它们是进程目录。系统中当前运行的每一个进程在/proc下都对应一个以进程号为目录名的目录/proc/pid，它们是读取进程信息的接口。此外，在Linux2.6.0-test6以上的版本中/proc/pid目录中有一个task目录，/proc/pid/task目录中也有一些以该进程所拥有的线程的线程号命名的目录/proc/pid/task/tid，它们是读取线程信息的接口。

  • /proc/cpuinfo文件：该文件中存放了有关CPU的相关信息(型号，缓存大小等)。
    
    • 可以通过该文件根据processor出现的次数统计CPU的逻辑个数(包括多核、超线程)。
  • /proc/stat文件：该文件包含了所有CPU活动的信息，该文件中的所有值都是从系统启动开始累计到当前时刻。
    
    • 注意：由这个文件系统提供的进程/线程CPU占用时间信息是从系统启动开始算的。
  • /proc/< pid>/stat文件：该文件包含了某一进程所有的活动的信息，该文件中的所有值都是从系统启动开始累计到当前时刻。
  • /proc/< pid>/task/< tid>/stat文件：该文件包含了某一线程所有的活动的信息，该文件中的所有值都是从系统启动开始累计到当前时刻。
  • 注：参考文章[2]，较为准确的CPU占用率计算方法
    
    • 单核情况下CPU占用率的计算：通过读取/proc/stat 、/proc/< pid>/stat、/proc/< pid>/task/< tid>/stat以及/proc/cpuinfo这几个文件获取总的CPU时间、进程的CPU时间、线程的CPU时间以及CPU的个数的信息，然后通过一定的算法进行计算(采样两个足够短的时间间隔的CPU快照与进程快照来计算进程的CPU使用率)。可提供以下CPU占用率计算
      
      • 总的CPU占用率计算
      • 某一进程CPU占用率计算
      • 某一线程CPU占用率计算
    • 多核情况下CPU占用率的计算：该情况下同样提供
      
      • 总的CPU占用率计算
      • 某一进程CPU占用率计算（多核情况下某进程CPU占用率 = 逻辑CPU个数×单核CPU占用率×100%）
      • 某一线程CPU占用率计算

• tcpdump工具：可实现对特定网卡特定端口特定地址或特定协议进行抓包，并且还提供and/or/not等逻辑语句来去除无用信息。参考文章：http://blog.csdn.net/baidu_35692628/article/details/76038713

3. 测试方案：

• 单网卡，多端口，单进程，最大码率测量
  
  • 多端口接收（3端口）
  • 总流量80Mbps（1个20Mbps + 2个30Mbps）
  • tcpdump抓包（利用libpcap工具，libpcap是从tcpdump项目中剥离出来的一个库）
  • top和ps命令测量CPU每个核的占用率（Linux平台）
  • 利用资源管理器计算CPU每个核的占用率（Windows平台）

4. 测试环境：

• Linux平台：
  
  • Ubuntu 16.04.2 LTS, x86_64, 4.4.0-77-generic, 4 Intel(R) Core(TM) i5-4590 CPU @ 3.3GHz

5. 测试结果：

• Linux平台：

  • top查看指定PID：top -p pid(s)，如 top -p 28973,7219
  • top显示运行特定进程的CPU核：top -> f -> d高亮’P = Last Used Cpu(SMP)’ ->q （实时）
  • ps -eo pid,args,psr命令查看进程号-进程命令行参数-分配给进程的CPU （稳定值，从进程运行到当前时刻，随着时间推移该值趋于稳定，ps aux查看）

  • ps -eo pid,pcpu | sort -n -k 2查看进程CPU占用率，为运行稳定值

  • 80Mbps，接收不存储：tcpdump udp port 1234/5/6

    • 端口1234（20Mbps）：MEM = 0.1%，CPU = 0.9%,0.9%,0.7%
    • 端口1235（30Mbps）：MEM = 0.1%，CPU = 0.9%,1.1%,0.8%
    • 端口1236（30Mbps）：MEM = 0.1%，CPU = 0.9%,1.0%,0.9%
    • 平均CPU占用率：2.7% （每一端口均由ps命令统计，为运行稳定值）
  • 80Mbps，接收并存储：tcpdump -i eth1 host 172.16.7.206 and port 1234 -w /opt/temp/1234.pcap
    
    • 端口1234（20Mbps）：MEM = 0.1%，CPU = 0.1%,0.1%,0.1%
    • 端口1235（30Mbps）：MEM = 0.1%，CPU = 0.1%,0.1%,0.1%
    • 端口1236（30Mbps）：MEM = 0.1%，CPU = 0.1%,0.1%,0.1%
    • 平均CPU占用率：0.3%（每一端口均由ps命令统计，为运行稳定值）

注：测试中还发现每个端口都存在不同程度的丢包情况，而且就算单端口发较低速率的包仍然存在丢包，可能跟tcpdump缓存设置有关。

5. 测试结果分析：

• 单核占用还是多核占用：
  
  • 经检测发现（top添加CPU核心占用显示列），同一进程在不同时刻会使用不同或多个CPU核心（Linux Kernel SMP负载均衡技术），以本次试验用台式机为例，同一进程在不同时刻4个核心都会使用。进程的CPU占用率是针对4个核心来说的。
  • 有的进程执行过程中始终只占用单个固定核心，如情形一所示（VLC进行CPU占用测试-始终占用一个核；tcpdump多端口抓包就是这种情形-一次占用一个核）
  • 有的进程一次占用多个核，如情形二所示

(1) 情形一：一个进程；单核能够解决的情形。程序在不同时刻使用不同核心，但是负荷量是一个核心就能承载的。

核心\时间	1s	2s	3s	4s	平均核心占用率
Core 1		40%			10%
Core 2	40%				10%
Core 3			40%		10%
Core 4				40%	10%
平均CPU占用率	10%	10%	10%	10%	10%
进程CPU占用率	40%	40%	40%	40%	4s内的占用率：(40+40+40+40)/4 = 40%

(2) 情形二： 一个进程；多核才能Cover的情形。 程序在不同时刻使用不同核心，但负荷量是需要多核才能承载。

核心\时间	1s	2s	3s	4s	平均核心占用率
Core 1	20%	25%	0%	30%	（20+25+30）/4 = 18.75%
Core 2	60%	30%	70%	0%	（60+30+70）/4 = 40%
Core 3	35%	65%	75%	80%	（35+65+75+80）/4 = 63.75%
Core 4	45%	40%	15%	50%	（45+40+15+50）/4 = 37.5%
平均CPU占用率	40%	40%	40%	40%	（18.75+40+63.75+37.5）/4 = 40%
进程CPU占用率	160%	160%	160%	160%	4s内的占用率：(160+160+160+160)/4 = 160%

注：每一个时段内的CPU占用率都是各个核心占用率的总和，即一个进程多线程占用不同核心，由命令mpstat -P ALL 1 4得到的图。
平均CPU占用率图示：Windows平台

• Linux平台接收不存储比接收存储的CPU占用率高原因分析：

  • 分析tcpdump数据接收过程发现，存储数据相对不存储显示数据来说，少了BPF包过滤过程和tcpdump输出显示过程，因而CPU占用率偏低。

• 与VLC接收时CPU占用率有较大出入的原因：

  • VLC视频播放软件，需要完成视频的解码和播放工作，解码播放是非常耗费CPU资源的事情，因而占用率出入较大。
  • 另外，tcpdump接收端口数据为多核心运行，VLC接收时，经检测为单核心运行。

• 本次测量数据是否能准确反应实际的系统CPU资源需求：

  • 上次的VLC测量是单核CPU的占用率，不过由于VLC的解码播放使得CPU占用率过高，并不能反应实际的系统性能；本次tcpdump多端口抓包测试，在程序功能上能比较真实的反应系统功能，但是实际的CPU占用上，由于B-GW程序不仅使用了libpcap抓包，还需要进行报头添加、队列维护、信令生成以及线程调度等功能，实际的CPU占用率将会比本次测量结果高。
  • 如果采用单核CPU基本能够满足资源需求，不过考虑到程序的多线程并发执行，具体CPU选型应满足此需求。

B-GW“多合一”的需求分析

(1) 商业价值：
我用一台B-GW就能实现多台B-GW的功能并且降低了你的成本，可能你原来需要3台B-GW（80Mbps/台；80万/台），我现在“多合一”之后的B-GW也能支持相同的数据流量（240Mbps/3台），同时成本降低到150万，那这是商业价值。至于说多个CPU配置多个B-GW，跟我现在一个更高性能的CPU就能配置多台B-GW，这个其实内含在成本里面。

(2) 实际可行性分析：
基于已有的系统知识，对“多合一”可行性分析如下

• 端口分配的问题：
  
  • 接收数据：3.0规定了特定上层信令的接收端口，“多合一”的B-GW中不同帧的信令数据将会混淆？
  • 发送数据：标准规定了数据的发射端口范围，“多合一”的B-GW中同样存在数据不能正常分离的问题？
• 资源配置的问题：
  
  • 与数据源的通信：无法区分不同帧的配置参数？
  • 时间同步和信令配置：同一B-GW配置多帧数据较为复杂

其实我个人倾向于认为存在“多合一”的需求，但由于目前这么做比较复杂，等后期条件成熟再作考虑。

(3) 需要解决的科学问题：

• 如果做算法研究或者数据传输优化：

  • 算法研究情况下，比如你如果光是加入一些算法来对比没有加入算法时候提高了资源利用率或者增大了系统吞吐量，那么并没有反应出研究的科学问题。符合研究实际的做法是，我利用上了算法并且对比不同算法之间的性能确定对于系统来说最优的调度算法或者能够提出一种更优的算法，那么这算找到了问题；
  • 或者比如说你加入多用户加入回传信道的需求反应出调度必要性，同时利用多用户通过回传信道反馈的信息进行跨层调度，这也不够，因为同样是没有讲清楚研究的问题是什么。不能说你是第一个做3.0 B-GW的这个调度，利用上了这种调度并且带来了性能的提升这就是解决了科学问题，不是的，这只是搬用了另一套别人做过的东西放到这个系统上，也只是工作，你还是没有讲清楚你做这件事情的时候有什么困难解决了什么问题。真正的做法是你用上了这种方法进行调度所带来的好处是什么，比如用户体验得到了提高、资源利用率得到了提高。

• 如果做硬件实现：

  • 一个对比点放在，CPU负荷上，举个例子，假如“4合1”之前，每个B-GW总的CPU占用率在30%，但是“4合1”之后，在保证相同处理和调度需求的同时，总的CPU占用率只有70%，那这是一个优化；
  • 另一个对比点更重要，那就是硬件实现资源Off-Load的问题，不管是单台B-GW实现也好、“多合一”实现也好，都只是工作量上的问题，硕士毕业必须要考虑问题的解决，那么这个问题会是但不仅是资源Off-Load的问题，就是说，我通过FPGA加速加快了数据处理速度，同时分担了原本CPU的部分用于数据处理和调度的资源，Off-Load出来的这部分资源可以用来做其他事情，比如更复杂的调度算法或者更复杂的功能实现都可以，总之就是通过这个Off-Load资源的优化来反映研究的科学问题。这样才能将故事讲好。但是可以预见，这个实现难度将会上升，毕竟可能涉及到软件和硬件的互联和调用，这又是一块很大的工作量。

Acknowledgements:
http://blog.csdn.net/unix21/article/details/8544578
http://blog.csdn.net/chen3888015/article/details/7432868#t9
http://blog.csdn.net/nanyun2010/article/details/23445223
http://blog.csdn.net/zqt520/article/details/13630963

2017.05.15
这篇文章主要是一些个人总结，不是很系统。文章难免有疏漏和不足之处，恳请读者指出