linux性能优化心得
本文以 极客时间 倪鹏飞老师的专栏为基础进行的编写心得、由于本人水平有限,如果有什么不妥的地方,还请各位批评指正。
一、平均负载的重要性
常用两个观察平均负载的命令
top
top - 16:30:18 up 44 days, 21:45, 2 users, load average: 0.42, 0.39, 0.32
Tasks: 126 total, 1 running, 125 sleeping, 0 stopped, 0 zombie
%Cpu0 : 8.4 us, 2.7 sy, 0.0 ni, 88.6 id, 0.0 wa, 0.0 hi, 0.3 si, 0.0 st
%Cpu1 : 6.1 us, 2.0 sy, 0.0 ni, 91.6 id, 0.0 wa, 0.0 hi, 0.3 si, 0.0 st
%Cpu2 : 8.4 us, 2.7 sy, 0.0 ni, 88.5 id, 0.0 wa, 0.0 hi, 0.3 si, 0.0 st
%Cpu3 : 6.1 us, 2.0 sy, 0.0 ni, 91.9 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st
KiB Mem : 8008880 total, 199208 free, 2657448 used, 5152224 buff/cache
KiB Swap: 0 total, 0 free, 0 used. 5013796 avail Memuptime
[root@usercenter-1 ~]# uptime
16:30:36 up 44 days, 21:45, 2 users, load average: 0.41, 0.39, 0.321.1 概念
平均负载是指单位时间内，系统处于可运行状态和不可中断状态的平均进程数，也就是平均活跃进程数，它和 CPU 使用率并没有直接关系。
1.2 平均负载三个时间点
1分钟 5分钟 15分钟
load average: 0.41, 0.39, 0.321.3 什么是最理想的平均负载？
1、得出系统CPU数量 /proc/cpuinfo
# 关于 grep 和 wc 的用法请查询它们的手册或者网络搜索
$ grep 'model name' /proc/cpuinfo | wc -l2、负载情况
根据时间不一样 三个不同的平均负载的值 其反应负载就是三个时间点负载情况
3、理论值
整体使用资源最合理，就是一个CPU 平均负载为1！
如：4个CPU 平均负载为4 最为完美
4、实际值
在应用程序部署（进程运行中）
个人觉得的在合理充分的压测应用系统下 得出来的平均负载最为合理，所以不同应用 平均负载不一致 但这个值肯定理由接近理论值。
1.4 跟CPU使用率的关系
cpu密集型进程，使用大量CPU会导致平均负载升高，跟平均负载一到
I/O密集型进程，等待I/O也会导致平均负载升高，但CPU使用率不一定会很高
大量等待CPU的进程调度也会导致平均负载升高，此时CPU使用率也会比较高
1.5 总结
平均负载产生的意义，快速查看整个系统整体性能手段，反映整体的负载情况。
日常工作中 可以以这个负载做为一个快速发生系统是否有负载问题的指标，另外可以以监控的方式覆盖 CPU报警，当然监控越细越好，不同的负载
1.6 推荐命令工具
stress 用来模拟 Linux 系统压测工具
mpstat pidstat 用来进程分析
watch -d二、CPU 上下文切换
2.1 CPU上下文切换产生？什么情况下会触发
多任务竞争CPU产生了CPU上下文切换的情况。
系统调用、进程状态转换(运行、就绪、阻塞)、时间片耗尽（CPU节拍数）、系统资源不足、sleep、优先级调度、硬件中断等！
2.2 上下文切换的过程(浓缩版)
- 记录当前值
- 找到新任务的上下文并加载
- 新任务结束，并恢复到目前位置
2.3 上下文切大致可分为三类
1、进程上下文切换
2、线程上下文切换
3、中断上下文切换
2.4 切换耗资源程度且关注点
进程是资源分配的最小单位，线程是任务调度执行的最小单位，每个进程都有一个主线程。另外，当进程只有一个线程的时候 大家可以理解就是线程切换
根据 Tsuna 的测试报告，每次上下文切换都需要几十纳秒到数微秒的CPU时间，所以优化这个切换非常重要。
线程切换比进程切换消耗小，主要原因是线程中切换 在一个进程中全局虚拟内存不变。
在同一个CPU来说，中断处理比进程拥有更高的优先级，所以中断上下文切换并不会与进程上下文切换同时发生。
2.5 排查上下文切换情况
1、vmstat
vmstat 1 5
关注四列结果
r (Running or Runnable) 正在运行和等待CPU进程数
b (Blocked) 处于不可中睡眠状态的进程数
cs (context switch) 每秒上下文切换
in (interrupt) 每秒的中断的次数2、pidstat （默认显示进程的指标数据 所以一下要把线程带上）
自愿上下文切换
非自愿上下文切换
主要区别原因在于 时间片耗尽（CPU节拍数）、系统资源不足为自愿。
pidstat -wt -u 1 3、关注 /proc/interrupts
watch -d cat /proc/interrupts三 CPU 使用100%的时候 你可以怎么操作
1、CPU 使用率是单位时间内 CPU 使用情况的统计
%user、%nice、 %system、%iowait2、cpu 维护是通过节拍率
3、节拍率是内核运行的
用户空间节拍率( USER_HZ)是一个固定设置
grep 'CONFIG_HZ=' /boot/config-$(uname -r)
4、/proc/stat 提供就是系统的CPU和任务统计信息
/proc/[pid]/stat展示进程的CPU和任务统计信息
5、cpu的使用率
cpu的使用率={1-(idle_time/total_cpu_time)}/sample_time
6、性能工具给出时间频率
top默认为3s，ps使用的是进程运行时间
7、top vmstat mpstat 等命令关于cpu性能相关指标的含义
8、pidstat 命令含义
9、perf
使用说明
perf top -g -p <mysqlpid>
perf record
perf top
列说明
Overhead
Shard
Object
动态共享对象类型
[.]
用户可执行程序、动态链接库
[k]
内核空间
Symbol
函数名 如果出现未知 16进制说明
10、测试工具ab
ab -c 10 -n 10 http://www.xx.cn/
系统CPU使用率很高，但为啥找不到高的CPU应用
课前
安装pstress yum install psmisc
在怀疑性能工具出问题前，最好还是先用其他工具交叉确认一下
实验过程
查看运行的时间情况：通过top
分析运行中的PID
pidstat -p <pid>
ps aux | grep <pid>重新查看top 情况
pstree 通过pstree 树状形式显示所有进程关系
pstree | grep <pidname> :pstree | grep nginx
找出父进程 然后在分析
可以进一步 在代码层模拟实现问题
perf report 查看报告
perf record -g
perf reportexecsnoop
git
小结
碰到常规问题无法解释的 CPU 使用率情况时，首先要想到有可能有两种情况
应用里直接调用了其他二进制程序，这些程序通常运行时间比较短，通过top等工具发现不了
应用本身在不停地崩溃重启，而启动过程的资源初始化，很可能会占用很多CPU资源
系统中出现的可中断进程和僵尸进程查看
top / ps 查看进程状态
R / Running Runnable
运行或者排队
D / Disk Sleep
不可中断状态睡眠
Z / Zombie
僵尸进程
S / Interruptible Sleep
可中断状态睡眠
I / Idle
空闲状态
T t / Stopped Traced
进程处于暂停或者 跟踪状态
X
Dead 进程已经消亡 快速消亡特别注意两个点
s
进程是一个会话的领导进程
进程组表示 一组相互关联的进程，
+
前台进程组
僵尸进程产生原因
（1）父子进程的运行是异步的过程，父进程需要知道子进程是何时关闭的
（2）子进程需要父进程来收尸，但父进程没有安装SIGCHLD信号处理函数调用wait或waitpid（）等待子进程结束，或是子进程执行太快，父进程还没来得及处理子进程状态
（3）父进程退出后，init进程会自动接手子进程，进行清理
（4）僵尸进程已经放弃了几乎所有内存空间，没有任何可执行代码，也不能被调度，仅仅在进程列表中保留一个位置，记载该进程的退出状态等信息供其他进程收集
（5）大量的僵尸进程会用尽 PID 进程号，导致新进程不能创建
运维这边学习的心得和体会。
1、对CPU有更好的认识及领悟
2、合理的利用CPU资源，合理的进行应用程序进行压测
腾讯云开发者
