性能瓶颈定位分析

1 首先进行OS层面的检查确认
首先要确认当前到底是哪些进程引起的负载高,以及这些进程卡在什么地方,瓶颈是什么。
一般情况下,服务器上最容易成为瓶颈的是磁盘I/O子系统,因为它的读写速度通常是最慢的;也会有其他原因:

1.某些进程/服务消耗更多CPU资源(服务响应更多请求或存在某些应用瓶颈);
2.发生比较严重的swap(可用物理内存不足);
3.发生比较严重的中断(因为SSD或网络的原因发生中断);
4.磁盘I/O比较慢(会导致CPU一直等待磁盘I/O请求);
一般先看整体负载如何
可以使用w 或sar -q 来查看服务器负载数据

sar -q 1

runq-sz:   运行队列的长度(等待运行的进程数)                                     
plist-sz:   进程列表中进程(processes)和线程(threads)的数量                    
ldavg-1:   最后1分钟的系统平均负载(System load average)                         
ldavg-5:   过去5分钟的系统平均负载                                                
ldavg-15: 过去15分钟的系统平均负载

查看CPU使用率

sar -u 2

07:20:28 PM     CPU     %user     %nice   %system   %iowait    %steal     %idle
07:20:30 PM     all     35.09      0.00     64.91      0.00      0.00      0.00
07:20:32 PM     all     27.38      0.00     52.38     20.24      0.00      0.00
07:20:35 PM     all     34.33      0.00     61.19      4.48      0.00      0.00
07:20:37 PM     all     36.51      0.00     63.49      0.00      0.00      0.00
07:20:39 PM     all     33.33      0.00     66.67      0.00      0.00      0.00
07:20:41 PM     all     33.33      0.00     61.90      4.76      0.00      0.00
07:20:43 PM     all     37.93      0.00     62.07      0.00      0.00      0.00

%user : 用户模式下消耗的CPU时间的比例;

%nice:通过nice改变了进程调度优先级的进程,在用户模式下消耗的CPU时间的比例;

%system:系统模式下消耗的CPU时间的比例;

%iowait:CPU等待磁盘I/O而导致空闲状态消耗时间的比例;

%steal:利用Xen等操作系统虚拟化技术时,等待其他虚拟CPU计算占用的时间比例;

%idle:CPU没有等待磁盘I/O等的空闲状态消耗的时间比例;

注:

如果 %iowait 的值过高,表示硬盘存在I/O瓶颈
如果 %idle 的值高但系统响应慢时,有可能是 CPU 等待分配内存,此时应加大内存容量
如果 %idle 的值持续低于 10,则系统的 CPU 处理能力相对较低,表明系统中最需要解决的资源是 CPU。

磁盘IO分析

iotop 确认到底哪些进程消耗的磁盘I/O资源最多

由于是压力测试,所以测试进程IO都比较高。

数据库层可以查看日志,对日志中的sql进行分析。

时间: 2024-12-08 11:02:54

性能瓶颈定位分析的相关文章

消息中间件的定位分析

消息中间件的定位分析 在以下的分析中,把产生消息的应用统一定义为消息的生产者,接收消息的应用统一定义为消息的消费者,尽管在mq中不使用这样的定义,而是称之为消息的发送 者和接收者.从不同的消息中间件对消息的产生者和使用者的名称定义来看,实际上已经反映出各消息中间件之间定位的差异,通过下面的分析,这种差异会更加清 晰.为了概念的统一,本文统一采用消息的生产者和消费者. 1.MQSeries Mq设计的核心思想是存储转发,围绕消息如何发送到目的地完成产品的各类功能.在mq中,发送消息之前,需要把消息

一次服务器IO占用率高的定位分析

背景:请事假在外中,听平台组同事反馈了一个问题,在往生产数据库中导入部分数据时会造成客户端的访问超时,初步定位是因为服务器磁盘占用IO过高,导数据时IO会飙升到100%,因此引起了不少数据库的慢查询操作导致客户端响应超时,无奈只好暂时停止了导入数据的脚本,同时也延误了针对这部分数据的生产测试工作.于是我第二天回到公司就投入了对这个问题的跟踪定位工作. 环境描述: 操作系统 文件系统 数据库 首先我们数据库某最大表的数据也不过300w多条,对于MySQL来说还是能够正常处理的.而且客户端并发量也不

