1、性能分析思路

性能测试分析的思路:先分析硬件 、网络、 系统配置、应用程序

硬件: cpu、内存、磁盘、网络、io

4、常见问题处理
4.1 常见问题及解决方法
如果r经常大于4,且id经常少于40,表示cpu的负荷很重。

如果pi,po长期不等于0,表示内存不足。

如果disk经常不等于0,且在b中的队列大于3,表示io性能不好。

1.)如果在processes中运行的序列(process r)是连续的大于在系统中的CPU的个数表示系统现在运行比较慢,有多数的进程等待CPU。

2.)如果r的输出数大于系统中可用CPU个数的4倍的话,则系统面临着CPU短缺的问题,或者是CPU的速率过低,系统中有多数的进程在等待CPU,造成系统中进程运行过慢。

3.)如果空闲时间(cpu id)持续为0并且系统时间(cpu sy)是用户时间的两倍(cpu us)系统则面临着CPU资源的短缺。

当发生以上问题的时候请先调整应用程序对CPU的占用情况.使得应用程序能够更有效的使用CPU.同时可以考虑增加更多的CPU. 关于CPU的使用情况还可以结合mpstat, ps aux top prstat –a等等一些相应的命令来综合考虑关于具体的CPU的使用情况,和那些进程在占用大量的CPU时间.一般情况下,应用程序的问题会比较大一些.比如一些sql语句不合理等等都会造成这样的现象.

内存问题现象:

内存的瓶颈是由scan rate (sr)来决定的.scan rate是通过每秒的始终算法来进行页扫描的.如果scan rate(sr)连续的大于每秒200页则表示可能存在内存缺陷.同样的如果page项中的pi和po这两栏表示每秒页面的调入的页数和每秒调出的页数.如果该值经常为非零值,也有可能存在内存的瓶颈,当然,如果个别的时候不为0的话,属于正常的页面调度这个是虚拟内存的主要原理.

解决办法:
1.调节applications & servers使得对内存和cache的使用更加有效.

2.增加系统的内存.

3. Implement priority paging in s in pre solaris 8 versions by adding line "set priority paging=1" in /etc/system. Remove this line if upgrading from Solaris 7 to 8 & retaining old /etc/system file.

关于内存的使用情况还可以结ps aux top prstat –a等等一些相应的命令来综合考虑关于具体的内存的使用情况,和那些进程在占用大量的内存.一般情况下,如果内存的占用率比较高,但是,CPU的占用很低的时候,可以考虑是有很多的应用程序占用了内存没有释放,但是,并没有占用CPU时间,可以考虑应用程序,对于未占用CPU时间和一些后台的程序,释放内存的占用。

r 表示运行队列(就是说多少个进程真的分配到CPU),我测试的服务器目前CPU比较空闲,没什么程序在跑,当这个值超过了CPU数目,就会出现CPU瓶颈了。这个也和top的负载有关系,一般负载超过了3就比较高,超过了5就高,超过了10就不正常了,服务器的状态很危险。top的负载类似每秒的运行队列。如果运行队列过大,表示你的CPU很繁忙,一般会造成CPU使用率很高。

