Проблемы с сборщиком мусора Java и памятью

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

после того, как вы можете воспроизвести его, попробуйте уменьшить размер кучи, чтобы увидеть, если вы можете воспроизвести его быстрее. Но сделай это во второй раз. поскольку небольшая куча может не попасть в "предел накладных расходов GC", что означает, что GC тратит чрезмерное время (98% по какой-то мере), пытаясь восстановить память.

для утечки памяти вам нужно выяснить, где в коде накапливаются ссылки на объекты. Е. Г. это создать карту всех входящих сетевых запросов? Веб-поиск https://www.google.com/search?q=how + to + debug + java + память + утечки показывает много полезных статей о том, как отлаживать утечки памяти Java, включая советы по использованию таких инструментов, как Анализатор Памяти Eclipse что вы используете. Поиск конкретного сообщения об ошибкеhttps://www.google.com/search?q=GC + накладные расходы + лимит + превышен также полезно.

no-op finalize() методы не должны вызывать эту проблему, но они могут усугубить ее. The doc on finalize () показывает, что наличие finalize() метод заставляет GC два раза определите, что экземпляр не используется (до и после вызова finalize()).

поэтому, как только вы сможете воспроизвести проблему, попробуйте удалить эти no-op finalize() методы и посмотреть, если проблема требует больше времени для размножения.

важно, что их много AbstractReferenceMap$WeakRef экземпляров в памяти. Пункт слабые ссылки относится к объекту, не заставляя его оставаться в памяти. AbstractReferenceMap - это карта, которая позволяет сделать ключи и / или значения слабыми ссылками или мягкими ссылки на литературу. (Точка мягкая ссылка - попытаться сохранить объект в памяти, но позволить GC освободить его, когда память становится низкой.) В любом случае, все эти экземпляры WeakRef в памяти, вероятно, усугубляют проблему, но не должны хранить в памяти ссылки на ключи/Значения карты. О чем они говорят? Что еще относится к этим объектам?

попробуйте инструмент, который обнаруживает утечки в исходном коде, например plumbr

есть ряд возможностей, возможно, некоторые из которых вы изучили.

Это определенно какая-то утечка памяти.

Если ваш сервер имеет сеансы пользователя, и ваши сеансы пользователя не истекают или не удаляются должным образом, когда пользователь неактивен более X минут/часов, вы получите накопление используемой памяти.

Если у вас есть одна или несколько карт чего-то, что генерирует ваша программа, и вы не очищаете карту старого / ненужного записи, вы можете снова получить накопление используемой памяти. Например, однажды я подумал о добавлении карты для отслеживания потоков процессов, чтобы пользователь мог получать информацию из каждого потока, пока мой босс не указал, что ни в какой момент законченные потоки не будут удалены с карты, поэтому, если пользователь останется в системе и активен, они будут держаться за эти потоки навсегда.

вы должны попробовать сделать нагрузочный тест на непроизводственном сервере, где вы имитируете нормальное использование вашего приложения в целом число пользователей. Возможно, даже ограничить память сервера даже ниже, чем обычно.

удачи, проблемы с памятью очень сложно отследить.

вы говорите, что уже пробовали jvisualvm, чтобы проверить машину. Может быть, попробуем еще раз, вот так:

• на этот раз посмотрите вкладку "Sampler -> Memory".

• Он должен сказать вам, какие (типы) объектов занимают больше всего памяти.

• затем выяснить, где такие объекты обычно создаются и удаляются.

• много раз "странные" ошибки могут быть вызваны агентами java, подключенными к JVM. Если у вас есть какие-либо агенты (например, jrebel/liverebel, newrelic, jprofiler), попробуйте сначала запустить без них.
• странные вещи также могут произойти при запуске JVM с нестандартными параметрами (- XX); некоторые комбинации, как известно, вызывают проблемы; какие параметры вы используете в настоящее время?
• утечка памяти также может быть в самой магнолии, вы пробовали погуглить "Магнолия утечка"? Вы используете какие-либо сторонние модули magnolia? Если возможно, попробуйте отключить/удалить их.

