cpu性能:

uptime命令中的系统平均负载:
平均负载时指的单位时间内,系统处于可运行状态和不可中断状态的平均进程数,也就是平均活跃进程数,它和CPU使用率并没有直接关系.
可运行状态的进程: 是指正在使用Cpu或者正在等待Cpu的进程,也就是我们ps命令看到的处于Runing状态的进程.
不可中断状态的进程:则是正在处于内核关键流程中的进程,并且这些流程是不可打断的,也就是ps命令查看到D状态,
所以,不可中断状态实际上是系统对进程和硬件的一种保护机制.
因此简单理解,平均负载其实就是平均活跃进程数,平均活跃进程数,直观上理解就是单位时间内的活跃进程数,但它实际上是活跃进程数的指数衰减的平均值. 既然平均的是活跃进程数，那么最理想的，就是每个 CPU 上都刚好运行着一个进程，这样每个 CPU 都得到了充分利用。
比如当平均负载为 2 时，意味着什么呢？
在只有 2 个 CPU 的系统上，意味着所有的 CPU 都刚好被完全占用。在 4 个 CPU 的系统上，意味着 CPU 有 50% 的空闲。而在只有 1 个 CPU 的系统中，则意味着有一半的进程竞争不到 CPU。

平均负载多少合适

平均负载最理想的情况是等于CPU的个数:
所以cpu的个数,可以/proc/cpuinfo中查看,所以可以判断,当负载大于cpu个数,就系统出现了过载.
同时三个时间段的值应该要合理运用:
1,如果是三个值相差不大,那就说明系统负载很平稳,
2,如果1分钟的值远远小于15分钟的值,那说明系统负载在减少,
3,反过来，如果 1 分钟的值远大于 15 分钟的值，就说明最近 1 分钟的负载在增加，这种增加有可能只是临时性的，也有可能还会持续增加下去，所以就需要持续观察。一旦 1 分钟的平均负载接近或超过了 CPU 的个数，就意味着系统正在发生过载的问题，这时就得分析调查是哪里导致的问题，并要想办法优化了。
所以在实际生产环境中,当平均负载高于cpu数量的70%的时候,就要及时进行排查问题了,

平均负载和CPU使用率:

平均负载是单位时间内处于运行状态和不可中断状态,所以是有两个部分,一部分是正在使用,一部分是等待cpu和等待io操作的,.
而cpu的使用率,是单位时间cpu的繁忙程度,是当前正在使用cpu的进程,
所以两者还是有很大区别的.
所以: 如果是对于cpu密集型,使用大量的cpu会导致平均负载升高,此时两者是一致的.
如果是io密集型,等待io升高,但此时cpu使用率不一定很高
大量等待 CPU 的进程调度也会导致平均负载升高，此时的 CPU 使用率也会比较高。
所以,对于平均负载: 是提供了一个快速查看系统的整体性能的手段,反映了整体负载的情况,但是只看平均负载本省,并不能直接发现问题,所以:
需要注意:平均负载高也有可能是cpu密集型导致的,
平均负载高并不一定代表cpu的使用率高,还有可能是io更繁忙了,
合理使用mpstat ,pidstat 等各种工具,进行性能的分析,

cpu的上下文切换:

多进程争抢cpu导致系统负载升高,主要原因就是CPU的上下文切换了.
因为是多任务同时进行.而在每个任务运行前，CPU 都需要知道任务从哪里加载、又从哪里开始运行，也就是说，需要系统事先帮它设置好 CPU 寄存器和程序计数器（Program Counter，PC）。
CPU寄存器,是cpu内置的容量小,但速度极快的内存,而程序计数器,则是用来存储cpu正在执行的指令位置,或者将要执行的下一条命令,他们都是cpu在运行任何任务前,必须依赖的环境,因此被叫做cpu上下文.
所以cpu上下文切换: 就是把先前的一个任务的cpu上下文保存起来,然后加载新任务的上下文到这些寄存器和程序计数器中,最后再跳转到程序计数器所指定的新位置,运行任务.

