<<上篇 | 首页 | 下篇>>

JVM 内存管理机制构成 及物理内存和虚拟内存

 

Better performance in production servers is possible with proper configuration of JVM parameters, particularily those related to memory usage and garbage collection.

unix&gt; bin/httpd.sh -Xmn100M -Xms500M -Xmx500M win&gt; bin/httpd.exe -Xmn100M -Xms500M -Xmx500M install win service&gt; bin/httpd.exe -Xmn100M -Xms500M -Xmx500M -install

 

It is good practice with server-side Java applications like Resin to set the minimum -Xms and maximum -Xmx heap sizes to the same value.

For efficient garbage collection, the -Xmn value should be lower than the -Xmx value.

 

If you monitor your java process with an OS tool like top or taskmanager, you may see the amount of memory you use exceed the amount you have specified for -Xmx. -Xmx limits the java heap size, java will allocate memory for other things, including a stack for each thread. It is not unusual for the total memory consumption of the VM to exceed the value of -Xmx.

(thanks to Rob Lockstone for his comments)

There are essentially two GC threads running. One is a very lightweight thread which does "little" collections primarily on the Eden (a.k.a. Young) generation of the heap. The other is the Full GC thread which traverses the entire heap when there is not enough memory left to allocate space for objects which get promoted from the Eden to the older generation(s).

If there is a memory leak or inadequate heap allocated, eventually the older generation will start to run out of room causing the Full GC thread to run (nearly) continuously. Since this process "stops the world", Resin won't be able to respond to requests and they'll start to back up.

The amount allocated for the Eden generation is the value specified with -Xmn. The amount allocated for the older generation is the value of -Xmx minus the -Xmn. Generally, you don't want the Eden to be too big or it will take too long for the GC to look through it for space that can be reclaimed.

See also:

Each thread in the VM get's a stack. The stack size will limit the number of threads that you can have, too big of a stack size and you will run out of memory as each thread is allocated more memory than it needs.

The Resin startup scripts (httpd.exe on Windows, wrapper.pl on Unix) will set the stack size to 2048k, unless it is specified explicity. 2048k is an appropriate value for most situations.

 

-Xss determines the size of the stack: -Xss1024k. If the stack space is too small, eventually you will see an exception .

Some people have reported that it is necessary to change stack size settings at the OS level for Linux. A call to ulimit may be necessary, and is usually done with a command in /etc/profile:

ulimit -s 2048

JDK 5 includes a number of tools that are useful for monitoring the JVM. Documentation for these tools is available from the Sun website. For JDK's prior to 5, Sun provides the jvmstat tools.

The most useful tool is jconsole. Details on using jconsole are provided in the Administration section of the Resin documentation.

win> ./httpd.exe -Dcom.sun.management.jmxremote unix> bin/httpd.sh -Dcom.sun.management.jmxremote ... in another shell window ... win> jconsole.exe unix> jconsole Choose Resin's JVM from the "Local" list.

jps and jstack are also useful, providing a quick command line method for obtaining stack traces of all current threads. Details on obtaining and interpreting stack traces is in the Troubleshooting section of the Resin documentation.

# jps 12903 Jps 20087 Resin # jstack 20087 Attaching to process ID 20087, please wait... Debugger attached successfully. Client compiler detected. JVM version is 1.5.0-beta2-b51 Thread 12691: (state = BLOCKED) - java.lang.Object.wait(long) (Compiled frame; information may be imprecise) - com.caucho.util.ThreadPool.runTasks() @bci=111, line=474 (Compiled frame) - com.caucho.util.ThreadPool.run() @bci=85, line=423 (Interpreted frame) - java.lang.Thread.run() @bci=11, line=595 (Interpreted frame) Thread 12689: (state = BLOCKED) - java.lang.Object.wait(long) (Compiled frame; information may be imprecise) - com.caucho.util.ThreadPool.runTasks() @bci=111, line=474 (Compiled frame) - com.caucho.util.ThreadPool.run() @bci=85, line=423 (Interpreted frame) - java.lang.Thread.run() @bci=11, line=595 (Interpreted frame) ...

 

阅读全文……