LCD 显示异常定位分析方法

第一种情况: 进入kernel或android 后,如果LCM图像示异常,可以通过如下步骤来判断问题出现在哪个层面. step1:通过DMMS截图,来判断上面刷到LCM的数据是否有问题. 若DMMS获取的图片没有问题,问题基本可以定位在LCM 驱动/模组,以及时序方面. step2: 若step1中DMMS获取的数据有问题,则需要抓取framebuffer数据进一步分析 adb shell cat /dev/graphics/fb0 > /data/fb.bin 然后将fb.bin通过adb p

百度云推送消息到达率低问题定位分析

去年做我们这个产品的时候,SE在客户端设计了一个推送功能,SE经过调研决定在Android和IOS端都集成百度的云推送SDK来支持这个推送功能.最近领导在做运营分析的时候,发现云推送的报表显示,在Android端消息的达到率非常低,设备的在线率波动比较大,有时高有时非常低. 我们的这个产品经过将近两年的折腾进步是有目共睹的,在今年的巴塞罗那GSMA世界移动通信大会上荣获"Best Mobile Music App"大奖,让我们这帮苦逼了将近两年的屌丝士气大振,领导也欣喜不已并且决定将精

通过日志定位分析接口调用缓慢的原因

最近我们的接口中有两个被调用的时候比较缓慢,一个查询大概需要2-3秒的样子,我们需要定位一下具体需要的时间秒数,就让某猿过去实现了.提交代码我review的时候我吓了一跳,那那两个类进行了手动统计时间,代码就不贴了,这样十分不好啊,如果以后要统计其他的controller或者service那就得手动再写,所以我重写了一份 我们需要对service以及controller进行统计,所以在springmvc.xml以及application-service.xml中都要开启aspectj 注解 <!

基于GIScript和GeoIP进行访问网址的地理定位分析

通过网页访问日志分析使用者的地址,然后将其放到地图上,分析访问来源的热区从而得到用户的地图分布,是不是很有用.也很酷?这里介绍个使用GIScript和GeoIP来进行访问网址的地理定位的例子. 这个功能虽然看起来简单,但其实要分为很多个环节的.下面详述: 1.首先是获取IP地址,这个不多说了.在Web服务器的RequestHeaders中都有,也可以通过日志进行提取.从文件中提取可以批量处理,而从访问信息中提取然后直接发送到消息总线或NoSQL之类的高效率存储系统可以实现实时的处理. 2.使用G

Linux 线程占用CPU过高定位分析

今天朋友问我一个Linux程序CPU占用涨停了,该如何分析, CPU占用过高,模拟CPU占用过高的情况 先上一段代码: 1 #include <iostream> 2 #include <thread> 3 #include <vector> 4 5 6 int main(int argc, char **argv) { 7 8 std::vector<std::thread> test_threads; 9 for(int i = 0; i < 9;

cpu监控波动定位分析问题

阿里云ECS->cpu监控信息 [[email protected] ~]# top 分析说明: cpu监视信息波动规律可以看出crontab任务或HTTP请求高峰期 对httpd mysqld服务占用cpu.内存使用率变化,本项目主要是api部分访问量大 cpu使用率高,定位原因: cpu使用率被拉高了,是数据量太大了,还是说响应时间太长了,还是说你这个并发量扛不住 原文地址:https://www.cnblogs.com/hnhycnlc888/p/12537239.html

log4j的性能瓶颈定位与性能优化(org.apache.log4j.spi.RootLogger) (转)

最近执行一个项目调优,发现使用第三方的Json库导致性能差.原以为问题就这么定位到了,结果去掉Json操作后,性能也不见好转. 现象非常诡异:CPU.内存.网络.磁盘使用率均有剩余,而且压力也是足够的.即使施加更大压力,吞吐量也不见好转. 于是监控了一下Java进程状态,发现几乎所有进程都处在 状态:BLOCKED 在 [email protected] 上,拥有者: http-0.0.0.0-8080-2010 阻塞总数:188,661 等待总数: 2,699 堆栈追踪: org.apache