系统管理的任务主要是:进程,线程和硬件发送的信号,会导致终端处理程序的调用,也是常见的任务.
所以根据任务不同,cpu的上下文切换分为几个场景:
1,也就是进程上下文件切换,
2,线程上下文切换
3,中断上下文切换,

进程上下文切换:

linxu按照特权等级,把进程的运行空间,分为内核空间和用户空间,
1,内核空间具有最高的权限,可以直接访问所有资源
2,用户空间,只能访问受限资源,不能直接访问内存等设备,必须通过系统调用陷入到内核中,才能进行特权的访问,
从用户态到内核态的转变,需要通过系统调用来实现完成:
切换的过程: cpu寄存器原来的用户态指令位置保存起来,然后执行内核态代码,cpu寄存器更新内核态指令的位置,最后才是进入到内核态运行内核任务,而当系统调用结束后,cpu寄存器需要恢复原来保存的用户态,然后再切换回用户态,继续运行下面的程序,.
所以一次系统调用过程中发生了两次cpu上下文切换
不过，需要注意的是，系统调用过程中，并不会涉及到虚拟内存等进程用户态的资源，也不会切换进程。这跟我们通常所说的进程上下文切换是不一样的：
进程上下文的切换,是指从一个进程切换到另一个进程运行,而系统调用则是一直都是一个进程在运行
所以,系统调用过程通常称为特权模式切换,而不是上下文切换,但实际上,系统调用过程中,cpu的上下文切换是无法避免的.
进程上下文切换和系统调用的区别:
1,进程是由内核管理调度,进行的切换只能发生在内核态,所以进程上下文不仅包括了虚拟内存,栈,全局变量,等用户空间内容资源,还包括了内核堆栈,寄存器等内核空间的状态.
因此,进程的上下文切换比系统调用时多了一步,在保存当前进程的内核状态和cpu寄存器之前,需要把该进程的虚拟内存,栈等保存下来,而加载了下一进程内核态后,还需要刷新进程的虚拟内存和用户栈.
根据 Tsuna 的测试报告，每次上下文切换都需要几十纳秒到数微秒的 CPU 时间。这个时间还是相当可观的，特别是在进程上下文切换次数较多的情况下，很容易导致 CPU 将大量时间耗费在寄存器、内核栈以及虚拟内存等资源的保存和恢复上，进而大大缩短了真正运行进程的时间。这也正是上一节中我们所讲的，导致平均负载升高的一个重要因素。

另外.Linux通过TLB来管理虚拟内存物理内存的映射关系,当虚拟内存更新后,TLB也需要刷新,内存访问变慢.所以会影响处理器的速度.

发生切换进程的上下文的时间
只有在进程调度的时候,Linux为每个cpu都维护了一个就绪队列,将活跃的金层,按照优先级和等待cpu的时间排序,然后选择最需要的,来进行运行.
进程在什么时候才会被调度到 CPU 上运行呢？

1. 对应进程的cpu时间片被用完了,就会被挂起,然后从队列中拿到新的进程.
2. 进程需要的资源不被满足,就会挂起,调度其他进程进行运行
3. 当进程通过睡眠函数,强制挂起,从新调度
4. 更高的优先级进程,当前的被挂起
5. 发生硬件中断的时候,cpu的进程会被挂起,转而执行内核中的中断服务程序,

线程上下文切换
线程和进程的最大区别在于,线程是调度的基本单位,而进程则是资源拥有的基本单位,
所以,内核中的任务调度,实际上就是调度对象是线程,而进程只是给线程提供了虚拟内存,全局变量等资源,
所以对于线程和进程理解:

1. 当进程只是有一个线程的时候,就认为该进程等于线程
2. 当进程拥有对个线程,这些线程就会共享相同的虚拟内存和全局变量等资源,这些资源在上下文切换的时候是不需要修改的.
3. 另外,线程也有自己的私有数据,比如栈和寄存器,这些在上下文切换的时候也是需要保存的

---

所以线程的上下文切换就有两种情况:

