Исключения Websphere outOfMemory

Ранее на этой неделе у нас было исключение Websphere OutOfMemory на одном из наших серверов, теперь мой вопрос: можно ли было предотвратить это, если IHS был ограничен в количестве одновременных клиентов, которые он мог поддерживать. Основная проблема была вызвана блокировкой базы данных, но к тому времени, когда она была устранена, WebSphere не хватило памяти.

Мне просто интересно, должны ли мы ограничить количество одновременных клиентских подключений в IHS, чтобы предотвратить возникновение этой ошибки?

Любая помощь или рекомендация будут высоко оценены.


java out-of-memory websphere ibmhttpserver
person ComeRun    schedule 27.05.2014    source источник
comment
Вы пытались увеличить размер кучи до оптимального?   -  person Devesh    schedule 27.05.2014
comment
Еще одна вещь, которую вы можете сделать, чтобы заставить mustGather проанализировать основную причину OOM. Следуйте этой статье для более подробной информации. www-01.ibm.com/support/docview. wss?uid=swg21138587#show-hide   -  person Devesh    schedule 27.05.2014

Ответы (1)


arrow_upward
2
arrow_downward

Ограничение количества одновременных сеансов не решит проблему, но обойдет ее.

Если в WebSphere закончилась память, первое, что вы должны сделать, это получить дамп кучи, проанализировать его и выяснить, почему ваше приложение могло использовать всю кучу. Я мог что-то упустить, но приложение, потребляющее всю кучу из-за блокировки базы данных, подразумевает ошибку.

Ограничение количества одновременных сеансов является допустимым решением (а не обходным путем) только в таких случаях, как:

  1. Каждый сеанс занимает X объем ОЗУ (то есть: X — это максимальный объем ОЗУ, занимаемый сеансом, при условии, что приложение работает так, как задумано), а размер кучи ограничен Y. В этом случае имеет смысл ограничить количество одновременных сеансов до Y/X. Это допустимое решение (а не обходной путь), потому что на самом деле ваша архитектура не рассчитана на большее количество сеансов.
  2. В сложной архитектуре способность архитектуры выдерживать большое количество одновременных сеансов равна способности самого слабого звена. Например, даже если размер кучи достаточен для поддержки 10 000 одновременных пользователей, но ваша база данных может выдержать только до 500 одновременных сеансов, вам следует ограничить количество одновременных сеансов до 500.
person Isaac    schedule 31.05.2014