|
第四章 操作系统调优4.1 操作系统调整
操作系统影响应用程序运行性能的因素主要有：硬件的配置(CPU、内存、硬盘等),核心参数,TCP/IP参数以及补丁的情况等。这里对操作系统的优化,除了更新最新的补丁程序以保证应用程序正常运行之外,就是调整TCP/IP参数,文件描述符,对于个别操作系统还有其他特别的参数调整。下面将依次介绍不同操作系统的情况,更多的信息请参考各操作系统的文档。4.1.1 HP-UX
对于HP-UX,你首先需要安装Java Patch:
http://www.hp.com/products1/unix/java/patches/index.html,然后需要确认下面文档中的核心参数是否满足(可以使用sam命令修改核心参数):http://e-docs.bea.com/platform/suppconfigs/configs81/hpux11_risc/81sp3.html#80105。
调整TCP参数: ndd -set /dev/tcp tcp_conn_req_max 1024, 将侦听队列的最大允许长度调整到1024。 有时操作系统限制进程使用的最大内存数小于你要配置的内存大小,则需要调整该值。
读者可以从http://docs.hp.com/hpux/onlinedocs/TKP-90203/TKP-90203.html了解更多的HP-UX调整建议。4.1.2 Solaris
调整TCP的参数,等待时间间隔tcp-time-wait-interval建议设置为60000ms: /usr/sbin/ndd ?set /dev/tcp tcp_time_wait_interval 60000;
其他参数调整如下:
tcp_xmit_hiwat/tcp_recv_hiwat 131072
tcp_conn_req_max_q/tcp_conn_req_max_q0 16384
调整一个进程打开的文件描述符的数量:软限制和硬限制以及散列表的大小,修改/etc/system文件:
set tcp:tcp_conn_hash_size=32768
set rlim_fd_cur=8192
set rlim_fd_max=8192
更多的调整信息请查阅: http://docs.sun.com/db/doc/806-7009(Solaris9)。4.1.3 AIX
AIX用no命令调整TCP参数，等待时间间隔tcp_timewait: no -o tcp_timewait=4,将tcp.timewait参数设置为4个15秒间隔，即1分钟。运行no -a命令将显示网络当前的所有属性值。由于UDP_SENDSPACE默认的缓存大小是8k,为减少I/O异常,需调整为32k:
no -o udp_sendspace=32768。此外, 当WebLogic HTTP请求忙时,可以调整侦听队列的最大长somaxconn到8192(默认值是1024)。
更多信息:http://publib16.boulder.ibmo.com/pseries/en-us/aixbman/prftungd/prftungd.htm。4.1.4 Linux
调整Linux系统使用sysctl命令修改TCP参数等待时间间隔:sysctl -w ip_ct_tcp_timeout_time_wait=60;调整打开文件的最大数:在/etc/sysctl.conf文件中，添加: Fs.file-max=65535,然后运行sysctl -p;调整打开文件描述符最大数为8192:在/etc/security/limits.conf文件，添加:WebLogic hard nofile 8192(仅针对WebLogic用户),然后在WebLogic启动文件里运行ulimit-n 8192激活设置。
更多信息请查阅:http://ipsysctl-tutorial.frozentux.net/ipsysctl-tutorial.html。4.1.5 Windows
Windows系统的调整通过修改注册表HKEY-LOCAL-MACHINESYSTEMCurrent ControlSetServices文件夹来完成。可以调整TcpipParameters子文件夹中的等待时间间隔时间 TcpTimedWaitDelay参数的值。侦听队列最大长度的默认值为15，为修改它，可在InetinfoParameters子目录中创建 DWORD条目ListenBackLog。
此外,Windows2000的Service Pack(要求sp3以上)也会影响系统稳定性: http://e-docs.bea.com/platform/suppconfigs/configs81/win2ksvr_as_data_pentium/81sp3.html。第五章 性能监控和性能分析5.1 性能瓶颈
最后,介绍一下实际分析J2EE应用性能的常用命令和工具。对于实现一个高性能的J2EE应用来说,掌握了J2EE调优的理论经验还是不够的。掌握性能监控,发现瓶颈和问题诊断才是保证J2EE系统持续高效运行的关键。
瓶颈指的是限值所有吞吐操作以及严重影响反应时间的系统内资源。在分布式系统内寻找并纠正瓶颈是非常困难的，需要有经验的团队来解决。瓶颈会发生在Web 服务器上，程序代码中，应用服务器上，数据库，操作系统或者网络，硬件上。经验表明，瓶颈很容易发生在如下地方：数据库连接与队列中；应用服务器的程序代码中；应用服务器和Web服务器硬件上；网络和TCP配置中。实际中可以着力对这些环节进行监控。
5.2 操作系统监控
操作系统层面的性能监控主要是对内存、CPU、I/O和交换区的使用情况进行监控分析。windows平台可以通过任务管理器和perfmon工具查看。如果是unix系统可以使用stat系列命令(vmstat, mpstat, iostat)监控内存、CPU和I/O的即时变化,使用swap命令查看交换区的使用情况。如果操作系统安装了top、topas、glance等使用工具,则使用top、topas、glance将能更为方便地看到WebLogic进程对操作系统的内存,CPU和I/O资源使用的即时变化情况。
而网络方面的性能可以通过ping和netstat等命令来监控,主要几个关键的网络统计值,如数据包再发送、重复数据包和数据包侦听丢失。
说明:本文提到的unix命令并非适用所有操作系统,仅供参考。5.3 数据库监控
数据库层面的监控这里为oracle9i为例来说明,可以采用oracle自带的工具Oracle
Interprise Manager Console来监控session和sql的执行情况。还有其他专业的数据库监控工具可以使用,比如QUEST的spotlight(http://www.quest.com/spotlight-portal/)可以非常形象和直观地对Oracle数据库的CPU、内存、I/O、Data Buffer Size、Shared Pool Size、Redo Buffer等参数进行即时监控,并自动对不正常的参数以红色显示。5.4 WebLogic监控
5.4.1 JVM监控 采用java参数-verbose:gc 来分析JVM的GC非常繁琐，而且不直观。使用-Xloggc:gc.log 参数将GC日志写入文件,采用GC 工具HPjtune (http://www.javaperformancetuning.com/tools/hpjtune/index.shtml)进行分析,可以轻松看出当前jvm参数配置是否合理。
严格意义上来说HPjtune是一个分析工具,不是监控工具。这里不得不提及jRocket,Intel平台上最快的JVM, 在WebLogic启动命令中增加-Xmanagement参数,就可以执行bea/jrockit81sp3_142_04/bin下console命令监控WebLogic的内存使用和CPU负载情况。设置Tools/Preferences菜单中的Mode of operation属性为developer, jRocket将提供Method Profiler工具，她能够将所有在JRockit Java虚拟机上执行的成员方法的调用次数、执行的总时间和每次调用的执行时间都统计出来，进行代码级调优，这是jRockit的又一大优势。
5.4.2 Console监控
WebLogic Console除了管理配置功能之外,提供了丰富的监控功能。通过WebLogic Console，首先我们可以查看服务器的运行情况。
5.4.2.1 Server监控
通过使用服务器的Performance Monitoring选项卡，可以查看到请求吞吐量，执行队列积压情况以及JVM栈利用情况。而通过点击Performance Genaral选项卡中” Monitor all Active Queues...”可以查看所以执行线程的当前统计数据。此外Monitoring选项卡还可以监控JTA和JMS等Service的情况。
5.4.2.2 JDBC监控
在连接池Monitoring选项卡中，WebLogic Console为每一个数据库连接池提供了实时统计信息。其中有三个重要参数可以反应WebLogic Server的健康状况：Connections High、Wait Second High和Waiters High。Connection High表示从服务器启动开始后到达池的最大连接数量，如果大于池的最大数量，则需要调整Maxium Capacity。Waiters High表示在没有可用连接的情况下，应用程序等待连接的最大个数。我们可以根据Waiters High的大小调整连接池容量。更多的参数可以通过Customize this view链接添加,参数含义参考:http://e-docs.bea.com/wls/docs81/ConsoleHelp/domain_jdbcconnectionpool_monitor.html#1104829。
5.4.2.3 WEB监控
Web Application Monitoring选项卡可以监控WEB应用的Session个数,以及Servlet的响应情况,激活Session Monitoring Enabled可以获取所有session的统计情况。更多信息请参考:
http://e-docs.bea.com/wls/docs81/ConsoleHelp/web_applications.html#1106723。
5.4.2.4 JMS监控
Welogic Console JMS监控功能比较多,不仅在Server JMS Monitoring选项卡可以监控Active JMS Connections, Pooled JMS Connections和Active JMS Servers的连接和使用情况。还可以监控JMS Session Pool、Active JMS Destinations和Durable Subscribers的消费和生产情况。比如,我们可以监控到JMS Queue的接收和消费消息的数量和字节数。有关JMS监控的详细情况可参见:http://edocs.bea.com/wls/docs81/ConsoleHelp/jms_monitor.html。
5.4.2.5 EJB监控
EJB监控包括对SLSB,SFSB,Entity Bean,MDB四种EJB的监控。本人认为EJB监控提供了非常丰富的运行时统计信息(http://e-docs.bea.com/wls/docs81/ConsoleHelp/ejb.html#1105036),非常有利于我们对EJB进行性能调优。
SLSB选项卡为用户提供实例池的运行时统计信息。Pool Miss Ratio 表示实例池的Miss率,Pool Waiter Total Count 表示线程等待bean 实例的累计时间,Pool Timeout Total Count表示超时的线程数。当Pool Miss Ratio较大时,可以增加max-beans-free-pool。
SFSB可以关注Cache Miss Ratio和Activation Count。Cache Miss Ratio过大时,调大max-bean-in-cache未必有帮助,需要尝试不用的max-bean-in-cache以获得最低的Cache Miss Ratio。激活将严重减慢应用程序的速度,如果某一个bean的Activation Count的值过高，那么需要考虑增加max-bean-in-cache的大小。
Entity Bean结合了SLSB的free pool和SFSB的cache。可以结合上面的策略进行监控。
而MDB仅比SLSB多一个参数JMSConnection Alive,报告EJB是否成功连接到JMS目的地。
更多Console监控信息可参见http://edocs.bea.com/wls/docs81/ConsoleHelp/index.html。
5.4.3 实用工具分析
WebLogic除了提供Console进行应用监控之外,用户还可以编写JMX程序或者通过SNMP协议进行监控。而QUEST Spotlight for WebLogic Server提供了类似WebLogic Console类似的监控功能,并对异常情况显红。
这里不得不提到实战中经常用来分析性能瓶颈的工具THREAD DUMP,统一的命令是使用 weblogic.Admin 命令 THREAD_DUMP。而在 windows上还可以使用+ 来创建诊断问题所需的线程转储Thread Dump,而在unix上使用kill -3 命令。我们从中可以看到WebLogic后台线程的运行情况,通常需要每隔10秒左右持续执行几次以助诊断问题。更多信息可以参考BEA实战集锦。
5.5 应用程序分析
应用程序分析除了凭借程序员丰富的经验和敏锐的洞察力去人工检查代码之外,使用厂家的工具也是节省时间的不错选择。目前市场上有Borland Optimizeit Enterprise Suite和QUEST Jprobe两个产品可以用来分析性能瓶颈,垃圾收集,内存泄漏,线程死锁和代码复盖等。Hpjmeter是一个免费的工具,也具有以上类似的性能分析功能。
而Borland Optimizeit Server Trace,HP OpenView Transaction Analyzer和Mercury LoadRunner J2EE breakdown都可以用来分解J2EE应用从客户端访问到最终数据库操作每一层次花费的时间,甚至精确到每一个方法的执行时间。Server Trace还具有检查内存泄漏，连接泄漏和错误警告等功能,一般在测试环境中使用。而HP OTVA的优势在于运行时监控,LoadRunner优势在于压力测试。
总结
J2EE调优是一门实践和经验科学，是一个复杂而往复的过程。其原则是：合理。合理,看似简单,细细品味,意味深长。本文所述的调优策略并不是一成不变的，只是为了给大家一个参考建议，让大家少走弯路，关键是根据实际环境调优。欢迎有兴趣的朋友在论坛上积极讨论和批评指正。
上一页
|
