OCR 服务CPU负载过高问题分析。

问题简述

在 OCR 的云侧服务部署时，部署了4个检测，8个识别的线上服务。
在全量服务之后，出现了 CPU 负载过高的问题，这个问题也是第一次遇到。

总核数 = 物理CPU个数 X 每颗物理CPU的核数 
总逻辑CPU数 = 物理CPU个数 X 每颗物理CPU的核数 X 超线程数

# 查看物理CPU个数
cat /proc/cpuinfo| grep "physical id"| sort| uniq| wc -l
# 查看每个物理CPU中core的个数(即核数)
cat /proc/cpuinfo| grep "cpu cores"| uniq
# 查看逻辑CPU的个数
cat /proc/cpuinfo| grep "processor"| wc -l
# 查看CPU信息（型号）
cat /proc/cpuinfo | grep name | cut -f2 -d: | uniq -c

问题分析

参考一，CPU负载的含义及指标 ：https://www.cnblogs.com/muahao/p/6492665.html

参考二，CPU高占用线程定位方法：
https://www.cnblogs.com/SunshineKimi/p/10652041.html

1. 首先定位是哪个进程及哪个线程对应的功耗过高。

如何定位是哪个服务进程导致CPU过载，哪个线程导致CPU过载，哪段代码导致CPU过载？

• 步骤一、找到最耗CPU的进程
  工具：top
  方法：
  执行: top -c ，显示进程运行信息列表
  键入P (大写p)，进程按照CPU使用率排序
  图示：
  如上图，最耗CPU的进程PID为1894

• 步骤二：找到最耗CPU的线程
  工具：top
  方法：top -Hp 1894 ，显示一个进程的线程运行信息列表
  键入P (大写p)，线程按照CPU使用率排序
  图示：
  如上图，进程10765内，最耗CPU的线程PID为9454

• 步骤三：将线程PID转化为16进制
  工具：printf
  方法：printf “%x” 9454
  如上图，9454对应的16进制是 24ee，当然，这一步可以用计算器。
  之所以要转化为16进制，是因为堆栈里，线程id是用16进制表示的。

• 步骤四：查看堆栈，找到线程在干嘛
  工具：pdbx, pystack
  方法：jstack 10765 | grep ‘0x2a34’ -C5 --color
  参考：http://www.blogjava.net/stone2083/archive/2013/08/19/403028.html
  打印进程堆栈
  通过线程id，过滤得到线程堆栈

• 步骤五：最后发现， 确定为 Flask 多线程机制被开启，导致在高并发下Flask会Fork多个子线程，批量复制模型的所有线程，并且在处理服务后，未对冗余线程进行回收，导致整体服务线程激增。