Ошибка нехватки памяти с ConnectionQueueStatsProvider

на прошлой неделе мы столкнулись с ошибкой нехватки памяти в нашей производственной среде. Эта ошибка нехватки памяти возникает примерно раз в неделю, и текущий обходной путь — перезапустить сервер приложений. Мы используем стеклянную рыбу 3.0.1. Сгенерированный дамп кучи весил около 5 Гб.

Пожалуйста, помогите в анализе дампа кучи ниже. Вот отчет о подозреваемых утечках, созданный с помощью eclipse MAT. Как мы анализируем отчет ниже?

One instance of 
"com.sun.enterprise.v3.services.impl.monitor.stats.ConnectionQueueStatsProvider" loaded by 
"org.apache.felix.framework.ModuleImpl$ModuleClassLoader @ 0x602650970" occupies 
2,104,143,312 (87.97%) bytes. The instance is referenced by 
org.glassfish.flashlight.impl.client.ReflectiveClientInvoker @ 0x600a63768 , loaded by 
"org.apache.felix.framework.ModuleImpl$ModuleClassLoader @ 0x60265dd38". The memory is 
accumulated in one instance of "java.util.concurrent.ConcurrentHashMap$Segment[]" loaded 
by "<system class loader>".

Keywords
org.apache.felix.framework.ModuleImpl$ModuleClassLoader @ 0x602650970
org.apache.felix.framework.ModuleImpl$ModuleClassLoader @ 0x60265dd38
java.util.concurrent.ConcurrentHashMap$Segment[]
com.sun.enterprise.v3.services.impl.monitor.stats.ConnectionQueueStatsProvider

кратчайшие пути к точке накоплениянакопленные объекты


java out-of-memory jvm heap concurrenthashmap
person robertdi    schedule 02.12.2013    source источник

Ответы (4)


arrow_upward
0
arrow_downward

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

Подробнее см. в этой беседе Подключения к базе данных и OutOfMemoryError: Java Heap Space

person user35971    schedule 02.12.2013
comment
Привет! где вы увидели, что соединения с базой данных являются причиной проблемы? - person robertdi; 02.12.2013
comment
Возможно, это не соединение с базой данных, соединения с базой данных также создают ту же проблему, и информация о соединении хранится в Hashmaps, поэтому здесь также некоторые соединения открываются и не закрываются должным образом, оставляя его сборщиком мусора. Так что проверьте эту точку зрения - person user35971; 02.12.2013

arrow_upward
0
arrow_downward

Трудно анализировать причину с таким небольшим количеством информации.

Согласно отчету, это может быть проблема с подключением к базе данных.

ПЫТАТЬСЯ:

  • Подтвердите, что удерживается ConnectionQueueStatsProvider (вероятно, java.util.concurrent.ConcurrentHashMap$Segment[]).

  • Откройте исходный код, узнайте, что находится в ConnectionQueueStatsProvider's ConcurrentHashMap.

Если токен java.util.concurrent.ConcurrentHashMap$Segment[] занимает большую часть пространства, у вашего приложения могут быть проблемы с подключением к базе данных.

Java.util.concurrent.ConcurrentHashMap — это только одно использование в ConnectionQueueStatsProvider:

66  private final Map<Integer, Long> openConnectionsCount = new ConcurrentHashMap<Integer, Long>();

Попробуйте проверить свой код и закрыть соединения с БД.

person lichengwu    schedule 02.12.2013

arrow_upward
0
arrow_downward

Ну, MAT здесь довольно очевиден. У вас есть экземпляр ConnectionQueueStatsProvider с огромной картой openConnectionsCount. Такое впечатление, что вы постоянно заполняете эту карту, но никогда ничего с нее не удаляете. Утечка памяти, если я когда-либо видел ее :)

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

person Nikem    schedule 02.12.2013

arrow_upward
0
arrow_downward

мы думаем, что нашли ответ. Мы видели похожую ошибку в jira Glassfish:https://java.net/jira/browse/GLASSFISH-16254. Кажется, это ошибка в Glassfish 3.0.1.

У них была ошибка нехватки памяти, когда был включен мониторинг Glassfish для пула потоков и службы http, что является точной настройкой, которую мы имели.

Мы отключили мониторинг Glassfish, и теперь мы стабильно работаем в течение 1 недели без нехватки памяти.

Спасибо всем за помощь!

person robertdi    schedule 06.12.2013