CPU个数、CPU核数和CPU逻辑核数的关系
概念
- 物理CPU数（physical id）：主板上实际插入的cpu数量，可以数不重复的 physical id 有几个
- CPU核心数（cpu cores）：单块CPU上面能处理数据的芯片组的数量，如双核、四核、八核等
- 逻辑CPU数：
逻辑CPU=物理CPU个数×每颗核数 #不支持超线程技术或没有开启次技术
逻辑CPU=物理CPU个数×每颗核数 *2 #表示服务器的CPU支持超线程技术
解读ubuntu/proc/cpuinfo文件
processor ：系统中逻辑处理核心数的编号，从0开始排序。
vendor_id ：CPU制造商
cpu family ：CPU产品系列代号
model ：CPU属于其系列中的哪一代的代号
model name ：CPU属于的名字及其编号、标称主频
stepping ：CPU属于制作更新版本
cpu MHz ：CPU的实际使用主频
cache size ：CPU二级缓存大小
physical id ：单个物理CPU的标号
siblings ：单个物理CPU的逻辑CPU数。siblings=cpu cores [*2]。
core id ：当前物理核在其所处CPU中的编号，这个编号不一定连续。
cpu cores ：该逻辑核所处CPU的物理核数。比如此处cpu cores 是4个，那么对应core id 可能是 1、3、4、5。
apicid ：用来区分不同逻辑核的编号，系统中每个逻辑核的此编号必然不同，此编号不一定连续
fpu ：是否具有浮点运算单元（Floating Point Unit）
fpu_exception ：是否支持浮点计算异常
cpuid level ：执行cpuid指令前，eax寄存器中的值，根据不同的值cpuid指令会返回不同的内容
wp ：表明当前CPU是否在内核态支持对用户空间的写保护（Write Protection）
flags ：当前CPU支持的功能
bogomips ：在系统内核启动时粗略测算的CPU速度（Million Instructions Per Second
clflush size ：每次刷新缓存的大小单位
cache_alignment ：缓存地址对齐单位
address sizes ：可访问地址空间位数
power management ：对能源管理的支持
确认CPU是否启用了超线程
cat /proc/cpuinfo | grep -e "cpu cores" -e "siblings" | sort | uniq
如果cpu cores数量和siblings数量一致，则没有启用超线程，否则超线程被启用。
获取当前服务器的核心数
第一种方法：
是通过top htop命令查看核心数
第二种方法：
计算processor计算核心数：
cat /proc/cpuinfo | grep "processor"| wc -l
第三种方法：
physical id 的最大值乘以siblings
其中，查询服务器有多少几颗CPU
cat /proc/cpuinfo | grep "physical id" |sort |uniq
查询CPU siblings数量
cat /proc/cpuinfo | grep "siblings" | uniq
CPU使用率和CPU负荷
什么是 CPU 使用率?
CPU 使用率就是 CPU 非空闲态运行的时间占比，它反映了 CPU 的繁忙程度。比如，单核 CPU 1s 内非空闲态运行时间为 0.8s，那么它的 CPU 使用率就是 80%;双核 CPU 1s 内非空闲态运行时间分别为 0.4s 和 0.6s，那么，总体 CPU 使用率就是 (0.4s + 0.6s) / (1s * 2) = 50%，其中 2 表示 CPU 核数，多核 CPU 同理。
什么是平均负载?
平均负载(Load Average)是指单位时间内，系统处于 可运行状态(Running / Runnable) 和 不可中断态 的平均进程数，也就是 平均活跃进程数。
可运行态进程包括正在使用 CPU 或者等待 CPU 的进程;不可中断态进程是指处于内核态关键流程中的进程，并且该流程不可被打断。比如当进程向磁盘写数据时，如果被打断，就可能出现磁盘数据与进程数据不一致。不可中断态，本质上是系统对进程和硬件设备的一种保护机制。
平均负载为多少更合理?
理想情况下，每个 CPU 应该满负荷工作，并且没有等待进程，此时，平均负载 = CPU 逻辑核数。但是，在实际生产系统中，不建议系统满负荷运行。通用的经验法则是：平均负载 = 0.7 * CPU 逻辑核数。
- 当平均负载持续大于 0.7 * CPU 逻辑核数，就需要开始调查原因，防止系统恶化;
- 当平均负载持续大于 1.0 * CPU 逻辑核数，必须寻找解决办法，降低平均负载;
- 当平均负载持续大于 5.0 * CPU 逻辑核数，表明系统已出现严重问题，长时间未响应，或者接近死机。
CPU 使用率与平均负载的关系
CPU 使用率是单位时间内 CPU 繁忙程度的统计。而平均负载不仅包括正在使用 CPU 的进程，还包括等待 CPU 或 I/O 的进程。因此，两者不能等同，有两种常见的场景如下所述：
- CPU 密集型应用，大量进程在等待或使用 CPU，此时 CPU 使用率与平均负载呈正相关状态。
- I/O 密集型应用，大量进程在等待 I/O，此时平均负载会升高，但 CPU 使用率不一定很高。
为了更深入的理解 CPU 使用率与平均负载的关系，我们举一个例子：假设现在有一个电话亭，有 4 个人在等待打电话，电话亭同一时刻只能容纳 1 个人打电话，只有拿起电话筒才算是真正使用。那么 CPU 使用率就是拿起电话筒的时间占比，它只取决于在电话亭里的人的行为，与平均负载没有非常直接的关系。而平均负载是指在电话亭里的人加上排队的总人数，如下图所示：
如何排查用户态 CPU 使用率高
用户态 CPU 使用率反映了应用程序的繁忙程度，通常与我们自己写的代码息息相关。因此，当你在做应用发布、配置变更或性能优化时，如果想定位消耗 CPU 最多的 Java 代码，可以遵循如下思路：1、通过 top 命令找到 CPU 消耗最多的进程号;
2、通过 top -Hp 进程号 命令找到 CPU 消耗最多的线程号(列名仍然为 PID);
3、通过printf "%x\n" 线程号 命令输出该线程号对应的 16 进制数字;
4、通过 jstack 进程号 | grep 16进制线程号 -A 10 命令找到 CPU 消耗最多的线程方法堆栈。
上述方法是目前业界最常用的诊断流程，如果是非 Java 应用，可以将 jstack 替换为 perf，推荐阅读 《Perf --- Linux下的系统性能调优工具》。
然而，上述方法有两个显著缺陷，一是操作流程复杂，而且往往一次 jstack 还不足以定位根因，需要执行多次;二是只能用于诊断在线问题，如果问题已经发生，无法复现的话，往往只能不了了之。
参考：/proc/cpuinfo文件解读（超易理解） - HowOldAreYou - 博客园 (cnblogs.com)