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