Service Temporarily Unavailable
The server is temporarily unable to service your request due to maintenance downtime or capacity problems. Please try again later.
Apache/2.0.59 (Unix) Resin/3.1.12 Server at ad2.easou.com Port 80
可以尝试
解决方案
1 这是因为用户站点使用的带宽超过了设定的最高限额引起的。
为了不显示这个错误信息,可以在apache(Unix平台最流行的WEB服务器平台)的配置中加上一个配置,当超出带宽时,让访问变慢,而不是立即显示错误信息。
编辑/usr/Prima(最完善的虚拟主机管理系统)/apache(Unix平台最流行的WEB服务器平台)_ssl/conf/httpd.conf,找到<IfModule mod_throttle.c>,在块中加入
ThrottleMaxDelay 0
重起apache(Unix平台最流行的WEB服务器平台):
/etc/init.d/httpd restart
还可以编辑一个显示服务器忙的html文件,放到/www/icons/busy.html,在httpd.conf中加入:
ErrorDocument 503 /icons/busy.html
出现OutOfMemoryException的解决方法
出现OOM异常大多数是因为分配给Resin的内存过小造成的,这个时候可以使用以下命令增大Resin的内存:
unix> bin/httpd.sh -Xmn100M -Xms500M -Xmx500M
win> bin/httpd.exe -Xmn100M -Xms500M -Xmx500M
install win service> bin/httpd.exe -Xmn100M -Xms500M -Xmx500M -install
这样就可以设置Resin使用的内存了
[开发]resin+spring+struts配搭在线上常见的三个问题
http://blog.chinaunix.net/uid-20787846-id-3471983.html
1、文件句柄数问题
现象1:访问页面出现500错误,错误描述为:java.lang.NoClassDefFoundError,后面跟的类名各式各样不一一列举了。
现象2:Resin被Wathcdog自动重启,日志中表明这是因为:Resin shutdown from out of file descriptors。
分析:由于Linux默认文件句柄限制为1024(通过命令ulimit –n来查看),所以当Web Server应对高负载起了大量线程,incoming socket connections和outgoing socket connections都很多,而且后台代码也可能涉及大量句柄打开,尤其是struts+spring组合。
因此当句柄数迅速到达1024的限制后,无法打开新句柄,于是乎文件打不开、类定义找不到,诸如此类的错误就出现了。
解决:
短期策略是调大Linux下对文件句柄数限制。操作如附录1所示。对于这个数字,一般建议是32667,也可以设置的更大,我们直接调为51200。
2、PermSize问题
现象:Resin被持续访问一段时间后,比如一天,就会报告如下500错误,导致所有页面不能访问:
OutOfMemoryError:PermGen space
此时,就只能重启机器了,重启resin都没用。
分析:因为线上用了spring+struts,这些框架用到大量动态class,ClassLoader是把这部分内存放在PermGen space里的。而JVM的GC是不会清理PermGen space的。这样很容易导致线上应用报告PermGen space内存溢出。
解决:通过在resin.xml中增加jvm-arg一系列参数,调大“PermSize”和“MaxPermSize”这两个参数来尽量避免出现JVM内存永久保存区域溢出错误。PermSize默认值参考附录2。修改情况参见附录3。
3、Xmx和Xms问题
现象:Resin报告如下500错误,导致所有页面不能访问:
OutOfMemoryError:Java heap space
此时重启resin还可以恢复。
分析:JVM默认的最大可用内存(-Xmx参数)和初始堆大小(-Xms参数)都偏小,很容易限制住服务器的能力。当Java架构的能力还没有发挥出来时,就已经被系统默认的各种参数限制住了,导致各种各样的异常。
解决:通过在resin.xml中增加jvm-arg一系列参数,调大“Xms”和“Xmx”以及“Xmn”这三个参数。修改情况参见附录3。Xmn附录4。
其中Xmx的值可以设置得很大,比如4096MB,跟你的物理内存大小差不太多都行,64位Linux支持得住。Xmn的值是Xmx数值的1/4。
Xms的值可以与Xmx一样,省得当压力上来后,初始堆大小发现不够,JVM又得花时间去把内存区大小扩到最大可用内存的数值,就在这个过程,持续不断的高负载可能已经将服务器冲垮。这个机理就类似于我们熟知的SQL Server要根据业务,仔细思考指定数据库空间初始值和最大值以及自增长模式。默认SQL Server数据库空间自动增长是按10%比例增加的:如果你最开始建库时分配了1GB空间,但当压力上来后,数据很快到达1GB,那么数据库就会先锁住所有请求,自动在磁盘上增长出100MB的空间,在这个自动增长过程,所有Web请求就会被挂住,最终可能全部超时。
附录附录1:
编辑/etc/profile,加入
ulimit -n 51200
有人认为设置为4096就可以,但在网络服务器上此数字最好调成几万,不然流量冲上来太容易冲破。
还有设置命令是:ulimit?–SHn 51200,-S、-H这两个参数的说明如下:
-H 设置硬件资源限制。
-S 设置软件资源限制。
-n size:设置内核可以同时打开的文件描述符的最大值。
还有另一种操作修改三个地方的设置,参见《修改 Ubuntu ulimit 限制》。
附录2:
没有给resin.xml加PermSize的情况下,默认计算规则是:
“JVM使用-XX:PermSize设置非堆内存初始值,默认是物理内存的1/64;由XX:MaxPermSize设置最大非堆内存的大小,默认是物理内存的1/4。”
那么,如果是物理内存4GB,那么64分之一就是64MB,这就是PermSize默认值,也就是永生代内存初始大小;
四分之一是1024MB,这就是MaxPermSize默认大小。
附录3:
优化规则:Server端的JVM最好将-Xms和-Xmx设为相同值。为了优化GC,最好让-Xmn值约等于-Xmx的1/4。
线上resin 4.0.15的resin.xml中增加如下配置节点:
<server-default>
<jvm-arg>-Xms4096m</jvm-arg>
<jvm-arg>-Xmx4096m</jvm-arg>
<jvm-arg>-Xmn1024m</jvm-arg>
<jvm-arg>-XX:PermSize=128m</jvm-arg>
<jvm-arg>-XX:MaxPermSize=256m</jvm-arg>
<thread-max>1024</thread-max>
<socket-timeout>30s</socket-timeout>
<keepalive-max>512</keepalive-max>
<keepalive-timeout>60s</keepalive-timeout>
</server-default>
附录4:
JVM的-Xmn参数含义是Young Generation的heap size。
JVM有2个GC线程。第一个线程负责回收Heap的Young区。第二个线程在Heap不足时,遍历Heap,将Young 区升级为Older区。Older区的大小等于-Xmx减去-Xmn,不能将-Xms的值设的过大,因为第二个线程被迫运行会降低JVM的性能。
resin的JVM參數調整
http://www.360doc.com/content/13/0827/11/13653527_310196338.shtml
<!-- - JVM 参数设置 -->
<jvm-arg>-Xms 512 m</jvm-arg>
( jvm 最小内存,也是启动 resin后的默认内存分配值)
<jvm-arg>-Xmx 512 m</jvm-arg> <!-- make ms=mx to reduce GC times -->
( jvm最大内存,当内存使用超过 Xms分配的值之后会自动向这个最大值提升,一般配置成最大最小值相等,理论上能够降低 GC 垃圾收集的时间,可按实际进行配置)
<jvm-arg>-Xmn 86 m</jvm-arg>
(内存分配增量,当内存需求超过 Xms值之后进行第一次分配请求的内存值,一般为 Xmx的 1/3-1/4 ;开始时候可以先屏蔽,当应用出现OutOfMemory的时候再打开也可以)
<jvm-arg>-XX:MaxNewSize= 256 m</jvm-arg>
<jvm-arg>-XX:PermSize= 128 m</jvm-arg>
<jvm-arg>-XX:MaxPermSize= 256 m</jvm-arg>
(以上三项是为了减少 OutOfMemory 而配置的,是每个 java编译执行的时候最多能一次申请 jvm 内存空间的值,以上默认配置基本够用,但依然出OutOfMemory 的时候可以适当调大,但不能超越 Xmx的值;开始时候可以先屏蔽,当应用出现 OutOfMemory的时候再打开也可以)
<jvm-arg>-Xss256k</jvm-arg> <!-- jvm Stack config -->
<jvm-arg>-Djava.awt.headless=true</jvm-arg> < (允许使用验证码)
<jvm-arg>-Djava.net.preferIPv4Stack=true</jvm-arg> <!-- disable IPv6 -->
<jvm-arg>-Doracle.jdbc.V8Compatible=true</jvm-arg>(针对 oracle10的兼容配置)
<watchdog-arg>-Dcom.sun.management.jmxremote</watchdog-arg>
<!-- 强制 resin 强制重起时的最小空闲内存 -->
<memory-free-min> 2 M</memory-free-min>
<!-- 最大线程数量 . -->
<thread-max>256</thread-max>
<!-- 套接字等待时间 -->
<socket-timeout>65s</socket-timeout>
<!-- 配置 keepalive -->
<keepalive-max>128</keepalive-max>
<keepalive-timeout>15s</keepalive-timeout>
Resin 中 JVM 的分析
JVM 虚拟内存
JVM 虚拟内存与系统内存的关系图:
-Xms 初始化 jvm 的时候从系统内存划分的 heap 内存数量
-Xmx jvm 最大能使用的 heap 内存数量
-Xmn ( -XX:NewSize/ -XX:MaxNewSize )年轻代占 heap 的内存数量
-XX:PermSize / -XX:MaxPermSize 持久代占用的系统内存数量
-Xss 单 个线程 堆栈 占的内存量,跟线程数相关
整个 JVM 的工作流程是:新的线程在 Eden 生成; Eden 满,把有经常访问的资
源放在 SO1 中,对 Eden 进行空间回收;当 SO1 满,将常使用的资源放到 SO2 ,对 SO 1
的空间进行回收;当 SO2 满,将经常访问的资源放到 Old ,对 SO2 进行空间回收;
按一定的规则对 Old 的资源进行处理。(为了容易记忆,我们可以对 SO1 、 SO2 、 O ld
起个其他的名字,分别是 幸存者 1 区,幸存者 2 区和养老区 )
简单概括为: Heap 设定与垃圾回收 Java Heap 分为 3 个区, New , Old 和
Permanent 。 New 保存刚实例化的对象。当该区被填满时, GC 会将对象移到 Old 区 。
Permanent 区则负责保存反射对象。 ( Perm 区在过去持久化没有使用的年代默认 的
配置已经足够使用,但现在要注意该区的情况,有可能 OOM--out of menery 就
是由于它而发生)
从上面的 JVM 工作机制,我们可以看出对 JVM 的优化主要在于: JVM-- 垃
圾收集。
注意: Heap 大小并不决定进程的内存使用量。进程的内存使用量要大于 -Xmx 定义的值,
因为 Java 为其他任务分配内存,例如每个线程的 Stack 等。
日常遇到的OOM和频繁发生GC 情况分析
java.lang.OutOfMemoryError: Java heap space
heap 空间不足,可能是 -Xmx 配得过大,或者系统内存不足或泄漏
java.lang.OutOfMemoryError: PermGen space
持久代内存不足,存在大量系统类被加载或 jpa 等架构频繁使用,需要增加 Perm的内存配置
java.lang.OutOfMemoryError:unable to create native thread
空闲内存不足以建立新的线程,减少 max-threads 的配置,增加空闲内存数量
为什么一些程序频繁发生 GC ?有如下原因:
1. 程序内调用了 System.gc() 或 Runtime.gc() 。
2. 一些中间件软件调用自己的 GC 方法,此时需要设置参数禁止这些 GC 。
3. Java 的 Heap 太小,一般默认的 Heap 值都很小。
4. 频繁实例化对象, Release 对象。此时尽量保存并重用对象,例如使用StringBuffer() 和 String() 。
5. 如果你发现每次 GC 后, Heap 的剩余空间会是总空间的 50% ,这表示你的 Heap
处于健康状态。
在 Resin 中对 JVM 的优化能很好的提高 Resin 的性能,通过这些基本知识使你对Resin 中 JVM 的优化更有把握。
参考文章:
http://blog.csdn.net/tyrone1979/archive/2006/09/25/1274458.aspx
http://www.caucho.com/resin-3.0/performance/jvm-tuning.xtp#garbage-collection
Resin中除JVM外的优化
在实际的生产环境中,以下三个东西经常用到,所以在这里提一下,也算是简单的优化。
<thread-max>512</thread-max>
最大线程数影响 resin 的系统负载能力以及 java 进程的内存占用
<keepalive-max>128</keepalive-max>
keepalive 的最大数量,对网络性能有影响
js/html/css/jpg/gif 等静态文件由 nginx 提供服务,剩下的由nginx以upstream方式代理到后端resin处理,以减少resin 提供这些静态文件访问的性能问题。
R esin 及 jvm 优化,是一项基于提供服务的应用上进行一段相对长时间的测试进行,由于每个项目都有其自身特点,只有根据这些特点来进行优化,才能把该项目配置得更好 ,不可能硬套到其它项目上 。
参考文章:
http://www.opendigest.org/article.php/450
欢迎大家增加这方面你的经验
合理配置RESIN内存-java.lang.OutOfMemoryError: PermGen space及其解决方法2013-01-11 15:50:53