性能调优总结

寻找性能瓶颈

  通常性能瓶颈的表象是资源消耗过多、外部处理系统性能不足或资源消耗不多,但程序的响应速度却仍达不到要求。

  资源主要消耗在CPU、文件IO、网络IO及内存方面,机器的资源是有限的,当某资源消耗过多时,通常会造成系统的响应速度变慢。

  外部处理的性能不够,主要是所调用的其他系统提供的功能或数据库操作的响应速度不够,所调用的其他系统性能不足,多数情况下也是资源消耗过多,但程序的性能不足造成的。数据库操作性能不足通常可以根据数据库的SQL执行速度、数据库机器的IOPS、数据库的Active Sessions等分析出来。

  资源消耗不多,但程序的响应速度仍达不到要求的主要原因是程序代码运行效率不够高、未充分使用资源或程序结构不合理。

  对java应用而言,寻找性能瓶颈的方法通常为,首先分析资源的消耗,然后结合java的一些工具来查询程序中造成资源消耗过多的代码。

CPU消耗分析

上下文切换

  每个CPU在同一时间只能执行一个线程,Linux采用抢占式调度,即:每个线程分配一定的执行时间,当到达执行时间、线程中有IO阻塞或高优先级线程要执行时,Linux将切换执行的线程,在切换时要存储目前线程的执行状态,并恢复要执行的线程的状态,这个过程,称为上下文切换。

运行队列

  每个CPU核都维护了一个可运行的线程队列。

  通常,系统的load主要由CPU的运行队列决定,load值越大,就意味着线程会消耗越长的时间才能执行完。

利用率

  CPU利用率为CPU在用户进程、内核、终端处理、IO等待以及空闲五个部分使用百分比。这五个值是分析CPU消耗情况的关键指标

  对java应用而言,CPU消耗严重主要体现在US、SY两个值上。

  US:当us值过高时,表示运行的应用消耗了大部分的CPU。

     这时,要找到具体消耗CPU的线程所执行的代码,

     Java应用造成us值过高的原因,主要是线程一直处于可运行状态,通常这些线程在执行无阻塞、循环、正则或存储的计算等动作造成的。

     另一个可能造成us值过高的原因是:频繁的GC。

  SY:当sy值高时,表示Linux花费了更多的时间在进行线程切换。

     Java应用造成这种现象的主要原因是启动的线程较多,且这些线程处于不断阻塞和执行状态的变化过程中,这就导致操作系统要不断切换执行的线程,产生大量的上下文切换。

     这时,最重要的是找出线程要不断切换状态的原因。

时间: 2024-08-08 14:09:17

性能调优总结的相关文章

iOS应用性能调优的25个建议和技巧

目录 我要给出的建议将分为三个不同的等级: 入门级. 中级和进阶级: 入门级(这是些你一定会经常用在你app开发中的建议) 1. 用ARC管理内存 2. 在正确的地方使用reuseIdentifier 3. 尽可能使Views透明 4. 避免庞大的XIB 5. 不要block主线程 6. 在Image Views中调整图片大小 7. 选择正确的Collection 8. 打开gzip压缩 中级(这些是你可能在一些相对复杂情况下可能用到的) 9. 重用和延迟加载Views 10. Cache, C

Android性能调优篇之Hierarchy Viewer工具的使用

详细内容请查看我的简书地址:Android性能调优篇之Hierarchy Viewer工具的使用 或者我的个人博客地址:Android性能调优篇之Hierarchy Viewer工具的使用

性能调优攻略

关于性能优化这是一个比较大的话题,在<由12306.cn谈谈网站性能技术>中我从业务和设计上说过一些可用的技术以及那些技术的优缺点,今天,想从一些技术细节上谈谈性能优化,主要是一些代码级别的技术和方法.本文的东西是我的一些经验和知识,并不一定全对,希望大家指正和补充. 在开始这篇文章之前,大家可以移步去看一下酷壳以前发表的<代码优化概要>,这篇文章基本上告诉你--要进行优化,先得找到性能瓶颈! 但是在讲如何定位系统性能瓶劲之前,请让我讲一下系统性能的定义和测试,因为没有这两件事,后

性能调优之:缓存

