最近碰到的一个Java应用,费了半天劲还是没定位到是哪儿的问。发上来给大家看看,给点建议。
环境
- DB Server:32core HPUX DB2
- App Server * 2:8core HPUX WAS6.1 每个节点2个app
初次测试现象
- WAS,DB2CPU均上不去,CPU、内存、磁盘、网络等都正常。
- 从loadrunner报告来看,有两个用例很奇怪,在16/24/50用户下,呈线性增长。根据经验,这两个用例可能存在资源争用,造成串行的地方。
- 检查DB2,正常,语句执行都很快,部分用例有锁,但与造成问题的两个用例无关。
第一次尝试:初步定位是WAS的问题,针对WAS进行排查。
- 关闭WAS应用打印的日志(据观察有System.out),刚开始有往外打印东西,量不大,但是很频繁,一秒钟大概几十条,无效。
- 调整WAS监控日志为error,避免过多信息。无效。
- 后减少用户数,使用1个用户长时间跑,发现那两个用例依旧随时间线性增长。说明问题不是因为资源争用,更可能是程序问题。
- 检查WAS中的Apache,配置正常,返回页正常。
第二次尝试:定位应用程序哪块的问题
- 因为WAS跑在HPUX上,使用HPjmeter跟踪线程状态,发现线程在IO上等待事件非常高。而程序占用IO最多的地方就是数据库连接。
- 打印线程堆栈,发现大部分线程阻塞在SocketRead上。证明了HPjmeter IO占用高。
- SokcetRead阻塞,可能以下几个地方有问题:数据库(很值得怀疑,但从数据库监控看,没有问题),网络(内网环境,这个应该也不会有问题),操作系统IO部分。
第三次尝试:针对SocketRead定位问题
- 更新WAS所带JDK,无效。(JDK OK)
- 更新操作系统IO部分最新Patch,无效。(OS IO OK)
- 更新WAS的JDBC驱动,无效。(JDBC OK)
- 把WAS和DB放在同一台机器上,无效。(网络 OK)
- 通过WAS监控,其中JDBC Time很短(间接也说明了数据库正常),但是UseTime很高(是JDBC Time的100倍+)。
- 程序除了这两个用例外,其他用例均正常。
悬而未决:问题到这,进了死胡同了。也没有更好的想法。
- Use Time、JDBC Time、SocketRead的矛盾。
- JDBC Time=JDBC处理时间+网络时间+数据库处理时间。JDBC Time应该包括了JDBC的SocketRead的时间。但是JDBC Time很小,而程序阻塞在SocketRead上。
- Use Time=连接分配到连接归还的时间差=n*JDBC Time(在整个连接分配到归还之间的所有JDBC请求)+业务逻辑处理时间。
- Use Time与JDBC Time差距很大,而且JDBC Time很小,能解释的话,第一种原因,就是在整个UseTime中有大量的JDBC请求,但是从这个业务看,不会有100倍那么多。
- 第二种原因,是“业务逻辑程序处理时间”占用了很多。这个是有可能的,而且程序编写的bug也能说明为什么在1个用户的时候,用例执行时间也程序线性。但是,程序最耗时的地方出现在JDBC的SocketRead上,而JDBC Time又未反应出这部分的时间。
- 什么造成了SocketRead阻塞
- 这个问题一直没有弄清楚,在数据、网络都正常的话,Socket不应该阻塞
- WAS的Java堆调整。这个问题是在调整WAS时碰到的。
- WAS个人不是太熟,但是从一般JVM调整来说,基本是类似的,但是这次在WAS上碰到的问题也很诡异。
- WAS堆之前配置是1560m,当调整为2048m后,用例的执行时间时间反而变长了。WAS堆之前配置是1560m,当调整为1024m后,用例的执行时间时间也变长了。很神奇的问题,程序执行速度一般取决于CPU和IO,内存影响很小,特别当内存足够的情况下。即便内存有影响,两个不同方向的调整居然能得出同样的结果,很令人费解。
- 不知道是否有WAS方面的大牛给点提示:)
结论
- 应用应该是有问题的,但是更细的东西或许只有看到代码才知道
- WAS真不会用...
分享到:
相关推荐
JVM调优是一项复杂且精细的任务,涉及对Java内存模型的深入理解和掌握。通过对数据类型、堆与栈的区别以及参数传递机制的理解,可以帮助开发者更好地诊断和解决性能问题。同时,合理的调优策略能够显著提升Java应用...
ORACLE参数调优方案ORACLE参数调优方案ORACLE参数调优方案
LINUX调优
HiISP图像调优指南是一份为ISP图像质量调试而编写的指南,内部详细介绍了ISP各模块调试方法,目的是为您在开发过程中遇到的问题提供解决办法和帮助。本文档主要适用于技术支持工程师和软件开发工程师。 本文档分为...
然而,为了确保其性能最大化,数据库调优是必不可少的一环。本文将深入探讨Greenplum数据库的调优策略,主要涵盖系统资源、硬件问题、资源管理和统计信息准确性四个方面。 1. Greenplum查询处理回顾 Greenplum...
在描述中,我们得知针对高消耗SQL的排查没有发现显著问题,但进行了脚本参数调优以解决数据字段值过长导致的错误,这表明在应用层面对SQL语句进行优化是提高性能的关键步骤之一。JDBC连接数的调整表明了在多用户环境...
Tuxedo性能调优经验谈,Tuxedo性能调优经验谈
### DB2 SQL性能调优秘笈 ...通过学习这些内容,DBA们可以更加深入地理解DB2内部的工作机制,并掌握一系列有效的性能调优方法。这对于任何希望提高DB2数据库性能的专业人士而言都是一本宝贵的参考书籍。
本压缩包“oracle调优工具.rar”提供了一系列的资源,帮助用户理解和实践Oracle数据库调优。 首先,"lab128.cnt"可能是一个实验或教程的配置文件,它可能包含了一系列的调优步骤和练习,帮助用户通过实际操作来学习...
本文通过一次实际的性能调优案例,深入探讨了如何定位和解决性能问题。首先,问题起因是因为一个消息平台在二期开发完成后,在性能测试中出现了响应速度波动大,TPS(每秒事务数)和请求响应时间不稳定的情况,低谷...
在信息技术领域,调优是一项至关重要的工作,目的是为了提高系统的性能、效率和可靠性。AWK是一种编程语言,专门用于文本和数据处理,它在数据提取、分析和报告生成方面有广泛的应用。在系统调优章节中,AWK不仅可以...
MyTun是一款专门用于SQL调优的工具,它能帮助数据库管理员和开发人员更好地理解SQL查询的执行过程,识别性能瓶颈,并提供优化建议。 1. SQL调优的重要性: SQL查询优化对于任何处理大量数据的应用程序来说都是至关...
IDS性能调优是信息系统管理中的一项重要技术,它主要涉及对Informix动态服务器(Informix Dynamic Server,简称IDS)的性能进行优化。IDS是一个高性能的关系型数据库管理系统,广泛应用于企业级的数据处理和实时应用...
- **青年代(Young Generation)**:大部分对象在这里创建并快速死亡,经历一次或几次Minor GC后,存活对象晋升至老年代。 - **老年代(Old Generation)**:长期存活的对象,经历了多次Minor GC后,它们被移动...
一、操作系统调优 二、Java虚拟机调优 三、Apache集成Tomcat 四、Apache和Tomcat集群 五、Tomcat自身优化 六、APR库使用
一、物理硬件与操作系统调优 1. CPU与内存:确保服务器拥有足够的CPU资源,合理分配核心数以平衡并发处理能力。内存大小应足够存储常用数据,减少磁盘I/O。 2. 硬盘I/O:使用RAID技术提高读写速度,考虑使用SSD硬盘...
ASE系统调优技巧
### 大数据各类性能调优 #### 12.1 配置原则 在大数据环境中,合理配置资源是实现高效能的关键。以下是一些基本原则: **原则1:CPU核数分配原则** - **数据节点**: 建议预留2~4个核心给操作系统和其他进程(如...