windows和linux下Tomcat内存的分配与溢出的配置详解

刺骨的言语ヽ痛彻心扉 2022-08-22 12:30 82阅读 0赞

原文：[windows和linux下Tomcat内存的分配与溢出的配置详解][windows_linux_Tomcat]

源代码下载地址：[http://www.zuidaima.com/share/1795452574026752.htm][windows_linux_Tomcat]

~以下给出1G内存环境下java jvm 的参数设置参考：

JAVA_OPTS=”-server -Xms800m -Xmx800m -XX:PermSize=64M
    -XX:MaxNewSize=256m -XX:MaxPermSize=128m -Djava.awt.headless=true ”
    JAVA_OPTS=”-server -Xms768m -Xmx768m -XX:PermSize=128m
    -XX:MaxPermSize=256m -XX:NewSize=192m -XX:MaxNewSize=384m”
    CATALINA_OPTS=”-server -Xms768m -Xmx768m -XX:PermSize=128m
    -XX:MaxPermSize=256m
    -XX:NewSize=192m -XX:MaxNewSize=384m”

Linux：

在/usr/local/apache-tomcat-5.5.23/bin目录下的catalina.sh  
添加：JAVA\_OPTS=’-Xms512m -Xmx1024m’  
要加“m”说明是MB，否则就是KB了，在启动tomcat时会报内存不足。  
\-Xms：初始值  
\-Xmx：最大值  
\-Xmn：最小值

Windows  
在catalina.bat最前面加入

set JAVA_OPTS=-Xms128m -Xmx350m

如果用startup.bat启动tomcat,OK设置生效.够成功的分配200M内存.

但是如果不是执行startup.bat启动tomcat而是利用windows的系统服务启动tomcat服务,  
上面的设置就不生效了,  
就是说set JAVA\_OPTS=-Xms128m -Xmx350m 没起作用.  
上面分配200M内存就OOM了..  
windows服务执行的是bin\\tomcat.exe.他读取注册表中的值,而不是catalina.bat的设置.  
解决办法:  
修改注册表HKEY\_LOCAL\_MACHINE\\SOFTWARE\\Apache Software Foundation  
\\Tomcat Service Manager\\Tomcat5\\Parameters\\JavaOptions  
原值为  
\-Dcatalina.home=”C:\\ApacheGroup\\Tomcat 5.0″  
\-Djava.endorsed.dirs=”C:\\ApacheGroup\\Tomcat 5.0\\common\\endorsed”  
\-Xrs  
加入 -Xms300m -Xmx350m  
重起tomcat服务,设置生效  
（Tomcat 5.5 的话，在Apache Software Foundation下有个Procrun 2.0的 Tomcat5\\Parameters\\Java下  
设置JvmMs和JvmMx的值就可以了，要修改10进制的值哦）

不过，OS对内存也有限制

附：如何获得JVM的最大可用内存

在命令行下用 java -XmxXXXXM -version 命令来进行测试，然后逐渐的增大XXXX的值，如果执行正常就表示指定的内存大小可用，否则会打印错误信息。

实际发现版本上有细微差别的JDK最大容许内存值都不尽相同，因此在实际的应用中还是要自己试验一下看到底内存能达到什么样的值。

通过这个表想说明的是，如果你的机器的内存太多的话，只能通过多运行几个实例来提供机器的利用率了，例如跑Tomcat，你可以多装几个Tomcat并做集群，依此类推。

这个人家测试的结果，我这里引用一下

公司 JVM版本 最大内存(兆)client 最大内存(兆)server  
SUN 1.5.x 1492 1520  
SUN 1.5.5(Linux) 2634 2660  
SUN 1.4.2 1564 1564  
SUN 1.4.2(Linux) 1900 1260  
IBM 1.4.2(Linux) 2047 N/A  
BEA JRockit 1.5 (U3) 1909 1902

所以跟OS的系统版本，jdk版本有很大的关系。要是希望充分利用内存，就考虑使用集群。

一、在tomcat的catalina.bat中修改，加入-Dcom.sun.management.jmxremote参数

set JAVA_OPTS=%JAVA_OPTS% -Dcom.sun.management.jmxremote

二、需要使用jdk5.0以上，打开bin目录下的jconsole.exe，即可连接跟踪tomcat的内存使用情况

内存溢出的处理办法:

常见的一般会有下面三种情况：  
        1.OutOfMemoryError: Java heap space  
        2.OutOfMemoryError: PermGen space  
        3.OutOfMemoryError: unable to create new native thread.  
对于前两种情况，在应用本身没有内存泄露的情况下可以用设置tomcat jvm参数来解决。（-Xms -Xmx -XX:PermSize  -XX:MaxPermSize）  
最后一种可能需要调整操作系统和tomcat jvm参数同时调整才能达到目的。  
第一种：是堆溢出。  
        在JVM中如果98％的时间是用于GC且可用的 Heap size 不足2％的时候将抛出此异常信息。  
        没有内存泄露的情况下，调整-Xms -Xmx参数可以解决。  
        -Xms:初始堆大小  
        -Xmx:最大堆大小  
        但堆的大小受下面三方面影响：  
        1.相关操作系统的数据模型（32-bt还是64-bit）限制；（32位系统下，一般限制在1.5G~2G；我在2003 server 系统下（物理内存：4G和6G，jdk：1.6）测试 1612M，64为操作系统对内存无限制。）  
        2.系统的可用虚拟内存限制；  
        3.系统的可用物理内存限制。  
        堆的大小可以使用 java -Xmx\*\*\*M  version 命令来测试。支持的话会出现jdk的版本号，不支持会报错。  
         -Xms -Xmx一般配置成一样比较好比如set JAVA\_OPTS= -Xms1024m -Xmx1024m  
第二种：永久保存区域溢出  
        PermGen space的全称是Permanent Generation space,是指内存的永久保存区域。这一部分用于存放Class和Meta的信息,Class在被 Load的时候被放入PermGen space区域，它和和存放Instance的Heap区域不同,GC(Garbage Collection)不会在主程序运行期对PermGen space进行清理，所以如果你的APP会LOAD很多CLASS的话,就很可能出现PermGen space错误。这种错误常见在web服务器对JSP进行pre compile的时候。但目前的hibernate和spring项目中也很容易出现这样的问题。http://www.javaeye.com/topic/80620?page=1 的帖子有讨论的这个问题。可能是由于这些框架会动态class，而且jvm的gc是不会清理PemGen space的，导致内存溢出。  
        这一个一般是加大-XX:PermSize  -XX:MaxPermSize 来解决问题。  
        -XX:PermSize 永久保存区域初始大小  
        -XX:PermSize 永久保存区域初始最大值  
        这一般结合第一条使用，比如 set JAVA\_OPTS= -Xms1024m -Xmx1024m  -XX:PermSize=128M -XX:PermSize=256M  
        有一点需要注意：java -Xmx\*\*\*M  version 命令来测试的最大堆内存是 -Xmx与 -XX:PermSize的 和 比如系统支持最大的jvm堆大小事1.5G，那  -Xmx1024m  -XX:PermSize=768M 是无法运行的。  
第三种：无法创建新的线程。  
        这种现象比较少见，也比较奇怪，主要是和jvm与系统内存的比例有关。  
        这种怪事是因为JVM已经被系统分配了大量的内存(比如1.5G)，并且它至少要占用可用内存的一半。有人发现，在线程个数很多的情况下，你分配给JVM的内存越多，那么，上述错误发生的可能性就越大。  
        产生这种现象的原因如下（从这个blog中了解到原因：http://hi.baidu.com/hexiong/blog/item/16dc9e518fb10c2542a75b3c.html）：  
        每一个32位的进程最多可以使用2G的可用内存，因为另外2G被操作系统保留。这里假设使用1.5G给JVM，那么还余下500M可用内存。这500M内存中的一部分必须用于系统dll的加载，那么真正剩下的也许只有400M，现在关键的地方出现了：当你使用Java创建一个线程，在JVM的内存里也会创建一个Thread对象，但是同时也会在操作系统里创建一个真正的物理线程(参考JVM规范)，操作系统会在余下的400兆内存里创建这个物理线程，而不是在JVM的1500M的内存堆里创建。在jdk1.4里头，默认的栈大小是256KB，但是在jdk1.5里头，默认的栈大小为1M每线程，因此，在余下400M的可用内存里边我们最多也只能创建400个可用线程。  
        这样结论就出来了，要想创建更多的线程，你必须减少分配给JVM的最大内存。还有一种做法是让JVM宿主在你的JNI代码里边。  
给出一个有关能够创建线程的最大个数的估算公式：  
        (MaxProcessMemory - JVMMemory - ReservedOsMemory) / (ThreadStackSize) = Number of threads  
        对于jdk1.5而言，假设操作系统保留120M内存：  
        1.5GB JVM: (2GB-1.5Gb-120MB)/(1MB) = ~380 threads  
        1.0GB JVM: (2GB-1.0Gb-120MB)/(1MB) = ~880 threads  
        在2000/XP/2003的boot.ini里头有一个启动选项，好像是：/PAE /3G ，可以让用户进程最大内存扩充至3G，这时操作系统只能占用最多1G的虚存。那样应该可以让JVM创建更多的线程。  
        因此这种情况需要结合操作系统进行相关调整。  
因此：我们需要结合不同情况对tomcat内存分配进行不同的诊断才能从根本上解决问题。

[windows_linux_Tomcat]: http://www.zuidaima.com/share/1795452574026752.htm