Приложение Spring Boot не отвечает после отправки большого количества запросов - PullRequest
Новая
       13

Приложение Spring Boot не отвечает после отправки большого количества запросов

0 голосов
/ 06 ноября 2019

У меня проблема с сервером, который называется сервером A: Сервер A: Red Hat Enterprise Linux Server версии 7.2 (Maipo) Сервер B: Red Hat Enterprise Linux Server версии 7.7 (Maipo)

jdk-8u231установлен на всех серверах.

У меня есть приложение Spring Boot, работающее на 2 серверах. Всякий раз, когда я использую Jmeter для отправки 100 запросов на параллелизм приложению, работающему на каждом сервере, у приложения, работающего на сервере B., не возникает проблем.

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

Дамп потоков и дамп кучи не имеют существенной разницы.

Может кто-нибудь показать мне, как анализировать эту проблему? Я до сих пор не знаю, почему проблема возникает.

1 Ответ

0 голосов
/ 06 ноября 2019

Ну, я могу только предположить здесь, но здесь некоторые идеи, которые могут помочь:

  1. Есть два возможных источника проблем здесь: Java-приложение и Linux (+ его сетевые политики, брандмауэрыи т. д.).

  2. Поскольку вы не знаете наверняка, что произойдет, попробуйте поработать с помощью «исключения».

    Создайте сценарий, который будет запускаться на 100 одновременныхЗапросы. Поместите сценарий на сервер А (проблемный) и запустите сценарий на «localhost» (очевидно). Если вы видите, что это работает, то проблема вовсе не в Java. Вероятно, некоторые сетевые политики или установки Linux, кто знает.

  3. Поместите сообщение журнала в контроллер приложения Java и проверьте журнал. В журнале, помимо прочего, должен быть напечатан номер запроса, чтобы вы могли понять, застряли ли вы после четко определенного числа запросов или это всегда другое число.

  4. Проверьте настройки приложения Spring Boot. Может быть, есть разница в количестве потоков, выделенных для обслуживания запроса встроенным веб-сервером, который работает внутри приложения весенней загрузки (при условии, что вы не используете реактивный стек), и это число отличается. В этом случае вы не сможете вызвать конечные точки отдыха, привод и т. Д.

  5. Если для настройки доступно соединение JMX, подключитесь через JMX и проверьте MBean Tomcat (опять же, при условии, что под капотом есть кот), чтобы проверить почти ту же информацию, что и в 4.

  6. Вы упомянули дампы потоков. Попробуйте выполнить более одного дампа потока, но один перед запуском теста JMeter, один во время работы (когда все еще работает), один, когда все застряло.

  7. В потокеdumps проверяет фактические трассировки стека, может быть, все потоки застряли, работая с базой данных или чем-то еще, и не могут обслуживать запросы, как я объяснил в "4"

  8. Изучите журналы GC, возможно, GCработает так усердно, что вы не можете реально взаимодействовать с приложением.

...