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

leaderКакую еще динамическую конфигурацию памяти? Чо за бред??
Плохо понимаю трейс, что там за вторая циферька.

начинали с
[GC (Allocation Failure) [PSYoungGen: 33280K->1104K( 38 400K )] 33280K->1184K( 125 952K ), 0.0179369 secs] [Times: user=0.01 sys=0.00, real=0.03 secs]

закончили
[GC (Allocation Failure) [PSYoungGen: 348 160K->0K( 348 672K )] 349252K->1092K( 436 224K ), 0.0007362 secs] [Times: user=0.00 sys=0.00, real=0.00 secs]
Здесь callback перестал вызываться


Как минимум young вырос с 38 Mb до 348 Mb. Что обозначает вторая циферка (125 Mb -> 436 Mb) - не знаю.

Тут же смотрит трейс с явным вызовом System.gc():

[Full GC (System.gc()) [PSYoungGen: 155K->0K( 38 400K )] [ParOldGen: 1081K->1112K(87552K)] 1237K->1112K( 125 952K ), [Metaspace: 6168K->6168K(1056768K)], 0.0048000 secs] [Times: user=0.00 sys=0.00, real=0.00 secs]
[GC (System.gc()) [PSYoungGen: 665K->176K(38400K)] 1778K->1289K(125952K), 0.0235730 secs] [Times: user=0.13 sys=0.00, real=0.03 secs]
И так далее..

Совершенно другое распределение памяти. Ну и смысл сравнивать логи при этом? одно мягкое, другое теплое. Одно вроде работает при 200-300 Mb и не падает. Другое умудряется падать при гиге.

Самое лучшее смотреть на исходный код. Хотя, никто не мешает снять дамп памяти и посмотреть, какой мусор там валяется любым анализаторов логов. Может на какие идеи натолкнет. Но в любом случае, сначала поставить нормальные настройке для JVM. Что бы, хотя бы, сравнивать работающий и падающий вариант при одинаковых настройках памяти.

С первой тройкой цифр все ясно:
PSYoungGen: 348 160K->0K(348 672K)] 349252K->1092K(436 224K),

Было 348 Mb в young, все вычищено, осталось 0.

А вот следующая тройка цифр подкупает своей загадочностью. Что это? OldGen? Сфигли PSYoungGen GC начал OldGen чистить (и главное, зачистил). Откуда там такие огромные цифры.

Попытался почитать доку (до этого настраивал GC только на 1.6), но как-то там все мало подробно.

Нифига не могу найти алгоритма, в каких случаях, минор коллектор, запускает мажор коллектор. Описание алгоритмов подкупают своей подробностью (((

Я бы вырубил нафиг всю эту автоматическую настройку и нормально настроил память.


предполагая, что исходный код не доступен и нужно придумывать work around'ы. Конечно, по хорошему, нужно видеть код и дамп памяти.

Пока, подозреваю (гадая на кофейной гуще) две возможные кривости кода:
1. Выделения очень огромных областей памяти > 100 - 200 Mb одним куском
2. Что-то завязано на финализаторах ( finalize() )
возможно и одно и второе, ну или что-то из свеже придуманного используется и не до конца почитали доку

Leonid KudryavtsevА вот следующая тройка цифр подкупает своей загадочностью.....
нашел описание формата
http://www.oracle.com/technetwork/java/example-141412.html

Типа вторая тройка это
<starting occupancy3> is the occupancy of the entire heap before the collection
<ending occupancy3> is the occupancy of the entire heap after the collection
<pause time3> is the pause time for the entire garbage collection. This would include

Но тогда вообще какой-то бред получается. Если это весь heap (young + tenured), то размер tenured какой-то НЕ реальный.

436 224K - 348 672K = < 100 Mb

Но это какой-то бред. Все старые доки уверяли, что размер tenured как минимум должен быть больше размера young. Иначе в процессе GC можно упасть.

am_sasa...в JNA освобождение памяти (физической, freemem) сидит в finalize()...
Матных слов не хватает. И где таких студентов учат....

Вот ларчик просто и открывался. Нефиг студенческими поделками пользоваться. Хотя, в свое время, в похожие ошибки даже Oracle Co. носом тыкать приходилось