生产环境系统负载过高如何定位？
通常情况下，我们最熟悉的查看平均负载的命令可能就是uptime这个命令了
[root@node3 ~]# uptime
22:33:18 up 174 days, 6:41, 1 user, load average: 0.06, 0.36, 0.65最后3个值分别是过去1、5、15分钟内的平均负载，那么在生产环境中，当系统负载达到多少的时候需要我们特别注意呢？
个人认为当平均负载持续超过cpu数量的80%以上就代表着当前机器已经算全力在工作了，一旦系统负载过高，就会导致程序变慢，严重的甚至会产生生产事故。比如说当前8核的系统，系统负载一直维持在7以上或者更高，这个时候你就该去排查原因了，是因为故障导致需要解决呢，还是说程序本身需要的资源比较多，需要加机器呢。
接下来，我将用几个例子来为你展开当生产环境系统负载过高时，如何排查
分析工具
在进行分析之前，我需要用到两个工具stress、sysstat，来模拟一下生产环境出现问题的场景
stress
这是一个压测工具，使用它可以很容易的对系统造成各种压力，常用选项如下：
- -c, --cpu N：产生 N 个进程，每个进程都反复不停的计算随机数的平方根
- -i, --io N：产生 N 个进程，每个进程反复调用 sync() 将内存上的内容写到硬盘上
- -m, --vm N：产生 N 个进程，每个进程不断分配和释放内存 --vm-bytes B：指定分配内存的大小 --vm-stride B：不断的给部分内存赋值，让 COW(Copy On Write)发生 --vm-hang N：指示每个消耗内存的进程在分配到内存后转入睡眠状态 N 秒，然后释放内存，一直重复执行这个过程 --vm-keep：一直占用内存，区别于不断的释放和重新分配(默认是不断释放并重新分配内存)
- -d, --hadd N：产生 N 个不断执行 write 和 unlink 函数的进程(创建文件，写入内容，删除文件) --hadd-bytes B：指定文件大小
- -t, --timeout N：在 N 秒后结束程序
sysstat
这是一个Linux性能监控的工具集，本文将会使用到其中的两个工具：
- mpstat：CPU性能分析工具，可以用来查看CPU的平均指标，常用参数如下：
- -P {cpu l ALL}：表示监控哪个CPU， cpu在[0,cpu个数-1]中取值
- internal：相邻的两次采样的间隔时间
- count：采样的次数
- pidstat：实时查看进程的CPU、内存、I/O及上下文切换等性能指标，常用参数如下：
- -u：默认的参数，显示各个进程的cpu使用统计
- -r：显示各个进程的内存使用统计
- -d：显示各个进程的IO使用情况
- -p：指定进程号
- -w：显示每个进程的上下文切换情况
- -t：显示选择任务的线程的统计信息外的额外信息
你可以使用如下命令下载安装这两个工具
yum install -y epel-release
yum install -y stress
wget https://github.com/sysstat/sysstat/archive/v11.5.5.tar.gz
tar -zxvf v11.5.5.tar.gz
cd sysstat-11.5.5
./configure
make
make install
cp mpstat /usr/bin/
cp pidstat /usr/bin/案例分析
这里希望你手里能够有一台2核以上的机器能供测试使用，首先使用uptime命令观察一下当前系统的平均负载，我的系统当前值为0.06, 0.36, 0.65
cpu密集型进程
由CPU使用率过高引起的系统负载升高
我们使用stress占用一个cpu
stress --cpu 1 --timeout 600
持续观察过去一分钟的平均负载，可以发现慢慢的就会上升到1点多
watch -d uptime
接着使用mpstat工具观察一下当前cpu的占用情况
mpstat -P ALL 5
这个命令的意思是每隔5秒更新一次全部cpu的占用信息，下图也说明我们的压测工具已经生效了
接着我们就使用工具来定位出是哪个进程引起的这个系统负载过高
pidstat -u 5 1
这个命令是每5秒输出一组监控数据
i/O密集型
由iowait过高引起的系统负载升高
同上个案例，先使用压测工具模拟IO压力
stress -i 1 --timeout 600
使用uptime观察系统负载的变化
watch -d uptime
使用mpstat查看CPU使用率的变化情况
mpstat -P ALL 5
观察结果发现刚才都还是0的iowait已经上升了很多
接着再次使用pidstat定位到具体的进程
pidstat -u 5 1
大量进程
这次使用stress工具模拟8个进程持续占有CPU
stress -c 8 --timeout 600
然后使用pidstat依然可以轻松的定位到问题所在
