Мы используем довольно сложное приложение в качестве портлета на Websphere Portal Server 5.1 в AIX с использованием IBM JDK 1.4.2. В нашей производственной системе я вижу странное поведение в подробных журналах GC. После периода нормального поведения система может быстро начать выделение больших и больших блоков. Система запускает трассировку> 1000 мс для завершения каждого GC, но блоки выделяются так быстро, что существует только разрыв в 30 мс между отказами распределения.Поведение странного поведения мусора с сервером портала Websphere
- Каждый отказ распределения немного больше последнего на некоторое целое количество x 1024 байта. Например. у вас может быть 5 МБ, а затем через короткое время 5 МБ + 17 * 1024.
- Это может продолжаться до 10 минут.
- Блоки, как правило, растут от 8 до 14 МБ, прежде чем они остановятся.
- Это четырехъядерная система, и я полагаю, что сейчас она тратит> 95% времени на выполнение GC с тремя ядрами, ожидая, что другое ядро завершит GC. В течение 10 минут. Уч.
- Очевидно, что производительность системы умирает в этот момент.
- У нас есть JSF, hibernate & JDBC, вызовы веб-сервисов, выход log4j и не намного больше.
Я интерпретирую это как скорее как нечто инфраструктурное, а не как наш код приложения. Если бы это была плохая конкатенация строк внутри цикла, мы ожидали бы более нерегулярного роста, чем блоки с 1024. Если бы это был рост StringBuffer или ArrayList, мы бы увидели удвоение размеров блоков. Рост заставляет меня думать о буферизации журналов или о чем-то еще. Я не могу придумать что-либо в нашем приложении, что распределения даже 1 МБ, не говоря уже о 14. Сегодня я искал записи в резервную копию в памяти до того, как их сбросили на диск, но объем протоколирующих заявлений за этот период обхода ГК был нигде не близок диапазон MB.
Очевидно, проблема связана с избыточным распределением памяти, а не с сборкой мусора, которая только делает все возможное, чтобы не отставать. Что-то выделяет большой блок и пытается увеличить его неэффективно с приращениями, которые слишком малы.
Любые идеи, которые могут вызывать все это, когда система находится под нагрузкой? Кто-нибудь видел что-то подобное с Portal Server?
Примечание: для кого-то, кто заинтересован, он начинает выглядеть так, как причина - случайный, но огромный запрос к базе данных. Кажется, что виновником является либо Hibernate, либо драйвер JDBC.
Обратите внимание, что в последних версиях IBM Java 5 и 6 теперь есть агент дампа, который вы можете использовать. Опция: -Xdump: stack: events = allocation, filter = #. может быть прямым размером, например «5 м» или диапазоном «256k..512k». Не забывайте, что «#» перед этим! Подробнее см. Руководство по диагностике Java. –