5.常见性能问题分析
IO/CPU/men连锁反应
1.free急剧下降
2.buff和cache被回收下降,但也无济于事
3.依旧需要使用大量swap交换分区swpd
4.等待进程数,b增多
5.读写IO,bi bo增多
6.si so大于0开始从硬盘中读取
7.cpu等待时间用于 IO等待,wa增加
内存不足
1.开始使用swpd,swpd不为0
2.si so大于0开始从硬盘中读取
io瓶颈
1.读写IO,bi bo增多超过2000
2.cpu等待时间用于 IO等待,wa增加 超过20
3.sy 系统调用时间长,IO操作频繁会导致增加 >30%
4.wa io等待时间长
iowait% <20% 良好
iowait% <35% 一般
iowait% >50%
5.进一步使用iostat观察
CPU瓶颈:load,vmstat中r列
1.反应为CPU队列长度
2.一段时间内,CPU正在处理和等待CPU处理的进程数之和,直接反应了CPU的使用和申请情况。
3.理想的load average:核数*CPU数*0.7
CPU个数:grep 'physical id' /proc/cpuinfo | sort -u
核数:grep 'core id' /proc/cpuinfo | sort -u | wc -l
4.超过这个值就说明已经是CPU瓶颈了
CPU瓶颈
1.us 用户CPU时间高超过90%
涉及到web服务器,cs 每秒上下文切换次数
例如我们调用系统函数,就要进行上下文切换,线程的切换,也要进程上下文切换,这个值要越小越好,太大了,要考虑调低线程或者进程的数目,例如在apache和nginx这种web服务器中,我们一般做性能测试时会进行几千并发甚至几万并发的测试,选择web服务器的进程可以由进程或者线程的峰值一直下调,压测,直到cs到一个比较小的值,这个进程和线程数就是比较合适的值了。系统调用也是,每次调用系统函数,我们的代码就会进入内核空间,导致上下文切换,这个是很耗资源,也要尽量避免频繁调用系统函数。上下文切换次数过多表示你的CPU大部分浪费在上下文切换,导致CPU干正经事的时间少了,CPU没有充分利用,是不可取的。
1.cs可以对apache和nginx线程和进程数限制起到一定的参考作用
2.我们一般做性能测试时会进行几千并发甚至几万并发的测试,选择web服务器的进程可以由进程或者线程的峰值一直下调,压测,直到cs到一个比较小的值,这个进程和线程数就是比较合适的值了
较好的趋势:主要是 swap使用少,swpd数值低。si so分页读取写入数值趋近于零

6.其他说明:
b 表示阻塞的进程,这个不多说,进程阻塞,大家懂的。

swpd 虚拟内存已使用的大小,如果大于0,表示你的机器物理内存不足了,如果不是程序内存泄露的原因,那么你该升级内存了或者把耗内存的任务迁移到其他机器。

free 空闲的物理内存的大小,我的机器内存总共8G,剩余3415M。

buff Linux/Unix系统是用来存储,目录里面有什么内容,权限等的缓存,我本机大概占用300多M

cache cache直接用来记忆我们打开的文件,给文件做缓冲,我本机大概占用300多M(这里是Linux/Unix的聪明之处,把空闲的物理内存的一部分拿来做文件和目录的缓存,是为了提高 程序执行的性能,当程序使用内存时,buffer/cached会很快地被使用。)

si 每秒从磁盘读入虚拟内存的大小,如果这个值大于0,表示物理内存不够用或者内存泄露了,要查找耗内存进程解决掉。我的机器内存充裕,一切正常。

so 每秒虚拟内存写入磁盘的大小,如果这个值大于0,同上。

bi 块设备每秒接收的块数量,这里的块设备是指系统上所有的磁盘和其他块设备,默认块大小是1024byte,我本机上没什么IO操作,所以一直是0,但是我曾在处理拷贝大量数据(2-3T)的机器上看过可以达到140000/s,磁盘写入速度差不多140M每秒

bo 块设备每秒发送的块数量,例如我们读取文件,bo就要大于0。bi和bo一般都要接近0,不然就是IO过于频繁,需要调整。

in 每秒CPU的中断次数,包括时间中断

cs 每秒上下文切换次数,例如我们调用系统函数,就要进行上下文切换,线程的切换,也要进程上下文切换,这个值要越小越好,太大了,要考虑调低线程或者进程的数目,例如在apache和nginx这种web服务器中,我们一般做性能测试时会进行几千并发甚至几万并发的测试,选择web服务器的进程可以由进程或者线程的峰值一直下调,压测,直到cs到一个比较小的值,这个进程和线程数就是比较合适的值了。系统调用也是,每次调用系统函数,我们的代码就会进入内核空间,导致上下文切换,这个是很耗资源,也要尽量避免频繁调用系统函数。上下文切换次数过多表示你的CPU大部分浪费在上下文切换,导致CPU干正经事的时间少了,CPU没有充分利用,是不可取的。

us 用户CPU时间,我曾经在一个做加密解密很频繁的服务器上,可以看到us接近100,r运行队列达到80(机器在做压力测试,性能表现不佳)。

sy 系统CPU时间,如果太高,表示系统调用时间长,例如是IO操作频繁。

