Проблемы с прерывистый сбой пристани
У меня проблемы с перебоями в Jetty, я использую Jetty 6.1.24.
У меня запущено веб-приложение neo4j Spring MVC, Jetty будет работать примерно 1 час, а затем я придется перезагрузить причал. Он работает на небольшом экземпляре amazon ec2, debian с 1,7 ГБ ОЗУ.
Я запускаю Jetty с помощью java -Xmx900m -server -jar start.jar
Я подключаюсь к серверу с помощью putty, когда Jetty вылетает разрыв сеанса замазки, Я не могу понять, какая ошибка привела к его аварийному завершению.
Я хотел бы видеть, является ли это ошибкой, сгенерированной Spring, я не уверен, как зарегистрировать вывод из приложения Spring с Jetty. Или, если это Jetty или проблема с памятью, что будет лучшим способом для мониторинга Jetty? Я не могу воссоздать это на моей локальной машине под управлением Windows. Как вы думаете, что будет лучшим способом подойти к этому? Спасибо
4 ответа
Когда вы говорите о сбое, вы имеете в виду, что JVM segfaults и исчезает? Если это так, я бы проверил и убедился, что вы не исчерпываете доступную память машины. Java в Linux будет аварийно завершать работу, когда системная память становится настолько низкой, что JVM не может выделить максимальную память. Например, вы установили максимальную память JVM на 500 МБ, из которых на данный момент используется 250 МБ. Однако в ОС Linux доступно только 128 МБ. Это приводит к нестабильным результатам, и JVM будет segfault.
В Windows JVM ведет себя лучше в этом сценарии и выдает OutOfMemoryError, когда системе не хватает памяти.
- Проверьте, сколько системной памяти доступно во время сбоев.
- Проверьте, не занимают ли другие процессы на вашем компьютере много памяти. Отключите все, что может конкурировать с JVM.
- Запустите jconsole и подключите его к вашей JVM. Это расскажет вам, как память используется в вашем процессе JVM, и даст вам историю, чтобы оглянуться назад, когда он выйдет из строя.
- Удалите любой нативный код, который вы можете загрузить в JVM при выполнении этого типа тестирования.
Я считаю, что у Jetty есть собственный код для обработки больших объемов запросов. Убедитесь, что он не используется. Вы хотите изолировать сбои в Java, а НЕ в какой-то странной нативной библиотеке.Если вы уберете родной материал и обнаружите, что он работает, у вас будет ответ на вопрос, что его вызывает. Если он продолжит падать, то вполне может быть то, что я описываю.
Вы можете заставить JVM выделять всю память при запуске с помощью -Xms900m, что может гарантировать, что JVM не будет бороться с другими процессами за память. После того, как будет выделена вся сумма Xmx, сбой не произойдет. Не решение, но вы можете легко проверить это таким образом.
Это не совсем программистский вопрос; возможно, он будет перенесен в ServerFault.
Вы не указали конкретно, какую операционную систему вы используете, но я рискну предположить, что это дистрибутив Linux. У вас есть два варианта выяснить, что не так:
Начните сеанс в экране. Экран будет жить до тех пор, пока машина включена, пока вы не перезагрузите операционную систему (или не выйдете из экрана).
вы запускаете screen вот так
screenи вы получаете новое приглашение, где вы можете запустить свою программу (cd foo, jetty и т.д.). Когда вы будете довольны и вам просто нужно куда-то уйти, вы можете отключить экран, нажав CTRL+A, а затем CTRL+D. Вы вернетесь в то место, где вы были до вызова
screen.Чтобы вернуться к просмотру
screen, наберитеscreen -R, что означает возобновить существующий экран. вы должны снова увидеть jetty.Самое приятное, что если вы потеряете соединение (или случайно закроете putty, или еще что-нибудь), вы можете использовать
screen -list, чтобы получить список запущенных экранов, а затем принудительно отсоединить их-Dи снова присоединить к текущему putty-R, никакого вреда!Используйте nohup. Nohup более или менее отсоединяет запущенный процесс от консоли, так что ни один из его выводов не попадает на терминал. Вы запускаете свою программу обычным образом, но добавляете слово
nohupк своей команде.Например:
nohup ls -l &После завершения
ls -lвывод сохраняется в файле nohup.out.
При запуске Java перенаправьте оба вывода (stdout и stderr) в файл:
Используя Bash:
java -Xmx900m -server -jar start.jar > stdout.txt 2> stderr.txt
После сбоя проверьте эти файлы.
Если сбой вызван сигналом (например, SEGV=ошибка сегментации), JVM должен создать дамп файла в том месте, где вы запустили java. Для виртуальной машины Sun (точки доступа) это что-то вроде hs_err_pid12121.log (здесь 12121 — идентификатор процесса).
Отключение Putty СИЛЬНО намекает, что серверу не хватает памяти и начинает закрывать процессы налево и направо . Вероятно, ваш экземпляр причала стал слишком большим.
Самое простое, что можно сделать сейчас, это добавить 1-2 Гб больше пространства подкачки и повторить это снова. Также обратите внимание, что вы можете использовать jvisualvm для подключения к экземпляру причала, чтобы напрямую получать информацию о времени выполнения.