• 前后两个线程属于不同进程,此时的资源不同享,所以切换线程和进程切换相同,
• 属于同一个线程,因此虚拟内存是共享的,所在虚拟内存这些资源保持不同,只需要切换私有数据,寄存器等不共享的数据,

中断上下文切换

为了快速响应硬件事件,中断处理会打断进程的正常调度和执行,
跟进程上下文不同,中断上下文切换并不涉及到进程的用户态,所以，即便中断过程打断了一个正处在用户态的进程，也不需要保存和恢复这个进程的虚拟内存、全局变量等用户态资源。
中断上下文, 其实只包括了内核态中断服务程序执行所必需的状态,包括了cpu寄存器,内核堆栈,硬件中断参数.

对同一个cpu来说,中断处理比进程拥有更高的优先级,所以中断上下文切换不会和进程上下文切换同时发生,所以中断上下文切换也是会消耗cpu性能.

查看系统的上下文切换情况

1,vmstat命令: 查看总体系统切换的一个状态.

# 每隔5秒输出1组数据
$ vmstat 5
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
 0  0      0 7005360  91564 818900    0    0     0     0   25   33  0  0 100  0  0

针对上下文切换需要注意下面几列内容:

1. cs(context switch) 是每秒上下文切换的次数,
2. in(interrupt)则是每秒中断的次数
3. r继续队列的长度,也就是正在等待运行和等待cpu的进程数.
4. b则是处于不可中断睡眠的状态的进程数.

pidstat -w命令查看每个进程的上下文切换:

# 每隔5秒输出1组数据
$ pidstat -w 5
Linux 4.15.0 (ubuntu)  09/23/18  _x86_64_  (2 CPU)

08:18:26      UID       PID   cswch/s nvcswch/s  Command
08:18:31        0         1      0.20      0.00  systemd
08:18:31        0         8      5.40      0.00  rcu_sched
...

其中需要重点关注:
cswch/s:表示每秒自愿上下文切换的次数,是指进程无法获取到所需要的资源,导致的上下文的切换,比如io,内存不足

nvcswch/s:表示非资源上下文切换的次数,值进程由于时间片已用尽,被系统强制调度,进行发生上下文切换.
每秒上下文切换多少次才算正常呢？
这主要是取决于系统本身的cpu性能,还需要根据上下文切换类型进行具体分析:

• 自愿上下文变多,说明进程在等待资源,有可能发生了io/等其他问题.
• 非自愿的上下文切换变多了,说明进程都在被强制调度,也就是都在争抢cpu,
• 中断次数变多了,说明cpu被中断处理程序占用了,还需要通过查看/proc/interrupts文件来分析具体的中断类型.

CPU使用率

为了维护cpu时间,Linux通过事先定义的节拍率,触发时间中断,并使用全局变量JIFFIES记录开机以来的节拍数,每发生一次时间中断,jiffies的值就加1.可以通过 /boot/config内核选项来查看它的配置值.
同时，正因为节拍率 HZ 是内核选项，所以用户空间程序并不能直接访问。为了方便用户空间程序，内核还提供了一个用户空间节拍率 USER_HZ，它总是固定为 100，也就是 1/100 秒。这样，用户空间程序并不需要关心内核中 HZ 被设置成了多少，因为它看到的总是固定值 USER_HZ。
对于 /proc/stat 提供的就是系统cpu和任务统计信息.

与cpu使用率相关的重要指标:

1.user(us) :是用户态cpu时间,注意,他不包含下面的nice时间,但包括了guest的时间.
2,nice(ni): 低优先级用户态cpu时间,nice的值越大优先级越低
3,system(sys): 代表内核态cpu时间,
4.idle(id): 表示空闲时间,不包括等待io的时间
5,irq(hi): 代表处理硬中断的cpu时间
6,iowait(wa) 代表等待io的cpu时间.
7,softtirq(si): 代表处理软中断的cpu时间,
8,steal(st): 代表当系统运行在虚拟机中的时候,被其他虚拟机占用的cpu时间
9,guest(guest): 代表通过虚拟化运行其他操作系统的时间,也就是运行虚拟机的cpu时间,
10,guest_nice(gnice),代表以低优先级运行虚拟机的时间.

