Проблема производительности в кластерных производственных серверах

Question

Наши производственные пользователи жалуются на проблемы с производительностью не менее двух-трех раз в месяц.У нас есть серверы IBM WAS 8 в производстве.Приложение использует две службы на основе SOAP, например, H и T. H развернут на кластерных серверах INTERNET (X, Y).T развернут на серверах INTRANET (U, V).Клиент напрямую подключается к H. H подключается к T на INTRANET.Обе службы на основе SOAP H, T подключаются к базе данных.Также есть сервис для аутентификации пользователей.Мы не видим никаких ошибок в журналах сервера U и V. Но журналы H на сервере X, Y выдают следующую ошибку.Разные ошибки в разное время:

1. java.net.SocketTimeoutException: Socket operation timed out before it could be completed
2. java.io.IOException: Connection close: Read failed.  Possible end of stream encountered.  
java.lang.OutOfMemoryError: GC overhead limit exceeded
3. Exception - User fault processing is not supported. The @WebFault faultbean is missing for java.rmi.RemoteException
4. Authentication failed

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

Answer 1

В качестве первого шага вы всегда должны следить за ключевыми ресурсами производительности базовой системы (аппаратный сервер, виртуальная машина, контейнер) - загрузка ЦП, свободная память, использование сети и т. Д. Если на вашем компьютере заканчиваются циклы ЦП или свободная ОЗУпроизводительность сервера приложений пострадает.

В качестве следующего уровня существуют различные метрики производительности, предоставляемые Java и WAS, которые могут помочь диагностировать проблему, подобную вашей.Полезное руководство по исследованию производительности WAS - книга по производительности WebSphere Application Server https://publib.boulder.ibm.com/httpserv/cookbook/
. В вашем случае, вероятно, этот раздел наиболее применим: https://publib.boulder.ibm.com/httpserv/cookbook/Recipes-WAS_Traditional_Recipes-General_WAS_Traditional_Performance_Problem.html

Одной из ошибок в вашем списке является выброс OOMиз-за "превышения предела служебных данных GC".Это означает, что серверная JVM работала на критически низком уровне свободного места в куче java, поэтому она почти все время проводила сборку мусора Java, пытаясь освободить пространство для реальной работы.Этот тип проблемы может вызвать другие проблемы, которые вы перечислили, такие как таймауты и сбои связи.

Для диагностики чрезмерной проблемы с сборкой мусора требуется подробное ведение журнала сборщика мусора - включение подробного сборщика мусора - это шаг № 2 во второй ссылке выше, также объясненный по адресу http://www -01.ibm.com / support /docview.wss? uid = swg21114927 Подробное ведение журнала GC требует очень мало служебных данных и имеет очень высокое диагностическое значение, поэтому его следует всегда включать, в том числе в производственных средах.

Самая важная информация из журнала GC - это количество доступной кучи свободного владения после каждого глобального GC.Это должно составлять не менее 30% от общего размера кучи владения, иначе JVM придется выполнять слишком много работы с GC, чтобы освободить место для «реальной работы», которую должен выполнять ваш сервер.Ошибка «Превышен лимит накладных расходов GC», как правило, возникает в конфигурациях, когда на занятом сервере менее 10% свободного пространства владения.

Если сервер постоянно работает с менее чем 30% свободного пространства владения после глобального GCВам нужно либо увеличить размер кучи, либо перенести некоторую рабочую нагрузку с сервера.