我的情况
我的问题
pdf导入期间的错误输出示例
此日志显示如何导入pdf,并在某些时间点启动错误消息。我标记了erorr消息胖。
...
2012年5月31日上午11:15:40 infovis.structure.pdf.PDFImport进程信息: 处理第13页
2012年5月31日上午11:15:40 infovis.structure.pdf.PDFImport进程信息:处理第14页
2012年5月31日上午11:15:41 infovis.structure.pdf.PDFImport流程信息:处理Page 15
Java HotSpot(TM)64位服务器VM警告:CodeCache已满。编译器已被禁用。 Java HotSpot(TM)64位服务器VM警告:尝试使用-XX增加代码缓存大小:ReservedCodeCacheSize =代码缓存[0x00007fa43437e000,0x00007fa4347fe000,0x00007fa43737e000] total_blobs = 1858 nmethods = 1318 adapters = 490 free_code_cache = 44631Kb largest_free_block = 45618688 Java HotSpot (TM)64位服务器VM警告:CodeCache已满。编译器已被禁用。 Java HotSpot(TM)64位服务器VM警告:尝试使用增加代码缓存大小 -XX:ReservedCodeCacheSize =代码缓存[0x00007fa43437e000,0x00007fa4347fe000,0x00007fa43737e000] total_blobs = 1859 nmethods = 1318 adapters = 490 free_code_cache = 44631Kb largest_free_block = 45618688
2012年5月31日上午11:16:19 infovis.structure.pdf.PDFImport进程信息:处理第16页
2012年5月31日上午11:16:20 infovis.structure.pdf.PDFImport流程信息:处理Page 17
Java HotSpot(TM)64位服务器VM警告:CodeCache已满。编译器已被禁用。 Java HotSpot(TM)64位服务器VM警告:尝试使用增加代码缓存大小 -XX:ReservedCodeCacheSize =代码缓存[0x00007fa43437e000,0x00007fa4347fe000,0x00007fa43737e000] total_blobs = 1860 nmethods = 1318 adapters = 490 free_code_cache = 44630Kb largest_free_block = 45618688 2012年5月31日上午11:17:07 infovis.structure.pdf.PDFImport进程信息:处理Page 18 Java HotSpot(TM)64位服务器VM警告:CodeCache已满。编译器已被禁用。 Java HotSpot(TM)64位服务器VM警告:尝试使用-XX增加代码缓存大小:ReservedCodeCacheSize =代码缓存[0x00007fa43437e000,0x00007fa4347fe000,0x00007fa43737e000] total_blobs = 1861 nmethods = 1318 adapters = 490 free_code_cache = 44633Kb largest_free_block = 45618688
依旧......
到目前为止我尝试了什么
我试图在我的服务器上更改tomcat配置中的缓存大小(我不是最好的使用linux shell)。我试图增加CodeCache大小,以及其他缓存的大小,但问题仍然存在。我已经检查了我的代码是否存在可能的泄漏但是还没有找到(请记住,如果我通过eclipse启动它,我不会收到此消息,因此这可能表示tomcat(?)配置问题)。我还尝试设置参数" UseCodeCacheFlushing"这应该是为了在代码缓存变满时将其清空,但不知何故它不会影响应用程序的崩溃。
我的tomcat服务器配置
我已经读过,当它是64位应用程序时,默认的CodeCache大小是32MB或64MB。我尝试保留512mb(也许我在配置中做错了什么?)但问题当然又发生了。
您可以在此处将JVM启动参数传递给Java。如果未设置,则 默认选项为:-Djava.awt.headless = true -Xmx128m -XX:+ UseConcMarkSweepGC
使用" -XX:+ UseConcMarkSweepGC"启用CMS垃圾收集器 (改善响应时间)。如果您使用该选项并且您运行Tomcat 一台机器只有一个CPU芯片,包含一个或两个内核, 你还应该添加" -XX:+ CMSIncrementalMode"选项。 JAVA_OPTS =" -Djava.awt.headless = true -Xmx3g -Xms2g -XX:+ UseCodeCacheFlushing -XX:+ UseG1GC -XX:MaxPermSize = 512m -XX:ReservedCodeCacheSize = 512m"
我对此的想法
在我的研究过程中,我发现一些注意事项,当编程失败时,CodeCache相关的问题可能表明内存泄漏问题,其结果是垃圾收集器无法清空缓存。 这可能是可能的,遗憾的是我没有我读过pdf的库的源代码。但另一方面,我在本地tomcat(四核,4x 3.0ghz,也是4g内存)的台式机上阅读650页pdf没有任何问题,这让我很困惑。
这可能只是一个tomcat问题,如果我使用其他服务器进行部署,可以解决,比如glassfish?
你们中的任何人可以帮助我或有任何想法或建议吗?也许我做了一些错误的配置?我在使用tomcat或其他服务器方面没有经验,所以任何帮助都非常受欢迎。
非常感谢您的每一个回答,并认为您与我分享。
答案 0 :(得分:0)
尝试另一个像JRockit这样的JVM,你不应该遇到这个问题。如果它是Tomcat - 尝试查看它是否记录了日志中的泄漏 - 它通常是针对类加载器问题。
答案 1 :(得分:0)
我的解决方案是从Tomcat切换到Glassfish作为部署我的应用程序的应用程序服务器。
在那次切换之后,我再也没有体验过这种CodeCache行为。
为了确保这个问题得到解决,我还观察了我的服务器上运行的java-vm(使用带远程的jconsole)。我再也没有看到任何可疑行为。