我们通常所说的cpu使用率:
就是处过空闲时间外的其他时间占总的cpu时间的百分比
所以,一般情况下参考的都是:
一段时间内的cpu使用率"
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-llRS7DSo-1669110424225)(2022-10-28-17-50-56.png)]
各种各样的性能分析工具已经帮我们计算好了。不过要注意的是，性能分析工具给出的都是间隔一段时间的平均 CPU 使用率，所以要注意间隔时间的设置，特别是用多个工具对比分析时，你一定要保证它们用的是相同的间隔时间。

cpu使用率过高的处理方式:

1,采用pref工具,内置性能工具,性能事件采样为基础,不仅可以分析系统的各种事件和内核性能,还可以用来分析制定应用程序的性能问题
常见用法: perf top 类似top命令,能够实时的显示出占用的cpu时钟最多的函数或者指令,因此被用来查找热点函数,但不能保存数据是实时的.
2,使用perf record
这个可以保存数据,用于后续分析.
在遇到cpu性能问题排查思路
首先是要清楚各个指标含义,
比如用户cpu和nice cpu高了,说明用户进程占用了太多cpu,所以应该着重排查进程性能的问题.
系统cpu高了,说明内核态占用了较多的cpu,所以应该着重排查内核线程或系统调用的性能问题.
io等待cpu高,说明等待io时间比较长,所以排查io问题,
软中断和硬中断高,说明软中断或硬中断的处理程序占用了较多的cpu,所以应该重排查内核中的中断服务程序.

cpu案例排查

根据Linux性能文章6,梳理:
1,案例测试: 使用ab工具对nginx的php服务进行压测
服务运行成功之后,执行压测命令,观察输出结果:

