Проблемы с пристани разбиваются периодически - PullRequest
Новая
       17

Проблемы с пристани разбиваются периодически

8 голосов
/ 18 августа 2010

У меня проблемы с перебоями в Jetty, я использую Jetty 6.1.24.

Я использую веб-приложение neo4j Spring MVC, Jetty будет работать приблизительно 1 час, а затемперезагрузить причал.Он работает на небольшом экземпляре amazon ec2, debian с 1,7 ГБ ОЗУ.

Я запускаю Jetty с использованием java -Xmx900m -server -jar start.jar

Я подключаюсь к серверу с помощью putty, когда Jetty завершает сеанс puttyотключается, я не вижу, какая ошибка привела к его аварийному завершению.

Я хотел бы видеть, является ли это ошибкой, сгенерированной Spring, я не уверен, как зарегистрировать вывод из приложения Spring сJetty.Или, если это Jetty или проблема с памятью, что будет лучшим способом для мониторинга Jetty?Я не могу воссоздать это на моей локальной машине под управлением Windows.Как вы думаете, что будет лучшим способом подойти к этому?Спасибо

Ответы [ 4 ]

5 голосов
/ 21 августа 2010

Это на самом деле не вопрос программиста; возможно, он будет перенесен в ServerFault.

Вы не указали конкретно, какую операционную систему вы используете, но я рискну угадать в каком-то дистрибутиве Linux. У вас есть два варианта выяснить, что не так:

  1. Начните сеанс на экране. Экран будет жить до тех пор, пока фактическое устройство включено , пока вы не перезагрузите операционную систему (или не выйдете из экрана).

    вы запускаете экран вот так 

    screen

    и вы получите новое приглашение, в котором вы можете запустить свою программу (cd foo, jetty и т. Д.). Когда вы счастливы и вам просто нужно куда-то пойти, вы можете отключить экран, нажав CTRL + A, а затем CTRL + D. Вы вернетесь на то место, где были до того, как вызвали screen.

    Чтобы вернуться к просмотру screen, вы набираете screen -R, что означает возобновление существующего экрана. Вы должны снова увидеть причал.

    Приятно то, что если вы потеряете соединение (или случайно закроете замазку или что-то еще), вы можете использовать screen -list, чтобы получить список запущенных экранов, а затем принудительно отсоединить их -D и снова прикрепить их к текущая шпатлевка -R, без вреда!

  2. Используйте nohup. Nohup более или менее отсоединяет процесс, который вы запускаете, от консоли, поэтому ни один из его выводов не поступает на терминал . Вы запускаете свою программу обычным способом, но добавляете слово nohup в свою команду.

    Например: 

    nohup ls -l &

    После завершения ls -l ваш вывод сохраняется в nohup.out.

4 голосов
/ 26 августа 2010

Когда вы говорите «сбой», вы имеете в виду сегментации JVM и исчезают? Если это так, я бы проверил и убедился, что вы не исчерпываете доступную память машины. Java на Linux будет аварийно завершать работу, когда системная память становится настолько низкой, что JVM не может выделить до своей максимальной памяти. Например, вы установили максимальную память JVM на 500 МБ, из которых в данный момент она использует 250 МБ. Однако в ОС Linux доступно только 128 МБ. Это приводит к нестабильным результатам, и JVM будет зависать.

В Windows JVM лучше себя ведет в этом сценарии и выдает OutOfMemoryError, когда системе не хватает памяти.

  1. Проверьте, сколько системной памяти доступно во время ваших сбоев.
  2. Убедитесь, что другие процессы на вашем компьютере занимают много памяти. Отключите все, что может конкурировать с JVM.
  3. Запустите jconsole и подключите его к вашей JVM. Это расскажет вам, как память используется в вашем процессе JVM, и даст вам историю, чтобы оглянуться назад, когда произойдет сбой.
  4. Удалите любой собственный код, который вы, возможно, загружаете в JVM при выполнении этого типа тестирования.

Я считаю, что у Jetty есть некоторый нативный код для обработки больших объемов запросов. Убедитесь, что это не используется. Вы хотите изолировать сбои в Java, а НЕ в какую-то странную нативную библиотеку. Если вы возьмете родной материал и обнаружите, что он работает, у вас есть ответ на вопрос, что его вызывает. Если это продолжит падать, тогда это вполне может быть то, что я описываю.

Вы можете заставить JVM выделять всю память при запуске с помощью -Xms900m, который может гарантировать, что JVM не будет бороться с другими процессами за память. Как только он выделит полную сумму Xmx, он не потерпит крах. Не решение, но вы можете легко проверить это таким образом.

2 голосов
/ 26 августа 2010

Когда вы запускаете Java, перенаправьте оба вывода (stdout и stderr) в файл:

Использование Bash: 

java -Xmx900m -server -jar start.jar > stdout.txt 2> stderr.txt

После сбоя проверьте эти файлы.

Если сбой происходит из-за сигнала (например, SEGV = ошибка сегментации), JVM должен создать дамп файла в том месте, где вы запустили Java. Для Sun VM (точка доступа) это что-то вроде hs_err_pid12121.log (здесь 12121 - идентификатор процесса).

1 голос
/ 28 августа 2010

Шпаклевка, отключающая STRONGLY, намекает на то, что серверу не хватает памяти, и начинает останавливать процессы влево и вправо.Вероятно, ваш экземпляр Jetty становится слишком большим.

Самое простое, что можно сделать сейчас, это добавить 1-2 Гб больше пространства подкачки и сделать это снова.Также обратите внимание, что вы можете использовать jvisualvm для подключения к экземпляру Jetty для непосредственного получения информации о времени выполнения.

...