【WAS入门开窍班】WAS性能调优大家谈！(官方第3问)

1. verboseGC 日志分析，通过在 WebSphere 管理控制台的java进程属性里勾选“详细垃圾回收”，然后到 native_stdout.log 中去找详细的 GC 信息。如果要进一步分析，可以使用 PMAT 工具。

2. 线程转储分析，那些线程在 Pending 的状态？线程转储是一个 javacore 文件，使用 ThreadAnalyzer 可以进行深入分析。

3. 堆转储分析，堆转储就是 Dump 文件，可以使用 Memory Dump Diagnostic for Java 工具 (MDD4J) 进行分析。 收起

补充一些细节。

1. 如果 WebSphere 反应过慢，应该首先看看是因为刚刚部署的 EAR 或者 WAR 导致这样的情况，还是陈年累积导致这样的情况。

2. 如果是后者，那就需要拿到 Java Core 文件和 Dump 文件做分析。在没有确切的分析之前，先不要着急修改 JVM 的各项参数，又或者是 IHS 中配置文件的参数。

3. 有没有人可以说一下在 Solaris Unix 下如何拿到这两个文件，kill -3 在 Solaris 下不管用；还有，文件拿到之后用什么工具进行分析，工具到何处可以得到。谢谢。 收起

调优是个漫长的过程，按着上文所述的原则 收起

调优是个漫长的过程，按着上文所述的原则，对不同的应用的应用摸索出最佳的运行配置。

除了对WAS的调整，我觉得还有必要对于web的前端做出优化，特别是面向Internet的应用。否则你后台优化半天，却因为没考虑到网络环境而导致速度慢是很得不偿失的。应用最好能做到动静分离，这样可以更好的利用Apache对静态页面做优化。http://developer.yahoo.com/performance/rules.html 这篇文章很不错，总结了网站优化的34条建议，http://www.dbanotes.net/web/high_performance_web_site.html 这里则是大牛《高性能网站建设指南》读后随感。当然后面这些不是程序员所要负责的范围，但是要引起关注，因为相比中间件和数据库的优化，这一层是比较容易被忽视的。 收起

总体的思想如下：

Ø无论如何，应该先保证做到应用程序调优，这是提高性能最显著的方法。比如：如果应用程序设计有问题，比如：数据库查询没有where语句，导致返回的结果集过大，容易引起OutOfMemory；比如wait()过长的时间；比如应用程序设计会导致死锁；比如巨大的HTTPSession；比如cache过多的数据等等，都是导致性能下降的最直接原因。

然后再考虑WAS调优。调优时，有几点要考虑：
1) Getting a baseline performance number and then set the tuning objective (吞吐量, 平均响应时间等)
2) Write down your tuning log - A log of what you changed and why you changed it.

3) Monitoring your environment
CPU utilization (Top command , vertical and horizontal scale-up of CPUs)
Memory utilization (top/vmstat commands)
         - The "swap" field should be zero -- if it is not, then the operating system is simulating the presence of more RAM by using disk space, which is of course a slow process.


4) Turn on Verbose GC, Based on Verbose GC log. Ideally, the GC cycle:
GC occurs at intervals longer than 10 seconds or so
GC takes 1 to 2 seconds or so to complete




5) JVM settings – change heap size

Goal: make the heap large enough to make the GC interval longer than 10 seconds, but small enough so the duration is only 1 to 2 seconds.
Notes: With each new JVM version, GC algorithms improve, so this tuning should become easier over time.



6) Connection pool settings

Usually,

The "sweet spot" for a small (4 CPU) database server is servicing 100-200 connections.
WebSphere acts as a connection concentrator in front of the database server. The connection pool size restricts how many database connections are held open to service incoming page requests.
Actions:
If your application uses all available connections, there may be an unmet demand for more connections.
Detect unmet demand by reading the javacore or by increasing the number of connections and seeing when the application server stops asking for more.
If the number of connections is the same or greater than the number of WebSphere client users, it is time to search the application for some sloppy code – connection leak?


7) Turning on servlet caching
For WebSphere Application Server, The Performance Adviser was kind enough to suggest turning on servlet caching, and performance improved.  TPV shows graphical output of PMI.


8) Thread pool count
Sometimes, We need to increase the thread pool in order to keep the CPU entertained.
But remember, a CPU can only drive 50 to 75 Java threads.






收起

LS那文章很不错，http://www.ibm.com/developerwork ... rie/0602_lurie.html
放上中文版更加好 收起

有一篇文章很古老，但是很好：
http://www.ibm.com/developerwork ... rie/0602_lurie.html 收起

IHS的调优可以参考 http://httpd.apache.org/docs/2.2/misc/perf-tuning.html 收起

可以看到IHS使用了 Multi-Processing Modules (MPMs)的worker方式来提供服务——多个子进程，每个子进程再派生出很多线程，每个线程处理一个连接。所以ThreadsPerChild设置了每个子进程可以派生的线程数，总共能提供的并发数则由MaxClients限制。这些设置是对Unix-type systems下生效，对于Windows平台，只有一个进程，所以是ThreadsPerChild确定最大访问量 收起

好东西:lol 收起