Есть сервис. Тупо слушает порт, пишет в базу, прокидывает часть сообщений в kafka. Задеплоен как контейнер в OpenShift кластере. Тривиальный и небольшой. Но такое впечатление что течет процессорное время. Grafana показывает линейный рост загрузки процессора от времени. Память константа. Поставил на удаленный мониторинг через jvisualvm — все чисто, процессор практически не загружен, память не течет, лишние потоки не плодятся, никакого криминала не заметил. Если использовать сборщики мусора parallelGC, G1, Serial — через определенное время, когда по grafana происходит максимум загрузки процессора, происходит хороший такой stop the world когда пода не отвечает несколько минут и она прибивается. Поставил cms сборщик, вроде получше, но один черт загрузка процессора средствами grafana лезет линейно вверх со временем, правда потом сбрасывается через несколько дней в ноль и снова линейно растет со временем. Не память, а именно процессор. При этом через jvisualvm никакого криминала не видно, загрузка процессора близка к нулевой, прямо перед падениям ничего похожего на затык сборщика мусора не видел, до самого конца классическая пила параллельная оси времени.
Не могу понять что может хотя бы теоретически быть за хрень, откуда к чертям может быть утечка процессорного времени на ровном месте, причем невидимая для JVM, ее только grafana видит. Такая хрень только с одной подой только с одним сервисом. Остальные сервисы вполне нормально работают. Причем еще и пользуются общими либами.
Здравствуйте, elmal, Вы писали:
E>Не могу понять что может хотя бы теоретически быть за хрень, откуда к чертям может быть утечка процессорного времени на ровном месте, причем невидимая для JVM, ее только grafana видит. Такая хрень только с одной подой только с одним сервисом. Остальные сервисы вполне нормально работают. Причем еще и пользуются общими либами.
Мде. Прям подземный стук в подполе.
Добавь всякую всячину для мониторинга — gc logs, jit logs, ram usage, page faults, io... Попытайся замучить процесс локально, чтобы воспроизвеси проблему в тестовых условиях.
Одна из возможных причин — свопить начинает, т.к. в ram куча не влазит.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, elmal, Вы писали:
E>Не могу понять что за хрень.
E>Есть сервис. Тупо слушает порт, пишет в базу, прокидывает часть сообщений в kafka. Задеплоен как контейнер в OpenShift кластере. Тривиальный и небольшой. Но такое впечатление что течет процессорное время. Grafana показывает линейный рост загрузки процессора от времени. Память константа. Поставил на удаленный мониторинг через jvisualvm — все чисто, процессор практически не загружен, память не течет, лишние потоки не плодятся, никакого криминала не заметил. Если использовать сборщики мусора parallelGC, G1, Serial — через определенное время, когда по grafana происходит максимум загрузки процессора, происходит хороший такой stop the world когда пода не отвечает несколько минут и она прибивается. Поставил cms сборщик, вроде получше, но один черт загрузка процессора средствами grafana лезет линейно вверх со временем, правда потом сбрасывается через несколько дней в ноль и снова линейно растет со временем. Не память, а именно процессор. При этом через jvisualvm никакого криминала не видно, загрузка процессора близка к нулевой, прямо перед падениям ничего похожего на затык сборщика мусора не видел, до самого конца классическая пила параллельная оси времени.
E>Не могу понять что может хотя бы теоретически быть за хрень, откуда к чертям может быть утечка процессорного времени на ровном месте, причем невидимая для JVM, ее только grafana видит. Такая хрень только с одной подой только с одним сервисом. Остальные сервисы вполне нормально работают. Причем еще и пользуются общими либами.
В первыю очередь необходимо понять в JVM ли проблема или в контейнере. Взять другой контейнер, помониторить нативными тулами (должен найтись поток который все жрет). Проверить что размер процесса не растет, нет аномалий с памятью, ИО. Если "вроде" все хорошо, то надо убедиться что с хостом все в порядке и он не перегружен. Иначе все будет тормозить, а внутри контейнера ничего не понятно.
По jvm:
Сервис не отвечает != STW пауза. Перед тем как прибивать надо делать дамп стеков и процесса. Будет понятно что происходит. Если хип и кол-во классов не растет, то и с гц должно быть все в порядке.
Здравствуйте, elmal, Вы писали:
E>Не могу понять что за хрень.
E>Есть сервис. Тупо слушает порт, пишет в базу, прокидывает часть сообщений в kafka. Задеплоен как контейнер в OpenShift кластере. Тривиальный и небольшой. Но такое впечатление что течет процессорное время. Grafana показывает линейный рост загрузки процессора от времени. Память константа. Поставил на удаленный мониторинг через jvisualvm — все чисто, процессор практически не загружен, память не течет, лишние потоки не плодятся, никакого криминала не заметил. Если использовать сборщики мусора parallelGC, G1, Serial — через определенное время, когда по grafana происходит максимум загрузки процессора, происходит хороший такой stop the world когда пода не отвечает несколько минут и она прибивается. Поставил cms сборщик, вроде получше, но один черт загрузка процессора средствами grafana лезет линейно вверх со временем, правда потом сбрасывается через несколько дней в ноль и снова линейно растет со временем. Не память, а именно процессор. При этом через jvisualvm никакого криминала не видно, загрузка процессора близка к нулевой, прямо перед падениям ничего похожего на затык сборщика мусора не видел, до самого конца классическая пила параллельная оси времени.
E>Не могу понять что может хотя бы теоретически быть за хрень, откуда к чертям может быть утечка процессорного времени на ровном месте, причем невидимая для JVM, ее только grafana видит. Такая хрень только с одной подой только с одним сервисом. Остальные сервисы вполне нормально работают. Причем еще и пользуются общими либами.
Ну шо разобрался?
Кстати в добавок к моему пред посту — сравни дамп perf в обычных условиях, и когда тормозит. Посмотришь, какая тварь все цпу сожрала. Если ситуация радикально разная — то может поможет понять что не так.
Здравствуйте, 0xCAFEDEAD, Вы писали:
CAF>Ну шо разобрался?
Ни хрена, по прежнему бьюсь головой об стену. Удалось только ее уменьшшить в 2 раза, в результате падает не через 12 часов, как раньше, а через 24. Перевел синхронные запросы на псевдоасинхронные, результат отдаю мгновенно, но предыдущий из кеша, а далее стартую поток, который для заданных парементров выполняет фоновую задачу и кладет результат в кеш. При этом утечка, блин, не линейная. Первое время (часов уже 20, ранее было 10) потребление пологое. А далее резкий рост CPU до падения. При этом удалось мне снять дамп памяти в момент неадекватности и падения — память была забита строками. Такое впечатление что сам jboss undertow закешировал результат. Но непонятно где закешировал, в нейтиве я не увидел ничего подозрительного. Из jvisualvm нажимаю perform gc — все очищается практически до нуля. И такое поведение прямо до момента падения.
Еще заметил в jvisualvm, что в конце остается много чего то, похожих на зомби потоки. То есть в общем списке показано на момент падения порядка 100 потоков, которые белые в агенде, которые не в running, blocked, waiting, parking. И названия таким потокам — TCP Connection(38) и тому подобное. Вчера заметил, сегодня погуглю нормально ли это или нет, мне всегда казалось что нормально, просто jvisualvm отображает все потоки, которые когда либо стартовали, соответственно их тупо уже давно нет, как и должно быть. Попробую еще почитать что там можно наконфигурить на jboss undertow, у меня стоит конфигурация по умолчанию, возможно еще попробую на другой сервер перейти. На других проектах с undertow проблем нет, более того, даже на этом проекте в других сервисах проблем нет. Но к другим проектам так часто не долбятся и ответы гораздо меньше, у меняя там на каждый запрос по мегабайтному json выплевывается, каждый раз разный.
Здравствуйте, 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 следить за нагрзкой и подчищаться?
Здравствуйте, 0xCAFEDEAD, Вы писали:
CAF>И может ли сам jboss следить за нагрзкой и подчищаться?
А вот непонятно. Нагуглил подобную проблему: https://stackoverflow.com/questions/32469354/undertow-on-spring-leaks-connections
Только не очень понятно как этим воспользоваться.
setServerOption(UndertowOptions.NO_REQUEST_TIMEOUT, 60000)
Это вроде один хрен передается в опциях по умолчанию и так.
Как выставить httpServerExchange.setPersistent(false) тоже ни хрена не понятно.
Здравствуйте, elmal, Вы писали:
E>Не могу понять что может хотя бы теоретически быть за хрень, откуда к чертям может быть утечка процессорного времени на ровном месте, причем невидимая для JVM, ее только grafana видит. Такая хрень только с одной подой только с одним сервисом. Остальные сервисы вполне нормально работают. Причем еще и пользуются общими либами.
Где-то течен "натив"? Можно попробовать сравнить все нативные зависимости на разных нодах.
Здравствуйте, elmal, Вы писали:
E>Здравствуйте, 0xCAFEDEAD, Вы писали:
CAF>>И может ли сам jboss следить за нагрзкой и подчищаться? E>А вот непонятно. Нагуглил подобную проблему:
Могу только предложить запустить контейнер внутри локального VmWare и ближе к окончанию 24 часов сделать снимок состояния, чтобы было с чем разбираться. Есть ещё функция record/replay, но оно чудовищно прожорливое.