标签 : ,

程序员浪费生命的几种方式

程序员应该要爱惜生命,做有用有意义的事情。做有用的事情,有两种方式,一、做一个对用户真正有价值的项目,这个项目是真正有意义有用的;二、朝正确的方向以正确的方式做项目。但是程序员会遇到很多失败的项目,这些系统要么是没有人用没有真正价值,要么是以不正确的方式做项目,使用不当的技术,例如,用报表工具代替查询、用ESB企业总线当作海量数据传输用,或者做一些没有实际用途的功能,如做一个万能的用户自定义查询系统、做用户自定义工作流工具、做用户自定义报表工具,这些项目无疑在浪费程序员的生命。笔者试图总结程序员浪费生命的几种方式,如下。

1、开发一个质量和性能很差的系统

程序员经常会碰到这样的项目,做出来的系统质量很差,操作无反馈,失败无提示,而且速度很慢,操作时不时要等一会儿。然而,关键是程序员没有机会或者不想参与实施和维护,失去了学习和诊断问题的机会。

2、花费大量人力财力开发一个一次性的项目

这是从事应用开发程序员经常碰到的情况,为某个客户定制化开发一个一次性的项目,然而这个项目要花费巨大的人力成本,最终开发维护周期很长,以巨大亏本收尾或无法收尾。

3、开发一个很漂亮花哨的无人用的系统

这也是当前常见的情况,客户要做一个亮点政绩工程,要做一个界面漂亮花哨“很炫”的系统,各种图表,各种交互方式、各种监控分析全部堆上,但最终这样的系统是没有人用的。这只是给领导或客人参观用的。

4、全新开发一个原有遗留的系统

程序员的领导要基于原有的系统重新做一个产品,大幅提升可维护性可扩展性,增加系统的稳定性,减少系统故障。领导决定召集人马,重新进行需求调研,需求分析,架构设计、编码开发测试。但是,这样的事情一再重复,同样类似的需求给不同的客户做了一套又一套新的系统,而且每个系统过一段时间后故障不稳定的情况依旧。各种版本、各种代码库留给了程序员......程序员需要持续给不同客户维护不同版本的系统。

5、开发一个项目范围不确定的系统

程序员所在的项目,没有人管理项目范围,没有WBS,用户提一点做一点,项目完全没有合同或契约约束,用户要做的越来越多,系统做得越来越大,最终无法控制,客户不满意,程序员也累得半死,试图讨好客户争取更大项目的计划失败。

6、开发一个没有系统角色或涉众的系统

程序员做的这个项目,虽然都有需求、有功能、有界面,但是奇怪的是,需求没有提到,也没有人知道这些功能是什么人用的。需求没有定义出系统的角色,以及角色所要参与的业务活动。然而这样的项目也不少见,

7、开发一个使用环境不确定的项目

程序员做的企业应用项目,不知道是给电脑用的还是给移动设备用的,不知道是给IE用的还是其他浏览器用的,不知道是给IE6用的还是IE10用的,不能确定浏览器平台版本。移动设备不知道是iOS还是Android,Android不知道是2.3的还是4.0的,也不能确定手机或平板电脑型号。我们知道,中等规模的企业应用都会比互联网应用要复杂很多,几乎不可能覆盖所有用户的使用终端平台,要做一个优秀系统必须有约束条件,有使用的目标平台。

针对以上各种情况,程序员经常是没办法干预的,因为,要么这是客户明知故犯的行为,要么是公司部门的战略行为,要么是由于项目经理基本的技能职责缺乏。当然程序员可以假设自己是项目经理,考虑该如何做好这些项目并适时适当的提出问题或解决办法,以免浪费自己的生命。转载请保留 IT瘾原文链接。

 

SQL执行计划 Execution plan with Derby

CALL SYSCS_UTIL.SYSCS_SET_RUNTIMESTATISTICS(1);

select * from EDW_BPM_OBJECT;

call SYSCS_UTIL.SYSCS_SET_RUNTIMESTATISTICS(0);

VALUES SYSCS_UTIL.SYSCS_GET_RUNTIMESTATISTICS();

 

标签 : ,