最近我切换到亚马逊ec2 + jetty9 +甲骨文jdk7_u45节省成本。 我发现docker服务器非常不稳定。 它随机崩溃没有任何jvm转储文件。
尝试使用dumpBeforeStop = TRUE启用标准输出。 它不会在崩溃之前将转储消息附加到stderrout.log。
似乎它与OutOfMemoryError没有关系，因为我启用了gc详细选项，发现在崩溃之前它仍然有很多可用的内存。 ：162604K-> 3340K（176960K），0.2240040秒] 248332K-> 89101K（373568K），0.2736860秒] [时间：用户= 0.01sys = 0.01，实际= 0.28秒]
试图用不同的jdk组合（jdk6 / jdk7）降级到jetty8。 仍然有同样的问题。
试图删除所有的jvm选项，并使用“sudo java -jar start.jar”运行jetty。 仍然崩溃。
任何其他方式来解决问题？
最后我通过添加交换内存来解决这个问题。
amazon t1.micro实例的默认AMI没有交换内存，我按照这个post创build了1G交换空间。 jvm可以运行一周。
很多话题在这里..
首先，什么版本的Jetty 9？ （具体！用这些细节编辑你的问题）
您提到的dumpBeforeStop=TRUE不是Jetty的已知configuration。 如果你的意思是启动属性jetty.dump.stop=true那么这是为了在正式/正常关机期间转储服务器+处理程序树的状态。 它与服务器内存或服务器崩溃无关。
如果要查看服务器和处理程序树转储，而不停止服务器，则可以使用启动属性jetty.dump.start=true或启用JMX并访问org.eclipse.jetty.server:type=server,id=0 MBean并使用dump()操作。
OutOfMemoryError可能由于各种原因而发生。 （您没有粘贴完整的错误信息和堆栈跟踪来缩小原因）。 它可能来自堆不足，或permgen，或线程，或文件描述符等…没有额外的信息从OutOfMemoryError错误消息，build议你在什么path看是几乎不可能的。
GC事件日志所提供的信息太less了， 你可能有一个试图分配4GB的操作，这不会显示在GC上，但仍然会导致OutOfMemoryError。 你可能有一个场景，服务器试图分配一个新的线程，但操作系统阻止它，这也会导致OutOfMemoryError: Failed to Create Thread
切换Jetty或JVM版本将不会影响OutOfMemoryError。
“删除所有的JVM选项”也可能没有效果，这取决于你的Jettyconfiguration方式，你没有在你的问题中指定。
根据您的特定版本的Jetty，启动是不同的。 （例如：docker7/8 / 9.0与docker9.1）
根据Jetty的具体安装技术，您的启动可能会有所不同。 （例如：独立与embedded，从官方docker分发，从Linux分发/包装，从云提供商打包，孤立与unixfied目录结构，拆分jetty.home与jetty.base，服务启动与shell与cron，shell脚本或Java命令行，没有start.ini vs start.ini和/或start.d等…）
简而言之，你的问题是有效的，但含糊不清，为你提供build议的可能途径太多了（根据你提供的信息有限）
感谢您的快速回答。 我尝试了jetty-9.0.6，jetty-9.0.5和jetty-8.1.14。 以上所有都有同样的问题。
dumpBeforeStop，它是jetty.xml中的有效configuration。 默认值是false，我同意它不会与服务器崩溃，如果它只适用于正常关机。 OutOfMemoryError不是这里的情况。 我打开-XX：-HeapDumpOnOutOfMemoryError。 崩溃时不会生成转储文件。
我试图删除所有的jvm选项，因为我想使用干净的默认设置来运行jetty查看任何差异。
现在的问题是，jvm随机崩溃，没有任何hs文件或任何有用的错误消息。 如果docker无法处理，stderr / stdout中应该有错误。
如果某些东西不能被jvm处理，就应该有一个热点文件。 可悲的是，它只是默默地崩溃。
我昨天晚上打开jettydebugging模式，发现它再次崩溃这个monring。 这是崩溃前日志的最后几行：
DBUG：oejsh.ContextHandler：scope /||/article.jsp @ oejwWebAppContext {/，文件：/tmp/jetty-0.0.0.0-8080-put2012.war- -xxx 。 / home / ec2-user / jetty / webapps / put2012.war 2013-11-13 06：26：00.891：DBUG：oejsh.ContextHandler：context = || /article.jsp @ oejwWebAppContext {/，文件：/tmp/jetty-0.0.0.0-8080-put2012.war- -xxx.xx- / webapp /，xxx.xx}，/ home / ec2-user / jetty / webapps / put2012.war DBUG：oejs.session：sessionManager=org.eclipse.jetty.server.session.HashSessionManager@1acc0e01 2013-11-13 06：26：00.891：DBUG：oejs.session：session = null 2013-11-13 06：26：00.891：DBUG：oejs.ServletHandler：servlet | /article.jsp | null – > jsp 2013-11-13 06：26：00.891：DBUG：oejs.ServletHandler：chain = null DBUG：oejs.session：new session＆id 1hva53vl2jfs9m6voqnqdamyj 2013-11-13 06：26：01.885：DBUG：oejw.WebAppClassLoader：加载类com.sun.mail.handlers。来自WebAppClassLoader的text_plain = put2012 @ 3ef07355 2013-11-13 06：26：01.885：DBUG：o ejw.WebAppClassLoader：从WebAppClassLoader = put2012 @ 3ef07355加载类com.sun.mail.handlers.text_plain
你可以看到没有提示为什么它崩溃。
没有尸体，我没有什么可以检查为什么死亡。
我尝试了jstack的线程转储，没有任何exception。 只有在崩溃时倾倒线程才有用。