проблема может быть связана только с одной частью вашего Вы можете попробовать воспроизвести проблему, "воспроизводя" журналы доступа на вашем промежуточном сервере/сервере разработки.

если ничего не работает, если бы это был я, я бы сделал следующее: - попытка воспроизвести проблему на" пустом " экземпляре Magnolia (без моего кода) - попытка воспроизвести проблему на "пустой" экземпляр Magnolia (без сторонних модулей) - попытка обновить все программное обеспечение (magnolia, сторонние модули, JVM) - наконец, попробуйте запустить производственный сайт с YourKit и попытаться найти утечку

Я предполагаю, что у вас есть автоматический запуск импорта, который вызывает некоторый экземпляр ImportHandler. Этот обработчик настроен на создание резервной копии всех узлов, которые он собирается обновить (я думаю, что это опция по умолчанию), и поскольку у вас, вероятно, много данных в вашем типе данных, и поскольку все это делается в сеансе, у вас заканчивается память. Попробуйте выяснить, какое задание импорта это и отключить резервное копирование для него.

HTH, Ян!--1-->

похоже, что ваши утечки памяти исходят из ваших массивов. Сборщик мусора имеет проблемы с идентификацией экземпляров объектов, которые были удалены из массивов, поэтому не будут собраны для освобождения памяти. Мой совет: когда вы удаляете объект из массива, назначьте позицию первого объекта null, поэтому сборщик мусора может понять, что это null объект и удалите его. Сомневаюсь, что это будет ваша точная проблема, но всегда хорошо знать эти и проверьте, не ваша ли это проблема.

также хорошо назначить экземпляр объекта null когда вам нужно удалить его / очистить его. Это потому что finalize() метод является отрывочным и злым, и иногда не будет вызываться сборщиком мусора. Лучшим обходным путем для этого является вызов его (или другого аналогичного метода) самостоятельно. Таким образом, вы уверены, что очистка мусора была выполнена успешно. Как сказал Джошуа блох в своей книге: эффективная Java, 2-е издание, пункт 7, стр. 27: избегайте финализаторов. "Финализаторы непредсказуемы, часто опасны и вообще не нужны". Вы можете увидеть раздел здесь.

поскольку код не отображается, я не вижу, может ли какой-либо из этих методов быть полезным, но все равно стоит знать эти вещи. Надеюсь, эти советы помогут вам!

Как рекомендовано выше, я бы связался с разработчиками Magnolia, но тем временем:

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

параллельный коллектор выдаст OutOfMemoryError, если слишком много время тратится на сборку мусора: если более 98% общее время тратится на сборку мусора и менее 2% кучи восстанавливается, OutOfMemoryError будет заброшенный.

поскольку вы не можете изменить реализацию, я бы рекомендовал изменить конфигурацию GC таким образом, чтобы она выполнялась реже, поэтому вероятность сбоя была бы меньше.

вот пример конфигурации, чтобы вы начали с параметров, вам нужно будет выяснить ваше сладкое пятно. Журналы ГК, вероятно, поможет, что

мои параметры VM следующие: -Отправляй по xms=6Г Значение-Xmx=6Г - XX: MaxPermSize=1G - XX: NewSize=2G - XX: MaxTenuringThreshold=8 - XX: SurvivorRatio=7 - XX: + UseConcMarkSweepGC - XX: + CMSClassUnloadingEnabled - XX: + CMSPermGenSweepingEnabled - XX: CMSInitiatingOccupancyFraction=60 - XX: + HeapDumpOnOutOfMemoryError - XX: + PrintGCDetails - XX: + PrintGCTimeStamps - XX: + PrintTenuringDistribution - Xloggc: журналы / gc.log