# 并发100个请求测试Nginx性能，总共测试1000个请求
$ ab -c 100 -n 1000 http://192.168.0.10:10000/
This is ApacheBench, Version 2.3 <$Revision: 1706008 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, 
...
Requests per second:    87.86 [#/sec] (mean)
Time per request:       1138.229 [ms] (mean)
...

这里可以看到nginx能承受的每秒的平均请求量是87多,开始排查性能问题,为了让测试能一直持续,将命令改变一下:
ab -c 5 -t 600 http://192.168.0.10:10000/ 对于案例总结一下排查过程和思路:
1,通过top命令,查看各个指标信息,发展是哪个资源的紧张导致性能的下降.
2排查对于该资源占用高德进程,使用pidstat观察.
3,对于当前运行的主要进程进行排查,在top命令中running状态的进程重点排查.
4,使用pidstat -p pid或者是ps aux | grep pid 查看该进程的详细占用信息.
5,如果该进程查不到信息,或者该进程一直是刷新重启,或者pid一直变化,考虑以下原因: 1,进程在不断的奔溃重启, 2,进程都是短进程,运行很短时间就结束了,top刷新间隔捕捉不到.
6,针对这种情况就要去找他对应的父进程,通过pstree命令,找到对应的父进程.
7,找到父进程观察他对子进程的创建情况,分析源码,知道对于子进程创建的方式和代码逻辑.
8,对可疑点进行一一排查测试,将这个代码拉起测试,观察资源变化情况使用perf工具,对性能事件进行记录,定位到函数上.
9,确定问题后,对代码层面进行调试,直至找到哪一行代码的bug引起的.
对于蹦到常规问题无法解释cpu使用率的情况时,首先要想到的就是短时间应用导致的问题,比如下面的情况:
应用里面直接调用了其他二进程程序,通常时间很短,top命令工具难以发现
应用本身不断的重启,而启动过程资源初始化占用大量cpu
推荐工具: execsnoop 找到它们的父进程，再从父进程所在的应用入手，排查问题的根源。

进程的状态

1. R --是 Running 或 Runnable 的缩写，表示进程在 CPU 的就绪队列中，正在运行或者正在等待运行。
2. D --Disk sleep的缩写,也就是不可中断睡眠,一般表示该进程正在跟硬件交互,并且交互不允许被其他进程中断或打断.
3. Z 是zombie的缩写,僵尸进程(父进程没有及时回收资源)
4. S 可中断睡眠状态,表示进程因为等待某个事件,而被系统挂起,当进程等待事件的发生时,它就被唤醒并进入了R状态.
5. I是idle的缩写,也就是空闲状态,用在不可中断的睡眠内核线程上,但对于内核线程来说,他们可能实际上并没有任何负载,用ldle这正是为了区分这种情况,注意,D状态的进程会导致平均负载升高,而I状态不会.
6. T状态,也就是Stoop或Traced的缩写,表示进程处于暂停或者跟踪的状态. 向一个进程发送 SIGSTOP 信号，它就会因响应这个信号变成暂停状态（Stopped）；再向它发送 SIGCONT 信号，进程又会恢复运行（如果进程是终端里直接启动的，则需要你用 fg 命令，恢复到前台运行）
7. X状态,Dead状态,表示进程已经消亡.

短时间的不可中断状态不用关心,但如果是系统或硬件发生了故障了,进程可能会在不可中断状态持续很久,甚至导致系统中出现大量不可中断进程。这时，你就得注意下，系统是不是出现了 I/O 等性能问题。
再看僵尸进程: 这是多进程应用很容易碰到的问题,正常的情况下,当一个进程创建了子进程后,它应该通过调用wait()或者waitpid()等待子进程结束后,回收掉子进程的资源,而子进程在结束时,会向父进程发送一个slgchld信号,所以父进程还可以注册slgchid信号的处理函数,一步回收资源.
但如果父进程没这么做,或没来及处理,就会导致僵尸进程的产生.大量的僵尸进程会占用pid号,导致新的进程不能被创建,所以需要及时排查.

进程组: 表示一组相互关联的进程,比如父子进程
会话: 会话是指共享同一个控制终端的一个或多个进程组.
案例分析:
现象: top命令中展示出,1分钟内的平均负载数已经等于了cpu数量, 僵尸进程数过多, iowait数值太高,有两个进程处于D状态.
1,排查iowait太高原因:
1通过dstat工具,进行io情况的观察,发现对磁盘的操作是什么,对应的数据量是什么
2.top命令中的两个D进程进行详解观测,使用pidstat命令,同时知道那个进程对磁盘的使用占用多 ,
3,因为进程想要访问磁盘,就得使用系统调用,所以通过strace命令去跟踪进程系统调用工具,或者是用perf record -g 将动态追踪记录下来,仔细分析找到进程的io调度…
4确认进程是io有大量的操作,然后开始从源码进行分析,对源码进行修改.
这对僵尸进程的处理方式:
僵尸进程的产生主要是于父进程有关,所以通过pstree命令找到对应的父进程,然后再父进程中找处理子进程的函数,wait()或waitpid(),

虽然这个案例是磁盘 I/O 导致了 iowait 升高，不过， iowait 高不一定代表 I/O 有性能瓶颈。当系统中只有 I/O 类型的进程在运行时，iowait 也会很高，但实际上，磁盘的读写远没有达到性能瓶颈的程度。因此，碰到 iowait 升高时，需要先用 dstat、pidstat 等工具，确认是不是磁盘 I/O 的问题，然后再找是哪些进程导致了 I/O。等待 I/O 的进程一般是不可中断状态，所以用 ps 命令找到的 D 状态（即不可中断状态）的进程，多为可疑进程。但这个案例中，在 I/O 操作后，进程又变成了僵尸进程，所以不能用 strace 直接分析这个进程的系统调用。

软中断

中断是系统用来响应硬件设备请求的一种机制，它会打断进程的正常调度和执行，然后调用内核中的中断处理程序来响应设备的请求。
中断其实就是一种异步的事件处理机制,可以提高系统的并发处理能力,
由于中断处理程序会打断其他进程的运行,所以为了减少对正常进程运行调度的影响,中断处理程序就需要快速的运行.
特别是: 中断处理程序在响应中断时,会临时关闭中断,这就会导致上一次的中断处理完成之前,其他中断都不能响应,也就是说中断有可能会丢失.这里接受了中断处理,对其他中断的响应信号就有可能接受不到,丢失.
所以,针对Linux将中断处理过程中分成了两个阶段,也就是上下部分.
上半部分用来快速处理中断,它在中断禁止模式下运行,主要处理硬件紧密相关的或时间敏感的工作
下半部分来延迟处理上半部分未完成的工作,通过以内核线程的方式运行.
所以总结下来:
上半部分直接处理硬件请求,也就是我们常说的硬中断,特点是快速执行
而下半部分则是由内核触发,也就是我们常说的软中断,特点是延迟执行
实际上，上半部会打断 CPU 正在执行的任务，然后立即执行中断处理程序。而下半部以内核线程的方式执行，并且每个 CPU 都对应一个软中断内核线程，名字为 “ksoftirqd/CPU 编号”，比如说， 0 号 CPU 对应的软中断内核线程的名字就是 ksoftirqd/0。不过要注意的是，软中断不只包括了刚刚所讲的硬件设备中断处理程序的下半部，一些内核自定义的事件也属于软中断，比如内核调度和 RCU 锁（Read-Copy Update 的缩写，RCU 是 Linux 内核中最常用的锁之一）等
其中 /proc/softirqs 提供了软中断的运行情况,
/proc/interrupts 提供了硬中断的运行情况.

软中断实际上都是以内核线程的方式运行的,每个cpu的都对应一个软中断内核线程,这个软件中断线程就是: ksoftirqd/cpu编号,.通过ps命令可以查看:

$ ps aux | grep softirq
root         7  0.0  0.0      0     0 ?        S    Oct10   0:01 [ksoftirqd/0]
root        16  0.0  0.0      0     0 ?        S    Oct10   0:01 [ksoftirqd/1]

一般来说,ps的输出中,名称括在中括号内部的,一般都是内核线程.
通过软中断有很多的类型比如:网络收发,定时,调度,rcu等锁的类型.
####软中断案例:
1,通过发现系统性能变慢,然后发现异常进行排查,使用top命令,来仔细观察每一列的使用情况.
2,通过找到top的cpu使用率高一点的是si这一行,然后找到对应占用cpu使用率较高的进程发现,软中断进程 ksoftirqd
3,查找判断软中断类型,通过/proc/softirqs文件,判断各种软中断类型次数,因为我们需要查看实时变化情况,所以中断次数的变化率才是我们需要关注的,使用watch -d cat /proc/softirqs 命令查看.找到其中变化率最高的几项,
然后一一排查,定位到最高变化速率的一项,确认软中断的类型,使用对应工具进行判断,
4,这里采用sar工具,针对网络类型的软中断进行排查,通过sar工具定位出是哪一个网卡,那种状态下的导致的.确认网络类型.
5,确认了网络发送类型和数据大小,接下来就需要使用网络抓包工具,进行网络抓包分析.
6根据网卡,协议类型进行抓包分析,抓取网络数据报文:

# -i eth0 只抓取eth0网卡，-n不解析协议名和主机名
# tcp port 80表示只抓取tcp协议并且端口号为80的网络帧
$ tcpdump -i eth0 -n tcp port 80
15:11:32.678966 IP 192.168.0.2.18238 > 192.168.0.30.80: Flags [S], seq 458303614, win 512, length 0
...

这里,FLags[S]表示这是一个syn包,在结合sar分析出的接受包量,就可以确定是发生了syn的FLOOD攻击.
这里针对最简单的解决方法便是,就是从交换机或防火墙将ip封禁.
软中断 CPU 使用率（softirq）升高是一种很常见的性能问题。虽然软中断的类型很多，但实际生产中，我们遇到的性能瓶颈大多是网络收发类型的软中断，特别是网络接收的软中断。

分析系统cpu的瓶颈

主要分析的cpu指标

1,cpu使用率

1,cpu使用率描述了非空闲时间占总的cpu的时间占用百分比,根据 CPU 上运行任务的不同，又被分为用户 CPU、系统 CPU、等待 I/O CPU、软中断和硬中断等。还有表示虚拟环境会用到的窃取cpu的使用率,(steal)和客户使用率(guest)
分别表示被其他虚拟机占用的cpu的时间百分比,和运行客户虚拟机的cpu时间百分比.

2,平均负载

需要观察这三个数值的一个变化,短时间的变化就需要特别进行注意.

3,上下文切换

包括: 1,无法获取到系统资源而导致的自愿上下文切换, 2,被系统强制调度导致的非自愿的上下文切换.

4cpu缓存的命中率

cpu缓存命中率越高,表示性能越好.
分析cpu性能使用的工具:
uptime,mpstat ,pidstat ,vmstat ,top,perf top ,dstat,sar,tcpdump
压测工具: sysbench,
[

快速分析cpu性能瓶颈

工具的使用,以及回显指标都有很清楚:
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-tP49qdBz-1669110424229)(2022-11-01-10-50-07.png)]
案例处理思路:
top 输出的平均负载升高，可以跟 vmstat 输出的运行状态和不可中断状态的进程数做对比，观察是哪种进程导致的负载升高。
如果是不可中断进程数增多了，那么就需要做 I/O 的分析，也就是用 dstat 或 sar 等工具，进一步分析 I/O 的情况。
如果是运行状态进程数增多了，那就需要回到 top 和 pidstat，找出这些处于运行状态的到底是什么进程，然后再用进程分析工具，做进一步分析。

