Недавно я перешел на amazon ec2 + jetty9 + oracle jdk7_u45 для экономии средств. Я обнаружил, что причальный сервер очень нестабилен. Он случайно вылетает без какого-либо файла дампа jvm.
Пытался включить стандартный вывод с параметром dumpBeforeStop = TRUE. Он не будет добавлять сообщения дампа в stderrout.log до сбоя.
Кажется, это не связано с OutOfMemoryError, поскольку я включил подробные параметры gc и обнаружил, что до сбоя у него все еще есть много доступной памяти. : 162604K-> 3340K (176960K), 0,2240040 секунд] 248332K-> 89101K (373568K), 0,2736860 секунд] [Times: user = 0,01 sys = 0,01, real = 0,28 sec]
Пытался перейти на причал8 с другой комбинацией jdk (jdk6 / jdk7). Все еще та же проблема.
Пытался удалить все параметры jvm и использовать "sudo java -jar start.jar" для запуска причала. По-прежнему сбой.
Есть ли другой способ решить проблему?
В конце концов я решил эту проблему, добавив подкачку памяти.
AMI по умолчанию из экземпляра amazon t1.micro не имеет памяти подкачки, я следую этому Почта чтобы создать пространство подкачки 1G. Jvm может быть запущен в течение недели.
Здесь много тем ..
Во-первых, какая версия Jetty 9? (будьте конкретны! отредактируйте свой вопрос с этими деталями)
В dumpBeforeStop=TRUE Вы упомянули, что это не известная конфигурация Jetty. Если вы имеете в виду свойство запуска jetty.dump.stop=true то это для сброса состояния дерева сервер + обработчик во время формального / постепенного завершения работы. Это не имеет ничего общего с памятью сервера или сбоями сервера.
Если вы хотите увидеть дамп дерева сервера и обработчика, не останавливая сервер, вы можете использовать либо свойство запуска jetty.dump.start=true или включите JMX и получите доступ к org.eclipse.jetty.server:type=server,id=0 MBean и используйте dump() операция.
OutOfMemoryError может возникать по разным причинам. (Вы не вставили полное сообщение об ошибке и трассировку стека, чтобы сузить причину). Это может произойти из-за недостаточной кучи, перманента, потоков, дескрипторов файлов и т. Д. Без дополнительной информации из сообщения об ошибке OutOfMemoryError, сообщающего вам, какой путь смотреть, практически невозможно.
Журналы событий GC предоставляют слишком мало информации о том, что происходит. У вас могло быть одно действие, которое пыталось выделить 4 ГБ, которое не отображалось в GC, но все равно вызывало OutOfMemoryError. У вас может быть сценарий, когда сервер пытается выделить новый поток, но ОС помешала этому, что также вызовет OutOfMemoryError: Failed to Create Thread
Смена версии Jetty или JVM не повлияет на OutOfMemoryError.
«Удаление всех параметров JVM» также может не иметь никакого эффекта, в зависимости от того, как у вас настроен Jetty, который вы не указали в своем вопросе.
В зависимости от вашей конкретной версии Jetty запуск отличается. (например: Jetty 7/8 / 9.0 против Jetty 9.1)
В зависимости от конкретной методики установки Jetty ваш запуск может отличаться. (например: автономный или встроенный, из официального распространения Jetty, из дистрибутива / упаковки linux, из пакета облачного провайдера, изолированной или unixfied структуры каталогов, разделения jetty.home на jetty.base, запуска службы против оболочки против cron, сценария оболочки или java командная строка, нет start.ini против start.ini и / или start.d и т. д.)
Короче говоря, ваш вопрос действительный, но расплывчатый, количество возможных путей получения совета для вас слишком велико (на основе ограниченной информации, которую вы предоставили)
Спасибо за быстрый ответ. Я пробовал причал-9.0.6, причал-9.0.5 и причал-8.1.14. У всего вышеперечисленного возникла та же проблема.
dumpBeforeStop, это действительная конфигурация в jetty.xml. Значение по умолчанию - false, я согласен, что это не имеет отношения к сбоям сервера, если он работает только при плавном завершении работы. OutOfMemoryError здесь не так. Включаю -XX: -HeapDumpOnOutOfMemoryError. При сбое не создается файл дампа.
Я попытался удалить все параметры jvm, потому что хочу использовать чистые настройки по умолчанию, чтобы запустить причал, чтобы увидеть какие-либо различия.
Проблема сейчас в том, что jvm вылетает случайным образом без какого-либо файла hs или какого-либо полезного сообщения об ошибке. Если что-то не может быть обработано пристанью, в stderr / stdout должна быть ошибка.
Если что-то не может быть обработано jvm, должен быть файл точки доступа. К сожалению, он просто тихо рушится.
Вчера вечером я попытался включить режим отладки причала и обнаружил, что он снова вылетает сегодня. Это последние несколько строк журнала до сбоя:
2013-11-13 06: 26: 00.891: DBUG: oejsh.ContextHandler: scope /||/article.jsp @ o.e.j.w.WebAppContext {/, файл: /tmp/jetty-0.0.0.0-8080-put2012.war--xxx.xx- / webapp /, xxx.xx}, / 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 2013-11-13 06: 26: 00.891: 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 13.11.2013 06: 26: 00.891: DBUG: oejs.ServletHandler: chain = null 13.11.2013 06: 26: 00.894: DBUG: oejs.session: новый сеанс и идентификатор 1hva53vl2jfs9m6voqnqdamyj 1hva53vl2jfs9m6voqnqdamyj 13.11.2013 06: 26: 01.885: DBUG: oejw.WebAppClassLoader: загруженный класс com.sun.mail.handlers.text_plain из WebAppClassLoader = put @ 3ef07355 13.11.2013 06: 26: 01.885: DBUG. WebAppClassLoader: загруженный класс com.sun.mail.handlers.text_plain из WebAppClassLoader = put2012 @ 3ef07355
Вы можете видеть, что нет никаких подсказок, почему он вылетает.
Без трупа мне нечего проверять, почему его убили.
Я пробовал дамп потоков с помощью jstack и ничего необычного. Это будет полезно только при сбросе потока в момент сбоя.