Linux服务器变卡，记录一下一般情况处理流程

1，CPU占用过高问题定位

1.1top指令，定位问题进程

第二行统计了系统的任务状态信息。running 很自然不必多说，包括正在 CPU 上运行的和将要被调度运行的；sleeping 通常是等待事件(比如 IO 操作)完成的任务，细分可以包括 interruptible 和 uninterruptible 的类型；stopped 是一些被暂停的任务，通常发送 SIGSTOP 或者对一个前台任务操作 Ctrl-Z 可以将其暂停；zombie 僵尸任务，虽然进程终止资源会被自动回收，但是含有退出任务的 task descriptor 需要父进程访问后才能释放，这种进程显示为 defunct 状态，无论是因为父进程提前退出还是未 wait 调用，出现这种进程都应该格外注意程序是否设计有误。

第三行 CPU 占用率根据类型有以下几种情况：

(us) user：CPU 在低 nice 值(高优先级)用户态所占用的时间(nice<=0)。正常情况下只要服务器不是很闲，那么大部分的 CPU 时间应该都在此执行这类程序
(sy) system：CPU 处于内核态所占用的时间，操作系统通过系统调用(system call)从用户态陷入内核态，以执行特定的服务；通常情况下该值会比较小，但是当服务器执行的 IO 比较密集的时候，该值会比较大
(ni) nice：CPU 在高 nice 值(低优先级)用户态以低优先级运行占用的时间(nice>0)。默认新启动的进程 nice=0，是不会计入这里的，除非手动通过 renice 或者 setpriority() 的方式修改程序的nice值
(id) idle：CPU 在空闲状态(执行 kernel idle handler )所占用的时间
(wa) iowait：等待 IO 完成做占用的时间
(hi) irq：系统处理硬件中断所消耗的时间
(si) softirq：系统处理软中断所消耗的时间，记住软中断分为 softirqs、tasklets (其实是前者的特例)、work queues，不知道这里是统计的是哪些的时间，毕竟 work queues 的执行已经不是中断上下文了
(st) steal：在虚拟机情况下才有意义，因为虚拟机下 CPU 也是共享物理 CPU 的，所以这段时间表明虚拟机等待 hypervisor 调度 CPU 的时间，也意味着这段时间 hypervisor 将 CPU 调度给别的 CPU 执行，这个时段的 CPU 资源被“stolen”了。这个值在我 KVM 的 VPS 机器上是不为 0 的，但也只有 0.1 这个数量级，是不是可以用来判断 VPS 超售的情况？

CPU 占用率高很多情况下意味着一些东西，这也给服务器 CPU 使用率过高情况下指明了相应地排查思路：

当 user 占用率过高的时候，通常是某些个别的进程占用了大量的 CPU，这时候很容易通过 top 找到该程序；此时如果怀疑程序异常，可以通过 perf 等思路找出热点调用函数来进一步排查；
当 system 占用率过高的时候，如果 IO 操作(包括终端 IO)比较多，可能会造成这部分的 CPU 占用率高，比如在 file server、database server 等类型的服务器上，否则(比如>20%)很可能有些部分的内核、驱动模块有问题；
当 nice 占用率过高的时候，通常是有意行为，当进程的发起者知道某些进程占用较高的 CPU，会设置其 nice 值确保不会淹没其他进程对 CPU 的使用请求；
当 iowait 占用率过高的时候，通常意味着某些程序的 IO 操作效率很低，或者 IO 对应设备的性能很低以至于读写操作需要很长的时间来完成；
当 irq/softirq 占用率过高的时候，很可能某些外设出现问题，导致产生大量的irq请求，这时候通过检查 /proc/interrupts 文件来深究问题所在；
当 steal 占用率过高的时候，黑心厂商虚拟机超售了吧！
第四行和第五行是物理内存和虚拟内存(交换分区)的信息：
total = free + used + buff/cache，现在buffers和cached Mem信息总和到一起了，但是buffers和cached

Mem 的关系很多地方都没说清楚。其实通过对比数据，这两个值就是 /proc/meminfo 中的 Buffers 和 Cached 字段：Buffers 是针对 raw disk 的块缓存，主要是以 raw block 的方式缓存文件系统的元数据(比如超级块信息等)，这个值一般比较小(20M左右)；而 Cached 是针对于某些具体的文件进行读缓存，以增加文件的访问效率而使用的，可以说是用于文件系统中文件缓存使用。

而 avail Mem 是一个新的参数值，用于指示在不进行交换的情况下，可以给新开启的程序多少内存空间，大致和 free + buff/cached 相当，而这也印证了上面的说法，free + buffers + cached Mem才是真正可用的物理内存。并且，使用交换分区不见得是坏事情，所以交换分区使用率不是什么严重的参数，但是频繁的 swap in/out 就不是好事情了，这种情况需要注意，通常表示物理内存紧缺的情况。

最后是每个程序的资源占用列表，其中 CPU 的使用率是所有 CPU core 占用率的总和。通常执行 top 的时候，本身该程序会大量的读取 /proc 操作，所以基本该 top 程序本身也会是名列前茅的。

top 虽然非常强大，但是通常用于控制台实时监测系统信息，不适合长时间(几天、几个月)监测系统的负载信息，同时对于短命的进程也会遗漏无法给出统计信息。

1.2、定位问题线程

使用ps -mp pid -o THREAD,tid,time命令查看该进程的线程情况，假设发现该进程的多个线程占用率很高

从输出信息可以看如果%cpu下哪个进程百分比较高进行定位，假设26459和26460之间的线程CPU占用率都很高

转换成16进制

1.3 查看问题线程堆栈

再使用jstack命令打印线程堆栈信息，命令格式：jstack pid |grep tid -A 30

查看对应问题，这里是没有什么问题 。假设此线程是JVM的gc线程。此时可以基本确定是内存不足或内存泄露导致gc线程持续运行，导致CPU占用过高。
所以接下来我们要找的内存方面的问题

以下摘抄他人博客

1.4 、内存问题定位 [^1]:https://blog.csdn.net/u013991521/article/details/52781423

使用jstat -gcutil命令查看进程的内存情况

Eden区内存占用100%，Old区内存占用99.99%，Full GC的次数高达220次，并且频繁Full GC，Full GC的持续时间也特别长，平均每次Full GC耗时6.8秒（1505.439/220）。根据这些信息，基本可以确定是程序代码上出现了问题，可能存在不合理创建对象的地方