文件上传后Apusic应用服务器内存溢出并宕机的一种处理方式
2011-05-04 22:17
357 查看
前几日,碰见一个奇怪的现象,连续的文件上传操作,会导致JVM内存溢出,而且是java.lang.OutOfMemoryError: PermGen space,内存的永久保存区域溢出。最终,导致整个Apusic应用服务器宕掉。
对于Permanent Generation space,JVM在运行期是不会进行垃圾清理的,这块内存溢出,一般主要是因为加载的类太多了,超出了JVM的默认值,或者设定的值。一般的解决方案是加大permanent generation space的大小。
但是,在这里将MaxPermSize由原来的128M增加到256M,照样在上传一些文件之后出现同样的问题,估计这块空间再怎么增大,溢出都是迟早的问题。应用在启动的时候,一切正常,说明加载应用的class文件是不成问题的。增加maxPermSize对问题的解决没有意义。
但是,文件上传的操作,怎么会引起permGen space的溢出呢?想不明白?
还是来监控一下应用的日志吧。
整个应用运行期间一切都很正常,debug出来的持久层框架生成的SQL语句都非常正常,只是在某些时间点,并没有规律的时间点总是出现以下的信息:
2011-04-26 18:03:08 INFO [apusic.web.office./office] Closing Spring root WebApplicationContext
2011-04-26 18:03:08 INFO [apusic.web.office./office] Shutting down log4j
2011-04-26 18:03:08 INFO [apusic.application.office] Stopped.
2011-04-26 18:03:09 INFO [apusic.web.office./office] Initializing Spring root WebApplicationContext
不明白为什么应用总要重新启动?
看到这里突然有些眉目了,会不会是频繁的重新启动应用,而每次重新启动的时候,Permanent Generation space总是会重新加载一遍所有的class文件,而JVM并没有对permanent generation space的垃圾收集,最终导致这块内存溢出了!
这只是猜测,找证据!终于,在经过几次频繁的文件上传的操作之后,久违的异常在万众瞩目中出现了!伴随着异常的是,每上传一个文件,整个session就会丢失。
2011-04-26 18:05:17 INFO [apusic.web.office./office] Closing Spring root WebApplicationContext
2011-04-26 18:05:17 INFO [apusic.web.office./office] Shutting down log4j
2011-04-26 18:05:17 INFO [apusic.application.office] Stopped.
2011-04-26 18:05:18 INFO [apusic.web.office./office] Initializing Spring root WebApplicationContext
2011-04-26 18:05:28 ERROR [con.err] Exception in thread 'AutoDeployer'
2011-04-26 18:05:28 ERROR [con.err] java.lang.OutOfMemoryError: PermGen space
看起来是在又一次重新启动应用的时候发生异常了,永久代内存溢出了!足以证明永久代的溢出,跟应用的不断重启有关,而Apuisc的宕机跟应用的不断自动重启有直接关系。问题找到了!但是,为什么应用会不断的自动重启呢?在确认代码没问题以后(我相信任何一个负责任的编程人员都会不动不动就重启应用玩的,而且JavaEE的规范从安全性上来考虑,也不会允许从应用中来重启应用的),更多开始转向对Apusic的分析。什么情况下,Apusic会自动重启应用?
应用中的文件发生变化?用户会不会直接把文件上传到当前应用目录下,而当前应用又放在Apusic默认的应用目录下,这样一旦默认应用下的某些文件发生变化,无论是文件的增加、修改还是删除,Apusic都会产生相应的措施,来保证变化之后的文件能够及时加载。
在与总部沟通之后(在这里要感谢总部李伟斌、韦永森等同事的大力支持,才使问题最终解决),最终确定问题就在于此,将上传目录从应用中迁移出来之后,一切正常!
总之,如果上传文件存放的位置如果正好在当前应用的某个目录下,而且这个应用又放在了Apusic默认的应用目录下,那很不巧,每上传一次文件,Apusic都会自动重新启动一下应用,以保证文件的及时加载。
因此,建议在进行涉及到文件上传的操作时,文件如果不是转换成二进制流存放在数据库中,那么最好将文件存放的问题放在应用之外,至少与应用平行的目录是可以做到的,甚至可以指定一个绝对路径,这样对于文件的管理也未尝不是一件好事。
对于Permanent Generation space,JVM在运行期是不会进行垃圾清理的,这块内存溢出,一般主要是因为加载的类太多了,超出了JVM的默认值,或者设定的值。一般的解决方案是加大permanent generation space的大小。
但是,在这里将MaxPermSize由原来的128M增加到256M,照样在上传一些文件之后出现同样的问题,估计这块空间再怎么增大,溢出都是迟早的问题。应用在启动的时候,一切正常,说明加载应用的class文件是不成问题的。增加maxPermSize对问题的解决没有意义。
但是,文件上传的操作,怎么会引起permGen space的溢出呢?想不明白?
还是来监控一下应用的日志吧。
整个应用运行期间一切都很正常,debug出来的持久层框架生成的SQL语句都非常正常,只是在某些时间点,并没有规律的时间点总是出现以下的信息:
2011-04-26 18:03:08 INFO [apusic.web.office./office] Closing Spring root WebApplicationContext
2011-04-26 18:03:08 INFO [apusic.web.office./office] Shutting down log4j
2011-04-26 18:03:08 INFO [apusic.application.office] Stopped.
2011-04-26 18:03:09 INFO [apusic.web.office./office] Initializing Spring root WebApplicationContext
不明白为什么应用总要重新启动?
看到这里突然有些眉目了,会不会是频繁的重新启动应用,而每次重新启动的时候,Permanent Generation space总是会重新加载一遍所有的class文件,而JVM并没有对permanent generation space的垃圾收集,最终导致这块内存溢出了!
这只是猜测,找证据!终于,在经过几次频繁的文件上传的操作之后,久违的异常在万众瞩目中出现了!伴随着异常的是,每上传一个文件,整个session就会丢失。
2011-04-26 18:05:17 INFO [apusic.web.office./office] Closing Spring root WebApplicationContext
2011-04-26 18:05:17 INFO [apusic.web.office./office] Shutting down log4j
2011-04-26 18:05:17 INFO [apusic.application.office] Stopped.
2011-04-26 18:05:18 INFO [apusic.web.office./office] Initializing Spring root WebApplicationContext
2011-04-26 18:05:28 ERROR [con.err] Exception in thread 'AutoDeployer'
2011-04-26 18:05:28 ERROR [con.err] java.lang.OutOfMemoryError: PermGen space
看起来是在又一次重新启动应用的时候发生异常了,永久代内存溢出了!足以证明永久代的溢出,跟应用的不断重启有关,而Apuisc的宕机跟应用的不断自动重启有直接关系。问题找到了!但是,为什么应用会不断的自动重启呢?在确认代码没问题以后(我相信任何一个负责任的编程人员都会不动不动就重启应用玩的,而且JavaEE的规范从安全性上来考虑,也不会允许从应用中来重启应用的),更多开始转向对Apusic的分析。什么情况下,Apusic会自动重启应用?
应用中的文件发生变化?用户会不会直接把文件上传到当前应用目录下,而当前应用又放在Apusic默认的应用目录下,这样一旦默认应用下的某些文件发生变化,无论是文件的增加、修改还是删除,Apusic都会产生相应的措施,来保证变化之后的文件能够及时加载。
在与总部沟通之后(在这里要感谢总部李伟斌、韦永森等同事的大力支持,才使问题最终解决),最终确定问题就在于此,将上传目录从应用中迁移出来之后,一切正常!
总之,如果上传文件存放的位置如果正好在当前应用的某个目录下,而且这个应用又放在了Apusic默认的应用目录下,那很不巧,每上传一次文件,Apusic都会自动重新启动一下应用,以保证文件的及时加载。
因此,建议在进行涉及到文件上传的操作时,文件如果不是转换成二进制流存放在数据库中,那么最好将文件存放的问题放在应用之外,至少与应用平行的目录是可以做到的,甚至可以指定一个绝对路径,这样对于文件的管理也未尝不是一件好事。
相关文章推荐
- 文件上传后Apusic应用服务器内存溢出并宕机的一种处理方式
- 上传文件至美国服务器的一种提速方式
- (总结2)WinForm中3种方式文件上传服务器:WebClient
- python 通过post方式上传文件到php服务器
- android批量文件上传(服务器采用servlet处理)
- 上传文件到服务器方式之二:使用Button的ActionListener
- apache commons fileupload 处理文件上传的两种方式(流式和非流式)
- 处理Extjs4 文件上传时若服务器出错带来的有关问题
- 转52破解jiangwei212Android爆破应用签名的一种全新高效方式(Native+服务器验证)
- 一般处理程序上传文件到Web服务器
- 实现向服务器上传图片文件、实现不同方式的form表单提交方式
- 转52破解jiangwei212Android爆破应用签名的一种全新高效方式(Native+服务器验证)
- java上传文件到远程服务器(二)---HttpClient方式
- Ubuntu架设HTTP方式访问的SVN服务器以及war文件上传自动部署
- asp.net(c#)使用HttpWebRequest附加携带请求参数以post方式模拟上传大文件(以图片为例)到Web服务器端
- 批处理FTP上传文件到服务器
- spring mvc源码-》MultipartReques类-》主要是对文件上传进行的处理,在上传文件时,编码格式为enctype="multipart/form-data"格式,以二进制形式提交数据,提交方式为post方式。
- Android逆向之旅---爆破应用签名的一种全新高效方式(Native+服务器验证)
- Selenium之常见元素处理系列三--upFile(上传文件),应用JavaScript
- 一种处理从文件读取整数的方式