大家好，又见面了，我是你们的朋友全栈君。如果您正在找激活码,请点击查看最新教程,关注关注公众号 “全栈程序员社区” 获取激活教程,可能之前旧版本教程已经失效.最新Idea2022.1教程亲测有效,一键激活。
Jetbrains全系列IDE使用 1年只要46元 售后保障 童叟无欺
服务器内核有个调度器，其负责调度两种资源（线程，中断）。调度器针对不同的资源有不同的优先级，下面三个优先级从高到低依次如下：
- 中断：设备完成操作后通知内核，例如硬件设备受到一个IO请求
- 系统进程：所有内核操作都在这个级别
- 用户进程：这些进程一般都运行在用户空间中，其在调度器中优先级比较低
下面分别详细介绍一些关键概念
一，关键概念
1，Context Switches（上下文切换）
现在的CPU大部分在同一颗核上同时只能跑一个线程，就算超线程处理器，微观上看同一时刻也只是跑一个线程。Linux内核看每颗CPU处理器都是独立处理器。一个Linux内核同时可以调度50-50000个线程。在每颗处理器中调度器都需要调度线程合理的使用CPU。每个线程分配了一个时间片的时间使用CPU，一旦时间片用完了或者高优先级资源（例如中断）需要占用CPU，该线程就会放回到调度队列中让高优先级资源使用CPU。这样的线程切换就是所谓的Context Switch（上下文切换）。每发生一次上下文切换资源就会从CPU的使用中挪到调度队列中。一个系统单位之间内上下文切换的次数越多，表明内核进行的工作越繁忙。
2，The run Queue（运行队列）
每个CPU都维护了一个运行队列，理想来讲调度器会一直处于运行和执行线程，这些线程不是处于运行状态就是休眠状态（等待IO或者阻塞）。如果CPU子系统的使用率非常高的情况下，内核调度程序可能跟不上系统的需要。会导致运行队列越来越大，同时一些可运行的线程一直得不到调度。
下面说明下load的概念：
load经常用来描述运行队列的状况。其含义是正在执行的线程个数与运行队列中线程个数的和。例如一个双核系统，现在有两个线程在执行，有4个线程在运行队列。
所以此时load为6。Linux提供了最近1min，5min，15min的统计。
3，CPU的使用率
CPU的使用率是指CPU使用百分比，该指标是系统CPU使用情况重要指标。大部分监控工具提供了如下四个维度的监控
- User Time（用户时间）：用户空间中的用户态线程使用CPU耗时占整个时间段比例
- System Time（系统时间）：系统线程（or 进程）使用CPU耗时占整个时间段比例
- Wait IO：因为等待IO请求空闲时间占整个时间段比例
- Idle：完全空闲时间占比
二，CPU监控
2.1，健康状态下CPU基准线
- 单核CPU，load不超过3个task。一般线上机器单核load超过1.5就该引起注意了。
- User Time不超过65%-70%
- System Time不超过30%
- 一般线上情况CPU使用率到80%，就应该加机器，或者想办法优化了。
- 上线文切换直接相关CPU的使用程度
2.2，vmstat使用
2.2.1 使用办法
vmstat {采样时间间隔,单位为秒}
vmstat 1
procs -----------memory---------- ---swap-- -----io---- -system-- ----cpu----
r b swpd free buff cache si so bi bo in cs us sy id wa
2 0 181124 150552 7404 606060 0 0 380 185 0 0 47 1 50 1
1 0 181124 149496 7412 606736 0 0 229 17 1245 1757 25 1 73 0
1 0 181124 148552 7420 607564 0 0 280 39 1331 1858 26 1 72 1
1 0 181124 145484 7428 610820 0 0 1053 23 1161 1728 24 1 73 1
|
下面只解释CPU相关的列
|
各列名称
|
含义
|
备注
|
|---|---|---|
| r | 运行队列中任务数（线程数） | |
| b | 被阻塞或者等待IO请求的线程数 | |
in |
interrupte：处理的中断数 | |
| cs | context switches：上下文切换数 | |
| us | user time:用户进程消耗时间比 | |
| sy | system time:系统进程消耗时间比 | |
| id | idle：空间时间比 |
2.2.2 Case分析
case1：
# vmstat 1
procs memory swap io system cpu
r b swpd free buff cache si so bi bo in cs us sy wa id
3 0 206564 15092 80336 176080 0 0 0 0 718 26 81 19 0 0
2 0 206564 14772 80336 176120 0 0 0 0 758 23 96 4 0 0
1 0 206564 14208 80336 176136 0 0 0 0 820 20 96 4 0 0
1 0 206956 13884 79180 175964 0 412 0 2680 1008 80 93 7 0 0
2 0 207348 14448 78800 175576 0 412 0 412 763 70 84 16 0 0
2 0 207348 15756 78800 175424 0 0 0 0 874 25 89 11 0 0
1 0 207348 16368 78800 175596 0 0 0 0 940 24 86 14 0 0
1 0 207348 16600 78800 175604 0 0 0 0 929 27 95 3 0 2
3 0 207348 16976 78548 175876 0 0 0 2508 969 35 93 7 0 0
4 0 207348 16216 78548 175704 0 0 0 0 874 36 93 6 0 1
4 0 207348 16424 78548 175776 0 0 0 0 850 26 77 23 0 0
2 0 207348 17496 78556 175840 0 0 0 0 736 23 83 17 0 0
0 0 207348 17680 78556 175868 0 0 0 0 861 21 91 8 0 1
|
从这个case可以看出：
- 当前CPU几乎都完全吃满，同时可运行队列中任务有堆积
- 系统有在使用swap，情况非常糟糕
- 内存也非常紧张，可用内存很少
- 线程上下文切换比中断少很多。猜测是个单线程在工作的样子（需要业务知识验证），如果不是从业务知识下判断
- 线上服务一般不允许出现这么糟糕的情况
case 2：
# vmstat 1
procs memory swap io system cpu
r b swpd free buff cache si so bi bo in cs us sy wa id
2 1 207740 98476 81344 180972 0 0 2496 0 900 2883 4 12 57 27
0 1 207740 96448 83304 180984 0 0 1968 328 810 2559 8 9 83 0
0 1 207740 94404 85348 180984 0 0 2044 0 829 2879 9 6 78 7
0 1 207740 92576 87176 180984 0 0 1828 0 689 2088 3 9 78 10
2 0 207740 91300 88452 180984 0 0 1276 0 565 2182 7 6 83 4
3 1 207740 90124 89628 180984 0 0 1176 0 551 2219 2 7 91 0
4 2 207740 89240 90512 180984 0 0 880 520 443 907 22 10 67 0
5 3 207740 88056 91680 180984 0 0 1168 0 628 1248 12 11 77 0
4 2 207740 86852 92880 180984 0 0 1200 0 654 1505 6 7 87 0
6 1 207740 85736 93996 180984 0 0 1116 0 526 1512 5 10 85 0
0 1 207740 84844 94888 180984 0 0 892 0 438 1556 6 4 90 0
|
从这个case可以得出下面结论：
- 线程上线文切换相比中断要频繁，内核消耗大量的时间完成上下文切换。
- CPU负载严重不均衡，用户进程消耗很少的CPU，但是大量的时间都在等待IO
- 因为CPU在等待IO，导致有些任务被block住了
2.3，mpstat使用
因为现在大多服务器都是多核，可以采用mpstat命令查看每个单核CPU的使用情况
sankuai@mobile-moviesolr02:~$ mpstat -P ALL 1
Linux 3.2.0-34-virtual (mobile-moviesolr02) 10/16/2015 _x86_64_ (4 CPU)
05:35:41 PM CPU %usr %nice %sys %iowait %irq %soft %steal %guest %idle
05:35:42 PM all 25.81 0.00 1.25 0.50 0.00 0.00 0.00 0.00 72.43
05:35:42 PM 0 1.00 0.00 1.00 0.00 0.00 0.00 0.00 0.00 98.00
05:35:42 PM 1 35.71 0.00 0.00 0.00 0.00 0.00 0.00 0.00 64.29
05:35:42 PM 2 6.93 0.00 3.96 0.00 0.00 0.00 0.00 0.00 89.11
05:35:42 PM 3 59.41 0.00 0.99 0.99 0.00 0.00 0.00 0.00 38.61
05:35:42 PM CPU %usr %nice %sys %iowait %irq %soft %steal %guest %idle
05:35:43 PM all 25.81 0.00 1.25 0.00 0.00 0.00 0.25 0.00 72.68
05:35:43 PM 0 0.00 0.00 1.01 0.00 0.00 0.00 0.00 0.00 98.99
05:35:43 PM 1 0.99 0.00 1.98 0.00 0.00 0.00 0.00 0.00 97.03
05:35:43 PM 2 8.00 0.00 2.00 0.00 0.00 0.00 0.00 0.00 90.00
05:35:43 PM 3 95.92 0.00 0.00 0.00 0.00 0.00 0.00 0.00 4.08
|
case 1:
#通过top -d 1 可以找出消耗CPU的大户
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
15957 nobody 25 0 2776 280 224 R 100 20.5 0:25.48 php
15959 mysql 25 0 2256 280 224 R 100 38.2 0:17.78 mysqld
15960 apache 25 0 2416 280 224 R 100 15.7 0:11.20 httpd
15901 root 16 0 2780 1092 800 R 1 0.1 0:01.59 top
1 root 16 0 1780 660 572 S 0 0.0 0:00.64 init
##然后可以看该进程在哪颗CPU上面，以及优先级如何
while :; do ps -eo pid,ni,pri,pcpu,psr,comm | grep 'java'; sleep 1; done
PID NI PRI %CPU PSR COMMAND
15775 0 15 86.0 3 mysqld
PID NI PRI %CPU PSR COMMAND
15775 0 14 94.0 3 mysqld
PID NI PRI %CPU PSR COMMAND
15775 0 14 96.6 3 mysqld
PID NI PRI %CPU PSR COMMAND
15775 0 14 98.0 3 mysqld
##PSR表示运行于第几颗CPU
|
参考：
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请联系我们举报，一经查实，本站将立刻删除。
发布者：全栈程序员-站长，转载请注明出处：https://javaforall.net/167721.html原文链接：https://javaforall.net