id 空闲 CPU时间,一般来说,id + us + sy = 100,一般我认为id是空闲CPU使用率,us是用户CPU使用率,sy是系统CPU使用率。

wt 等待IO CPU时间。
以上原文链接:
原文链接:https://blog.csdn.net/shugyin/article/details/127434367

2、CPU简介

>中央处理器
》 结构: 运算器、控制器、寄存器、时钟
运算器:运算
控制器:把内存的指令、数据读入寄存器,控制计算机寄存器: 暂存指令、数据、地址
>时钟:计时
》内存:与CPU沟通的桥梁,存cpu的运算数据;硬盘、外存数据

一段程序要被执行,先编译成机器语言, 进入内存, cpu控制器再从内存中获取指令、数据,放到寄存器中, 时钟控制,CPU的运算器什么时候开始计算,计算时长多长, 运算器开始计算,运算过程中,如果还需要数据,控制器,再从寄存器中拿数据,拿不到就从内存中拿,如果1个时间片段计算不完,就干其他事,之后再执行,执行完了,输出数据给寄存器,传给内存=======切换、中断

cpu 中央处理器
架构、主频、核
cpu:结构 主要物理结构是3个,实际是有4
运算器: 真正进行计算的单元
控制器: leader
寄存器: 存储 指令、数据、地址
时钟

内存: 程序代码、网络数据,外部数据进入cpu的桥梁,内存的速度,要比cpu的速度

cpu中: 内核、线程、架构

cpu的内核,医院中的医生

cpu的线程,医生配备的护士

cpu的架构,医院的结构

看cpu的数据信息: `top` `lscpu` `cat /proc/cpuinfo`

/proc 虚拟文件,操作系统启动时,读取的信息,这些信息放内存中

`cat /proc/cpuinfo |grep "physical id" |sort |uniq |wc -l ` 查看物理cpu数量

`cat /proc/cpuinfo | grep "cpu cores" |uniq `查看CPU的core数,即核数

`cat /proc/cpuinfo | grep "processor" |wc -l` 查看逻辑CPU数量

load average = cpuload ioload

上下文切换: 寄存器中的资源进行切换
自愿上下文切换: 资源不够,自觉的切换到另外指令上
非自愿上下文切换: 有可能有优先级更高的指令、指令执行的时间已经到了,被迫中止当前的指令,去执行其他指令

最新文章

  1. cf Round 613
  2. 【原】ajaxupload.js上传报错处理方法
  3. Units Problem: How to read text size as custom attr from xml and set it to TextView in java code
  4. 解析PHP中的file_get_contents获取远程页面乱码的问题【转】
  5. Mysql迁移工具在生产环境下的使用
  6. complex(x):创建一个复数
  7. java_反射_及其简单应用(2016-11-16)
  8. PHP编程规范
  9. Git 文件状态的转换
  10. [Spark内核] 第36课:TaskScheduler内幕天机解密:Spark shell案例运行日志详解、TaskScheduler和SchedulerBackend、FIFO与FAIR、Task运行时本地性算法详解等
  11. Webpack执行命令参数详解
  12. UOJ#465. 【HNOI2019】校园旅行 其他
  13. CentOS 编译安装 Nodejs (实测 笔记 Centos 7.3 + node 6.9.5)
  14. MTQQ 物联网
  15. NPOI帮助类
  16. Array and Linkedlist区别与操作的时间复杂度(转载)
  17. Oracle DBHelper 第二版
  18. 17、uwp 打包失败记录
  19. Python爬虫初识
  20. 数据库使用B+树原理

热门文章

  1. springboot框架返回日期值少一天
  2. JAVA虚拟机21---JAVA内存模型
  3. 聊聊火热的 ChatGPT(我帮大伙问了几个比较关心的问题)
  4. Servlet HTTP Request Response笔记
  5. 自动化测试如此容易!多语言自动化测试框架 Selenium 编程(C#篇)
  6. T-SQL——将字符串转换为多列
  7. JDK、JRE、JVM三者之间的关系
  8. 在线工具帮助医生在社区转诊时甄别SpA患者
  9. Pdfjs第三方插件使用
  10. C语言学习--结构体指针