irbis_al,

Решит проблему, если в логах есть ошибка outofmemory. Но там не в одном месте память увеличивается, надо знать что увеличивать, поэтому в этом случае начать нужно с логов.

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

irbis_alИ тормоза как раз говорят ,что он на границе нехватки памяти...но каждый раз ему её удаётся освободить.
(я давно я java работаю и эту тему знаю)
Тормоза ни о чем не говорят, это лишь одна из трех озвученных здесь версий источника тормозов. Если есть Memory Leak, то как следствие появление outofmemory в логах практически неизбежно и можно уже решать проблему точечно. Или искать проблему в другом месте. Речь идёт не о тормозах на определенный интервал времени, а о том, что проблема решается только перезапуском weblogic, поэтому очистка памяти само по себе здесь врят ли не является проблемой.

С учетом, что проблема на конкретной странице, другие версии более вероятны. Если оставить баги с бесконечным потреблением cpu процессами weblogic в покое, то проблема может быть в dblinks, например. Например, в определенных ситуациях oracle не освобождает память выделяемую под dblink, до закрытия сессии, либо до вызова dbms_session.close_database_link вызывая утечки памяти уже в самом оракле (версия проверяется килянием всех сессий, как уже заметили выше). Тут слишком мало информации, чтобы делать какие-либо выводы о причинах тормозов.

irbis_alтак ведёт себя java когда permgen и heap память подходят критической точке.
Он очищает кучу.И если есть утечки памяти ...а у WL они есть...тем больше времени на анализ мёртвых объектов.

Я много раз наблюдал примерно следующую картину: например сервер работает несколько месяцев, вдруг начинает тормозить, в логах ошибка outofmemory, которая каждый раз соответствует примерно времени началу тормозов. Т.е. тут четкая корреляция каждый раз между наличием ошибки outofmemory и началом тормозов. Я думаю, это связано с тем, что какие-то процессы при этом перестают адекватно работать, например высвобождение нужного количества памяти начинает занимать очень много времени, в результате новые процессы не могут получить доступа к новой памяти и начинаются тормоза. С учетом теории с memory leak, то вполне может быть, что когда количество утекшей памяти приближается к критической массе, новым процессами просто не хватает памяти, в результате возникает outofmemory, поэтому эти два события и возникают примерно в одно время.

irbis_alНо когда какой-то процесс захватил лишнего.очистка кучи начинает вызываться часто....потому что java не может сразу освободить всё то ,что тот процесс "хапнул" (Мы ведь не забываем ,что другие приложения тоже работают и потребляют только освободившуюся память...а тут и другие на очереди ждут памяти...) И таким образом)...И outofmemory exception может и не возникнуть....
Мы попадаем в цикл...у нас есть как бы память которую можно было бы освободить..но нет на это кванта времени....и обслуживается только вот-вот необходимое.(При условии ,что сервер активно эксплуатируется ).
С причинами возникновения спорить не буду, может и так, но вот дальше после outofmemory объяснение не очень подходит. Т.е. имели достаточно часто раньше такую ситуацию: утром работало нормально, потом, например, в 10:20 перестало работать, и в следующие пол дня уже почти ничего не работает, пока сервер не перезапустишь. Т.е. это не постепенно нарастающая проблема, и не проблема, которая проходит со временем, при том что сервер месяцами работал нормально при схожей нагрузке. Как минимум во время обеда при существенном снижении нагрузки он должен был бы разгрузиться, но подобного не наблюдалось ни разу. Сейчас таких ошибок в общем-то не наблюдается уже

irbis_al,

Т.е. я хочу сказать, что out of memory это некий порог, событие, которое прямо или косвенно может существенно влиять на работу сервера. Что собственно не противоречит описанным выше причинам возникновения ошибки.

irbis_alНу так у автора же вроде не было outofmemory exception...так было бы вообще всё просто .
outofmemory exception свидетельствует о многих косяках.
Я очень сомневаюсь, что ТС умеет логи сервера weblogic смотреть, иначе он о них бы упомянул в первом же сообщении ;)

А посмотреть, что там происходит попросту необходимо

Vortexoid,

Я бы не стал говорить, что проблема именно в weblogic-е без тщательной проверки и отработки вариантов (легко ошибиться).
Например, сильно большое совпадение по dblink-ам, соответственно, стоит отработать вариант описанный выше (даже если все признаки, что проблема в weblogic), и помониторить V$PROCESS_MEMORY, скажем, на предмет неадекватных значений на период проблем. Даже в хелпе написано, что dblink-и таки желательно чистить в Security Attributes > Cleanup PL/SQL Code

В общем, если когда-нибудь захочется разобраться, тут много чего накидали, с чего начать поиски.
Мне самому weblogic не нравится, но его не просто так обычно ставят. Если вы уже перевели сам апекс на что-то другое, возможно он у вас по прежнему параллельно где-то крутится.

Собственно пишу, т.к. есть еще вариант (может еще кому пригодится, тут хорошо в обзорном виде написано)

Если windows с настройкой через планировщик (а это актуально для weblogic и для режима standalone),
то там есть неприятная особенность - приоритет i/o выставляется принудительно в низкий, независимо от приоритета cpu (не путать их)

http://www.outsidethebox.ms/9936/ Важное примечание о приоритете CPU и I/O

Когда программа запускается из планировщика, ей принудительно назначается низкий приоритет процессорного времени (CPU) и операций ввода-вывода (I/O). Это сделано специально, поскольку задачи планировщика рассчитаны на выполнение в фоне.

Низкая нагрузка на процессор и жесткий диск оптимально подходит для фоновых задач, но не для всех программ. Так, программам для проверки обновлений или почтовому клиенту вряд ли нужно много ресурсов – их можно безболезненно запускать из планировщика. Но если программа требует повышенного внимания процессора или активно взаимодействует с диском, ее лучше не ограничивать.

Указать другой приоритет задания можно только при импорте его XML-файла.
Это как минимум справедливо для windows server 2008 / 2012 независимо от мощности диска,
т.е. windows смотрит, если диск, скажем, нагружен только на половину, она может решить, что давать доступ к процессам с низким приоритетом вообще не стоит (или стоит, но редко), а это приводит к периодическим подвисаниям в период какой-нибудь неполной нагрузки на диск