现网问题定位--CPU占用较高

项目场景：

此项目是我司的一个海外项目，功能类似于支付宝。

---

问题描述

项目投产后，正常的维护使用。在上周四，我们更新了微服务一个组件的包，到了周五早上，我们收到有一台服务器的CPU占用较高的告警通知。

---

原因分析：

我们收到了告警信息后，初步的排查过程如下：
1.是否是微服务出故障了？
我们通过监控平台查看了微服务的运行状态，运行状态正常；

2.是否是这个微服务节点业务处理有问题？
我们查看了日志，日志中并无相关的业务处理报错日志。
查看这个微服务相关的多个节点：这多个节点的硬件配置相同，安装的软件也相同；部署的新的组件X是从别的机器上拷贝过来的，所以问题不在软件上。

3.排查硬件
3.1CPU排查
既然CPU使用较高，我们先排查CPU，我们编写了一个python脚本，在机器上运行。
脚本如下：

通过在没有问题和有问题的机器上运行，看下执行的时间做比较，时间上基本相同，CPU的问题排除了
3.2内存排查
排查的依据：将固定大小的内存挂在到本地的一个目录上，通过内存对目录写入内容，待写入结束后，对比在没有问题和有问题的机器上运行结果。
过程如下：
（1）通过命令创建本地目录：

mkdir /tmp/tals

（2）查看本地可用内存，挂在内存到刚才创建的目录

mount -t tmpfs -o size=10g tmpfs /tmp/tbls

（3）执行通过内存写入目录内容命令：

dd if=/dev/zeor of=/tmp/tbls bs=1M count=4096 oflag=direct

（4）查看写入结果：
有问题机器：

没有问题机器：

有问题的机器，内存读写在783MB/s，没有问题的机器，内存读写再1.9GB/s

问题初步结论：

该问题非业务应用软件引起的，是由该主机配置引起的。

哈哈，到此可以甩锅出去了，不是我们应用软件的问题，你们运营人员定位去吧，非常开心！！！！！！！

后来和运营部门沟通，该问题的引起的最终原因是：虚拟机内存扩到64G后触发了NUMA bug导致cpu高，读写内存速度慢

解决方案：

虚拟主机内存扩充暂时回退，重新规划扩容。

总结：

开心 ^_^，
    经过通宵的问题定位，终于有了明确的结论，就是太费时间了，绕了一大圈，问题出现在底层上。
    这又要脑补好多知识了，NUMA。。。。。。。。。。。。。
    痛并快乐着。