性能优化
文章平均质量分 81
cpzhong
程序员,对系统架构、敏捷项目管理、前端开发有着浓厚的兴趣。
展开
-
性能调优三步走
在性能调优前,我们首先需要制定性能调优目标(响应时间和TPS),这个可以根据业务场景,线上服务器集群配置等来确定。确定好目标就可以准备数据、压力测试脚本了,这些都完成后就一个一个场景进行测试,对不能达到目标的场景再寻找瓶颈所在,那么如何来找到瓶颈呢?概括来说就是使用排除法,比如说在应用程序层面,可以将怀疑有性能瓶颈的代码注释起来,再跑一次测试脚本,看响应时间和TPS的变化,直到找到最终瓶颈所在的代码块。 调优时可以从以下三个层面入手:1. 应用程序优化应用程序优化主要指的是从应用代原创 2011-05-31 17:39:00 · 968 阅读 · 0 评论 -
java编程中影响性能的一些点
本次迭代,在做一些代码的优化和重构,网上整理的一篇文章,推荐大家看看,平常编码中加以应用,红色标注的点是我认为在现在的项目开发中需要特别注意的,有不同意见的点欢迎大家一起讨论。原文地址:http://blog.csdn.net/kome2000/archive/2010/04/2转载 2011-07-12 19:13:27 · 3259 阅读 · 0 评论 -
JVM垃圾收集器异同
JVM 垃圾收集器有3类,这里主要介绍我们常用的 并行和并发收集器:The Throughput Collector (也叫并行收集器)串行收集器在GC时会停止其他所有工作线程(stop-the-world),CPU利用率是最高的,所以适用于要求高吞吐量(throughp原创 2011-09-30 17:12:31 · 6064 阅读 · 0 评论 -
记一次JVM GC日志分析
这几天在准备升级JDK版本到1.6,对目前线上JVM(版本是1.5.0_08-b03) GC日志进行了分析,发现一些参数设置不太合理的地方,有待后续通过数据来进行验证。1.原始GC日志(通过JVM配置GC Print参数获取GC日志)...695.775: [GC 695.776: [ParNew: 130944K->0K(131008K), 0.0174100 secs] 43296原创 2011-09-29 22:30:34 · 22897 阅读 · 3 评论 -
为什么CMS GC时出现Concurrent Mode Failure?
并发收集器(concurrentcollector)指的是回收年老代和持久代时,采用多个线程和应用线程并发执行,减少应用停顿时间,但如果参数设置不当,容易出现Concurrent ModeFailure现象,此时JVM将采用停顿的方式进行full gc,整个gc时间相当可观,完全违背了采用CMS GC的初衷。 出现此现象的原因主要有两个:一个是在年老代被用完之前不能完成对无引用对象的回收原创 2011-10-27 22:59:41 · 32998 阅读 · 1 评论 -
JVM GC的几个叫法
根据GC所处的代,试图将GC叫法归纳如下:young generationyoung gc == minor gctenured generationold gc == cms gc == major gc == full gc full gc都是串行方式的,耗时很长,所以我们需要尽量减少发生频次。原创 2011-09-30 17:32:02 · 1333 阅读 · 0 评论 -
如何抓获JVM crash的幕后黑手?(一)
最近几天线上jboss服务器经常莫名地突然停止运行,导致半夜都被报警短信吵醒,元旦几天也基本就在收报警,然后重启系统。查看jboss控制台错误日志,发现只有下面一行:/opt/.../jboss/bin/run.sh: line 181: 26430 段错误 "$JAVA" $JAVA_OPTS -Djava.endorsed.dirs="$JBOSS_END原创 2012-01-11 14:35:20 · 25021 阅读 · 0 评论 -
如何抓获JVM crash的幕后黑手?(二)
其实通过上一篇所讲的core dump方法可以比较方便找到jvm crash问题所在,但这种方法适合crash比较频繁,容易获取到core dump文件,如果没有这个文件,那怎么可以查到问题呢。现在回过头想想通过跟踪crash时的apache日志,其实也能找到造成crash的请求,下面是某次crash时的日志:[07/Jan/2012:07:52:40 +0800] "GET /a.xhtml原创 2012-01-12 13:23:28 · 2676 阅读 · 0 评论 -
如何抓获JVM crash的幕后黑手?(三)
通过前两篇如何抓获JVM crash的幕后黑手?(一) 如何抓获JVM crash的幕后黑手?(二)的分析,如果还不能查到原因,那很有可能不是应用自身的问题,而是系统将应用强行kill了,如何判断是系统强行kill的呢? 我们需要先了解下linux的一个oom-killer机制。linux oom-killer是一种自我保护机制,当系统分配不出内存时会触发这个机制,由操作系统在己原创 2013-01-30 22:21:12 · 1638 阅读 · 0 评论