在执行任何查询时,SQL Server都会将数据读取到内存,数据使用之后,不会立即释放,而是会缓存在内存Buffer中,当再次执行相同的查询时,如果所需数据全部缓存在内存中,那么SQL Server不会产生Disk IO操作,立即返回查询结果,这是SQL Server的性能优化机制. 一,主要的内存消费者(Memory Consumer) 1,数据缓存(Data Cache) Data Cache是存储数据页(Data Page)的缓冲区,当SQL Server需要读取数据文件(File)中的数

SQL 语句性能调优

经常听到有做应用的朋友抱怨数据库的性能问题,比如非常低的并发,令人崩溃的响应时间,长时间的锁等待,锁升级 , 甚至是死锁,等等.在解决这些问题的过程中,DBA 经常发现应用开发人员对数据库的"误用".包括 , 返回过多不必要的数据 , 不必要和不适当加锁,对隔离级别的误用和对存储过程的误用等等.但是,面对浩如烟海的数据库知识 , 要求完全掌握 , 对应用开发人员来说也确实枯燥艰深 . 因此,笔者特别提炼对应用开发人员有帮助的 SQL 书写部分,以期望能对数据库开发人员有所帮助. &qu

JVM性能调优

一.JVM性能调优策略 二.性能调优 1.Java线程池(java.util.concurrent.ThreadPoolExecutor) 大多数JVM6上的应用采用的线程池都是JDK自带的线程池,之所以把成熟的Java线程池进行罗嗦说明,是因为该线程池的行为与我们想象的有点出入.Java线程池有几个重要的配置参数: corePoolSize:核心线程数(最新线程数) maximumPoolSize:最大线程数,超过这个数量的任务会被拒绝,用户可以通过RejectedExecutionHandl

性能调优

性能调优 1.设计调优 宏观层面质的优化 2.代码调优 熟悉相关API,并在合适的场景中正确使用相关API或类库,同时,对算法.数据结构的灵活运用也是代码优化的重要内容 3.JVM调优 代码和JVM属于系统微观层面量的优化 4.数据库调优 使用preparestatement代替statement提高查询效率 Select,使用要查询的具体的列名,避免使用*号, 合理地使用冗余字段 Oracle的分区表 根据不同的数据,以Oracle为例,设置合理大小的共享池.缓存缓冲区或者PGA 5.操作系统

Java性能调优笔记

Java性能调优笔记 调优步骤:衡量系统现状.设定调优目标.寻找性能瓶颈.性能调优.衡量是否到达目标(如果未到达目标,需重新寻找性能瓶颈).性能调优结束. 寻找性能瓶颈 性能瓶颈的表象:资源消耗过多.外部处理系统的性能不足.资源消耗不多但程序的响应速度却仍达不到要求. 资源消耗:CPU.文件IO.网络IO.内存. 外部处理系统的性能不足:所调用的其他系统提供的功能或数据库操作的响应速度不够. 资源消耗不多但程序的响应速度却仍达不到要求:程序代码运行效率不够高.未充分使用资源.程序结构不合理. C

Spark&amp;Spark性能调优实战

Spark特别适用于多次操作特定的数据,分mem-only和mem & disk.其中mem-only:效率高,但占用大量的内存,成本很高;mem & disk:内存用完后,会自动向磁盘迁移,解决了内存不足的问题,却带来了数据的置换的消费.Spark常见的调优工具有nman.Jmeter和Jprofile,以下是Spark调优的一个实例分析: 1.场景:精确客户群 对一个容量为300g的客户信息表在spark上进行查询优化,该大宽表有1800多列,有效使用的有20列. 2.优化达到的效果:

性能调优概述

大纲: 一.概述 二.什么是性能调优?(what) 三.为什么需要性能调优?(why) 四.什么时候需要性能调优?(when) 五.什么地方需要性能调优?(where) 六.什么人来进行性能调优?(who) 七.怎么样进行性能调优?(How) 八.总结 注,硬件配置:CUP Xeon E5620 x 2 8核心, 内存 16G , 硬盘 RAID 10,操作系统: CentOS 6.4 x86_64(64位). 一.概述 本来呢,这篇博文上个星期就应该写好了,但最近项目比较紧,晚上老是加班,于是