判断CPU、内存、磁盘的性能瓶颈
一、cpu性能瓶颈
1、cpu指标要求
建议CPU指标如下
- 对于每一个CPU来说运行队列不要超过3,例如,如果是双核CPU就不要超过6;
- 如果CPU在满负荷运行,应该符合下列分布,
- User Time:65%~70%, us过大,说明有用户进程占用很多cpu时间,需要进一步的分析其它软硬件因素。
- System Time:30%~35%,sy过大,说明系统管理方面花了很多时间,说明该系统中某个子系统产生了瓶颈,需要进一步分析其它软硬件因素。
- User Time+System Time ,合理值范围是 60-85%,如果在一个多用户系统中us+sy时间超过85%,则进程可能要花时间在运行队列中等待,响应时间和业务吞吐量会受损害
- Idle:0%~5%, CPU完全空闲的百分比
- 对于上下文切换要结合CPU使用率来看,如果CPU使用满足上述分布,大量的上下文切换也是可以接受的。
- 出现cpu计数器不在范围时,不一定是由于cpu资源不够,因为其他资源的也会引起,例如内存不够时,cpu会忙内存管理的事,表面上可能是cpu的利用为100%
2、cpu3个重要概念
有3个重要的概念:上下文切换(context switchs),运行队列(Run queue)和使用率(utilization)
查看运行队列,使用top或者uptime查看
- 每个CPU都会维持一个运行队列,理想情况下,调度器会不断让队列中的进程运行。进程不是处在sleep状态就是run able状态。
- 如果CPU过载,就会出现调度器跟不上系统的要求,导致可运行的进程会填满队列。
- 队列愈大,程序执行时间就愈长。
- “load”用来表示运行队列,用top 命令我们可以看到CPU一分钟,5分钟和15分钟内的运行队列的大小。
- 这个值越大表明系统负荷越大。用uptime得到的3个负载值除以逻辑CPU数,如果3个结果值均>1,则表示CPU过载。
查看上下文切换,使用vmstat查看cs
- 每个CPU(或多核CPU中每个核心)在同一时间只能执行一个线程,Linux采用抢占式调度,线程的处理器可以在同一时间运行多个线程(包括多核CPU),Linux内核会把多核的处理器当作多个单独的CPU来识别
- 即为每个线程分配一定的执行时间,当到达执行时间,线程中有IO阻塞或高优先级线程要执行时,Linux将切换执行的线程,在切换时要存储目前线程的执行状态,并恢复要执行的线程状态,这个过程称之为上下文切换。
- 对于java应用,典型的是在进行文件IO操作,网络IO操作,锁等待或线程sleep时,当前线程会进入阻塞或者休眠状态,从而触发上下文切换,上下文切换过多会造成内核占用过多的CPU使用,使得应用的响应速度下降。
- 一个标准的Linux内核可以支持运行50~50000个进程运行,对于普通的CPU,内核会调度和执行这些进程
关于时间片和动态优先级
- 时间片对于CPU来说是很关键的参数,如果时间片太长,就会使系统的交互性能变差,用户感觉不到并行。如果太短,又会造成系统频繁的上下文切换,使性能下降。对于IO Bound的系统来讲并不需要太长的时间片,因为系统主要是IO操作;而对于CPU Bound的系统来说需要长的时间片以保持cache的有效性。
- 每一个进程启动的时候系统都会给出一个默认的优先级,但在运行过程中,系统会根据进程的运行状况不断调整优先级,内核会升高或降低进程的优先级(每次增加或降低5),判断标准是根据进程处于sleep状态的时间。
- IO Bound进程大部分时间在sleep状态,所以内核会调高它的优先级,CPU Bound进程会被内核惩罚降低优先级。因此,如果一个系统上即运行IO Bound进程,又运行CPU Bound进程,会发现,IO Bound进程的性能不会下降,而CPU Bound进程性能会不断下降。
3、CPU相关分析命令
top命令:
输入top命令,如下图:
top命令显示内容后按1,则会显示每颗CPU的使用情况,如下图
结论:用户空间和内核空间的CPU使用百分比一般是70%和30%,这是一个比较合理的值。如果内核空间占用CPU太多,则会影响进程(用户空间)提供的服务。
uptime命令:
输入uptime命令,如下图:
结论:CPU来说运行队列不要超过3,例如,如果是双核CPU就不要超过6
w命令:
结论:主要关注Load average,其3个值从左至右分别代表最近1分钟、最近5分钟、最近15分钟系统的负载。如果这3个值除以CPU核数>1,则表示服务器有较大压力,可以使用vmstat进一步查看CPU运行队列。
vmstat命令:
结论:
- cs表示上下文切换的数量
- r: 表示系统中 CPU 等待处理的线程。由于 CPU 每次只能处理一个线程,所以,该数值越大,通常表示系统运行越慢,当这个值超过了CPU数目,就会出现CPU瓶颈了
- wa:IO 等待消耗的 CPU 时间百分比。该值较高时,说明 IO 等待比较严重,这可能磁盘大量作随机访问造成的,也可能是磁盘性能出现了瓶颈。
![](https://img2022.cnblogs.com/blog/782175/202205/782175-20220526153859886-1230450855.png)
sar命令(System Activity Reporter系统活动情况报告):
执行sar -q命令,结果如下:
输出项说明:
runq-sz:运行队列的长度(等待运行的进程数)
plist-sz:进程列表中进程(processes)和线程(threads)的数量
ldavg-1:最后1分钟的系统平均负载(System load average)
ldavg-5:过去5分钟的系统平均负载
ldavg-15:过去15分钟的系统平均负载
pidstat命令:
自动某个进行上下文切换情况:
![](https://img2022.cnblogs.com/blog/782175/202205/782175-20220526152011949-743997371.png)
查看活动进程的 CPU 统计信息:
dstat命令:
执行dstat --top-cpu 可以实时查看CPU当前在运行的进程名称,如下图
dstat --top-cpu --top-mem --top-io
4、定位进程某个线程cpu高
- top -Hp pid来找到 CPU 使用率比较高的一些线程
- 将排在前面的线程 PID 转换成十六进制:printf ‘%x\n’ pid得到 nid
- 打印 Java 线程栈的信息:jstack 24076| grep 5e0d -A30
5、结论
- 检查system的运行队列,以及确定不要超出每个处理器3个可运行状态线程的限制.
- 确定CPU 利用率中user/system比例维持在70/30
- 当CPU 开销更多的时间在system mode,那就说明已经超负荷并且应该尝试重新调度优先级
- 当I/O 处理得到增长,CPU 范畴的应用处理将受到影响
- ps:对于JAVA应用,CPU瓶颈可以通过jprofiler监控分析
二、内存瓶颈
1、查看利用率(free)
used:已使用多大。
free:可用有多少。
Shared:多个进程共享的内存总额。
Buffers/cached:磁盘缓存的大小。
所以空闲内存=free+buffers+cached=total-used
2、查看页交换,swap交换(pi、po、so、si),磁盘IO(vmstat)
si: 每秒从交换区写到内存的大小
so: 每秒写入交换区的内存大小
page in :分页(Page)从磁盘重新回到内存的过程被称作Page-In
page out : 分页(Page)写入磁盘的过程被称作Page-Out
另外在进行页交换的时候,会产生磁盘IO,还需注意bi,bo
Bo 磁盘块页面从内存到文件或交换设备的总额
Bi 磁盘块页面从文件或交换设备到内存的总额
vmstat命令:
si:交换内存使用,由磁盘调入内存
so:交换内存使用,由内存调入磁盘
sar命令:
sar -W 10 3
pswpin/s:每秒系统换入的交换页面(swap page)数量
pswpout/s:每秒系统换出的交换页面(swap page)数量
vmstat -s 查看 paged in/out 数量:
3、page fault(pidstat -r,sar -B )
minflt/s: 每秒次缺页错误次数(minor page faults),次缺页错误次数意即虚拟内存地址映射成物理内存地址产生的page fault次数
majflt/s: 每秒主缺页错误次数(major page faults),当虚拟内存地址映射成物理内存地址时,相应的page在swap中,这样的page fault为major page fault,一般在内存使用紧张时产生
其中sar -B中fault/s表示每秒钟minflt,majflt的和。
pidstat -r命令:
输出信息含义: PID:进程标识符 Minflt/s:任务每秒发生的次要错误,不需要从磁盘中加载页 Majflt/s:任务每秒发生的主要错误,需要从磁盘中加载页 VSZ:虚拟地址大小,虚拟内存的使用KB RSS:常驻集合大小,非交换区五里内存使用KB %MEM:进程当前使用的物理内存百分比 Command:task命令名
sar -B 命令:
pgpgin/s:表示每秒从磁盘或SWAP置换到内存的字节数(KB)
pgpgout/s:表示每秒从内存置换到磁盘或SWAP的字节数(KB)
fault/s:每秒钟系统产生的缺页数,即主缺页与次缺页之和(major + minor)
majflt/s:每秒钟产生的主缺页数.
pgfree/s:每秒被放入空闲队列中的页个数
pgscank/s:每秒被kswapd扫描的页个数
pgscand/s:每秒直接被扫描的页个数
pgsteal/s:每秒钟从cache中被清除来满足内存需要的页个数
%vmeff:每秒清除的页(pgsteal)占总扫描页(pgscank+pgscand)的百分比
4、结论
监控虚拟内存性能由以下几个部分组成:
1.当系统中出现较少的页错误,获得最好的响应时间,是因为memory caches(译注:内存高速缓存)比disk caches更快(译注:磁盘高速缓存).
2.较少的空闲内存,是件好事情,那意味着缓存的使用更有效率.除非在不断的写入swap device和disk.
3.如果系统不断报告,swap device总是繁忙中,那就意味着内存已经不足,需要升级了.
zee:
如果用做缓冲区(buff)和快速缓存(Cache)的物理内存不断地增加,而空闲的物理内存(free)不断地减少,证明系统中运行的进程正在不断地消耗物理内存。
已经使用的虚拟内存(swpd)不断增加,而且存在着大量的页面交换(si和so),证明物理内存已经不能满足系统需求,系统必须把物理内存的页面交换到磁盘中去。
由此可以得到这样的结论:该主机上的物理内存已经不能满足系统运行的需要,内存已成为该系统性能的一个瓶颈。
ps:对于java程序,内存瓶颈可以通过heap dump后使用mat分析
三、磁盘瓶颈
1、确认磁盘 I/O 存在性能问题
对于随机负载,当遇到余下情况时,我们那通常认为存在 I/O 性能问题:
1. 平均读时间大于 15ms
2. 在具有写 cache 的条件下,平均写时间大于 2.5ms
对于顺序负载,当遇到余下情况时,我们那通常认为存在 I/O 性能问题:
1. 在一个磁盘上有两个连续的 I/O 流
2. 吞吐量不足(即远远小于磁盘 I/O 带宽)
对于一块磁盘来讲,随着 IOPS 数量的增加,I/O service 也会增加,并且会有一个饱和点,即 IOPS 达到某个点以后,IOPS 再增加将会引起 I/O service time 的显著增加。
图 3. 磁盘 IOPS 与 IO service time 关系图
- 从经验上讲,我们在测试工作中,我们主要关注 IOPS 和吞吐量以及磁盘的 busy% 这三个数值。
- 如果 IOPS 和吞吐量均很低,磁盘的 busy% 也很低,我们会认为磁盘压力过小,造成吞吐量和 IOPS 过低;
- 只有在 IOPS 和吞吐量均很低,磁盘的 busy% 很高(接近 100%)的时候,我们才会从磁盘 I/O 方面分析 I/O 性能
2、磁盘性能指标
五个常见指标: 使用率、饱和度、IOPS、吞吐量以及响应时间。这五个指标,是衡量磁盘性能的基本指标。
- 使用率,是指磁盘处理 I/O 的时间百分比。过高的使用率(比如超过 80%),通常意味着磁盘 I/O 存在性能瓶颈。
- 饱和度,是指磁盘处理 I/O 的繁忙程度。过高的饱和度,意味着磁盘存在严重的性能瓶颈。当饱和度为 100% 时,磁盘无法接受新的 I/O 请求。
- IOPS(Input/Output Per Second),是指每秒的 I/O 请求数。
- 吞吐量,是指每秒的 I/O 请求大小。
- 响应时间,是指 I/O 请求从发出到收到响应的间隔时间。
3、定位命令
- iostat查看IO信息。如果 %util 接近 100%,说明产生的I/O请求太多,I/O系统已经满负荷,该磁盘可能存在瓶颈。
- 另外还需要注意iowait这个值,iowait 值高就意味着磁盘缓慢或负载过大。还有不要信任svctm这个字段。
- 监控swap 和系统分区,要确保virtual memory不是文件系统I/O 的瓶颈.
- ps:磁盘瓶颈可以通过pidstat -d 定位程序(Centos中安装pidstat命令:yum install sysstat)
iostat(%util):
iostat 是最常用的磁盘 I/O 性能观测工具,它提供了每个磁盘的使用率、IOPS、吞吐量等各种常见的性能指标,当然,这些数据实际上来自 /proc/diskstats。
查看设备使用率(%util)、响应时间(await)
说明:PID:进程id
kB_rd/s:每秒从磁盘读取的KB
kB_wr/s:每秒写入磁盘KB
kB_ccwr/s:任务取消的写入磁盘的KB。当任务截断脏的pagecache的时候会发生。
COMMAND:task的命令名
1、如果 %util 接近 100%,说明产生的I/O请求太多,I/O系统已经满负荷,该磁盘可能存在瓶颈。 2、如果 svctm 比较接近 await,说明 I/O 几乎没有等待时间; 3、如果 await 远大于 svctm,说明I/O 队列太长,io响应太慢,则需要进行必要优化。 4、如果avgqu-sz比较大,也表示有当量io在等待。 5、idle小于70% IO压力就较大了,一般读取速度有较多的wait。
这些指标中,重点注意:
• %util ,就是我们前面提到的磁盘 I/O 使用率;
• r/s+ w/s ,就是 IOPS;
• rkB/s+wkB/s ,就是吞吐量;
• r_await+w_await ,就是响应时间。
top(iowait%):
pidstat -d:
查看活跃进程的 I/O 读写情况
PID:进程id
kB_rd/s:每秒从磁盘读取的KB
kB_wr/s:每秒写入磁盘KB
kB_ccwr/s:任务取消的写入磁盘的KB。当任务截断脏的pagecache的时候会发生。
COMMAND:task的命令名
iotop命令:
根据 I/O 大小对进程排序:
前两行分别表示,进程的磁盘读写大小总数和磁盘真实的读写大小总数。因为缓存、缓冲区、I/O 合并等因素的影响,它们可能并不相等。
剩下的部分,则是从各个角度来分别表示进程的 I/O 情况,包括线程 ID、I/O 优先级、每秒读磁盘的大小、每秒写磁盘的大小、换入和等待 I/O 的时钟百分比等。
posted on 2022-05-26 14:23 uestc2007 阅读(1818) 评论(0) 编辑 收藏 举报