性能优化的思路

性能优化的方法论:
首先，既然要做性能优化，那要怎么判断它是不是有效呢？特别是优化后，到底能提升多少性能呢？
第二，性能问题通常不是独立的，如果有多个性能问题同时发生，你应该先优化哪一个呢？
第三，提升性能的方法并不是唯一的，当有多种方法可以选择时，你会选用哪一种呢？
是不是总选那个最大程度提升性能的方法就行了呢？

评估优化效果:

评估的方式采用三步走方式:
1,确定性能的量化指标
2,测试优化前的性能指标
3,测试优化后的性能指标
对于确定性能量化指标是不能局限于一个维度,需要从程序和系统资源或业务利用率等多个方面进行评估.
针对这些指定几项优化项和标准,
性能测试:
性能测试需要严谨,且最好采用不同的工具之间进行交叉验证.
注意: 1,要避免性能压测工具或监控工具本身对系统程序的影响.
2,避免外部环境的变化影响性能指标的评估,
多个性能问题同时存在,要怎么选择,总结一条找到最关键的问题,并不是所有问题都值得优化
按照前面的思路进行排查,找到优化后能够最大提升性能的关键问题
第一，如果发现是系统资源达到了瓶颈，比如 CPU 使用率达到了 100%，那么首先优化的一定是系统资源使用问题。完成系统资源瓶颈的优化后，我们才要考虑其他问题。第二，针对不同类型的指标，首先去优化那些由瓶颈导致的，性能指标变化幅度最大的问题。比如产生瓶颈后，用户 CPU 使用率升高了 10%，而系统 CPU 使用率却升高了 50%，这个时候就应该首先优化系统 CPU 的使用。
对于有多种优化方法,如何选择:

cpu优化:

应用程序优化:
1,编译器优化
2,算法优化
3,异步处理
4,多线程代替多进程
5,善用缓存,
系统优化
1,cpu绑定: 把进程绑定到一个或者多个cpu上,可以提高cpu缓存的命中率,减少跨cpu带来的上下文切换问题.
2,cpu独占: 不允许其他进程再来使用这些 CPU。
3,优先级的调整
4,为进程设置资源限制
5,NUMA（Non-Uniform Memory Access）优化：支持 NUMA 的处理器会被划分为多个 node，每个 node 都有自己的本地内存空间。NUMA 优化，其实就是让 CPU 尽可能只访问本地内存
6,中断负载均衡: 开启 irqbalance 服务或者配置 smp_affinity，就可以把中断处理过程自动负载均衡到多个 CPU 上。