Здравствуйте, elmal, Вы писали:

E>Здравствуйте, 0xCAFEDEAD, Вы писали:

CAF>>Ну шо разобрался?
E>Ни хрена, по прежнему бьюсь головой об стену. Удалось только ее уменьшшить в 2 раза, в результате падает не через 12 часов, как раньше, а через 24. Перевел синхронные запросы на псевдоасинхронные, результат отдаю мгновенно, но предыдущий из кеша, а далее стартую поток, который для заданных парементров выполняет фоновую задачу и кладет результат в кеш. При этом утечка, блин, не линейная. Первое время (часов уже 20, ранее было 10) потребление пологое. А далее резкий рост CPU до падения. При этом удалось мне снять дамп памяти в момент неадекватности и падения — память была забита строками. Такое впечатление что сам jboss undertow закешировал результат. Но непонятно где закешировал, в нейтиве я не увидел ничего подозрительного. Из jvisualvm нажимаю perform gc — все очищается практически до нуля. И такое поведение прямо до момента падения.

точно нет Soft(Weak)Reference? Что же еще убирает GC?
Если что — -XX:SoftRefLRUPolicyMSPerMB может уменьшить нагрузку.

Надо еще StringTable изучить, что там со строками?



E>Еще заметил в jvisualvm, что в конце остается много чего то, похожих на зомби потоки. То есть в общем списке показано на момент падения порядка 100 потоков, которые белые в агенде, которые не в running, blocked, waiting, parking. И названия таким потокам — TCP Connection(38) и тому подобное. Вчера заметил, сегодня погуглю нормально ли это или нет, мне всегда казалось что нормально, просто jvisualvm отображает все потоки, которые когда либо стартовали, соответственно их тупо уже давно нет, как и должно быть. Попробую еще почитать что там можно наконфигурить на jboss undertow, у меня стоит конфигурация по умолчанию, возможно еще попробую на другой сервер перейти. На других проектах с undertow проблем нет, более того, даже на этом проекте в других сервисах проблем нет. Но к другим проектам так часто не долбятся и ответы гораздо меньше, у меняя там на каждый запрос по мегабайтному json выплевывается, каждый раз разный.

100 не работающих потоков не должны влиять.

Кто жрет ЦПУ?

Здравствуйте, elmal, Вы писали:

E>Здравствуйте, 0xCAFEDEAD, Вы писали:

CAF>>Ну шо разобрался?
E>Ни хрена, по прежнему бьюсь головой об стену. Удалось только ее уменьшшить в 2 раза, в результате падает не через 12 часов, как раньше, а через 24. Перевел синхронные запросы на псевдоасинхронные, результат отдаю мгновенно, но предыдущий из кеша, а далее стартую поток, который для заданных парементров выполняет фоновую задачу и кладет результат в кеш. При этом утечка, блин, не линейная. Первое время (часов уже 20, ранее было 10) потребление пологое. А далее резкий рост CPU до падения. При этом удалось мне снять дамп памяти в момент неадекватности и падения — память была забита строками. Такое впечатление что сам jboss undertow закешировал результат. Но непонятно где закешировал, в нейтиве я не увидел ничего подозрительного. Из jvisualvm нажимаю perform gc — все очищается практически до нуля. И такое поведение прямо до момента падения.

точно нет Soft(Weak)Reference? Что же еще убирает GC?
Если что — -XX:SoftRefLRUPolicyMSPerMB может уменьшить нагрузку.

Надо еще StringTable изучить, что там со строками?
(Очень маловероянто, правда, что проблема в этом)



E>Еще заметил в jvisualvm, что в конце остается много чего то, похожих на зомби потоки. То есть в общем списке показано на момент падения порядка 100 потоков, которые белые в агенде, которые не в running, blocked, waiting, parking. И названия таким потокам — TCP Connection(38) и тому подобное. Вчера заметил, сегодня погуглю нормально ли это или нет, мне всегда казалось что нормально, просто jvisualvm отображает все потоки, которые когда либо стартовали, соответственно их тупо уже давно нет, как и должно быть. Попробую еще почитать что там можно наконфигурить на jboss undertow, у меня стоит конфигурация по умолчанию, возможно еще попробую на другой сервер перейти. На других проектах с undertow проблем нет, более того, даже на этом проекте в других сервисах проблем нет. Но к другим проектам так часто не долбятся и ответы гораздо меньше, у меняя там на каждый запрос по мегабайтному json выплевывается, каждый раз разный.

100 не работающих потоков не должны влиять.

Кто жрет ЦПУ?
И может ли сам jboss следить за нагрзкой и подчищаться?