Про возрожденные тоже не слышал. Это о чем?Сабина wrote:soft references строго говоря не убитыеPalych wrote: (слабые ссылки, да и объекты могут быть возрождены).
а про "возрождены" можно поподробнее ?
Началось это со static final String а потом добавили copy on write.Это про Object resurrection. Я про него много раз мельком читал, но не углублялся.kostik78 wrote: Про возрожденные тоже не слышал. Это о чем?
Аааа, Вы про этот хак с finalize. Дык это такой антипаттерн про который лучше не расказывать ибо найдуться деятели что нахачат что потом не разберешься.Palych wrote:Это про Object resurrection. Я про него много раз мельком читал, но не углублялся.kostik78 wrote: Про возрожденные тоже не слышал. Это о чем?
Определение или авточистка ?kostik78 wrote: Кстати определение дубликатов строчек есть давно а не только появилось
.Чего то zk классов много. А по сабжекту - большие хипы на большом железе подымать а у mat надо jvm параметры поправить. Я обычно сервак берут с 64gb memory и на нем терзаю через ssh X-Forwarding.Сабина wrote:У меня тут задача вытащить хоть что-то из heapdump-а размером 17 GB. Все что удалось ( без OOM) - открыьт в JVisualVM и посмотреть на список классов. В табе Instances ничего from the top of the list ( самого интересного) не открывается
Это случай когда один из Kafka consumers начинаесть жрать много памяти и тормозить, потом в какой то момент много коммитов в Кафку с этой ситемы начинает падать и "все умерли". Пытаюсь понять почему из 40 боксов именно у этого проблемы, по идее все идет по принципу rounds Robin, надеялась посмотреть на object tree - ан нет, MAT, YourKit сразу упали с OOM, тока VisualVm что-то вымучил долго думв до того как
Я бы предположил что она сначала начинает тормозить по какой-то причине, а из-за этого жрет память.Сабина wrote: Это случай когда один из Kafka consumers начинаесть жрать много памяти и тормозить, потом в какой то момент много коммитов в Кафку с этой ситемы начинает падать и "все умерли". Пытаюсь понять почему из 40 боксов именно у этого проблемы,
Да, я посмотрела и для дампа в 17 GB надо 34 GB , а на лаптопе тока 16kostik78 wrote:Чего то zk классов много. А по сабжекту - большие хипы на большом железе подымать а у mat надо jvm параметры поправить. Я обычно сервак берут с 64gb memory и на нем терзаю через ssh X-Forwarding.Сабина wrote:У меня тут задача вытащить хоть что-то из heapdump-а размером 17 GB. Все что удалось ( без OOM) - открыьт в JVisualVM и посмотреть на список классов. В табе Instances ничего from the top of the list ( самого интересного) не открывается
Это случай когда один из Kafka consumers начинаесть жрать много памяти и тормозить, потом в какой то момент много коммитов в Кафку с этой ситемы начинает падать и "все умерли". Пытаюсь понять почему из 40 боксов именно у этого проблемы, по идее все идет по принципу rounds Robin, надеялась посмотреть на object tree - ан нет, MAT, YourKit сразу упали с OOM, тока VisualVm что-то вымучил долго думв до того как
. Какой именно message is too big or fecth too slow and why the hell this specific box out of 40 decided to be too slow
Это все точно знаем. Each instance goes against several remote rest endpoints and fetches huge JSONs from response ( we have time breakdown of each http call and time spent in method). Но в собранном batch-e всегда mix of the messages и падает уже при попытке batch.commitPalych wrote:Я бы предположил что она сначала начинает тормозить по какой-то причине, а из-за этого жрет память.Сабина wrote: Это случай когда один из Kafka consumers начинаесть жрать много памяти и тормозить, потом в какой то момент много коммитов в Кафку с этой ситемы начинает падать и "все умерли". Пытаюсь понять почему из 40 боксов именно у этого проблемы,
И расследовать бы попробовал timing отдельных операций, не обращая внимания на JVM...
А commit в обычных условиях на этом ноде столько же занимает, или медленнее?Сабина wrote: падает уже при попытке batch.commit
Так а что его отлавливать - момент когда память >95% четко отмечен, а так же и ошибки UNKNOWN_MEMBER_ID в логах. Вся загадка в том что все остальное BAU. Есть еше мысль enable zk or kafka debug, но это проишодт раз в сто лет - фиг отловишь. Вся надежда была на dumpPalych wrote:А commit в обычных условиях на этом ноде столько же занимает, или медленнее?Сабина wrote: падает уже при попытке batch.commit
Наверное нужно отловить момент когда конкретный песец приходит (по графикам памяти и time spent in GC) и медитировать над логами, выискивать что случилось.
И еще - замерить производительность сетевых соединений.
Иногда тормоза может вызвать клиент, который не торопится читать ответы (сеть тормозит, или сам клиент), и они накапливаются...
Обычно наличие исходников и dump достаточно чтобы разобраться в чем дело. Найдите сервак с большим обьемом памяти и настройте ssh X forwarding и впередСабина wrote:
Так а что его отлавливать - момент когда память >95% четко отмечен, а так же и ошибки UNKNOWN_MEMBER_ID в логах. Вся загадка в том что все остальное BAU. Есть еше мысль enable zk or kafka debug, но это проишодт раз в сто лет - фиг отловишь. Вся надежда была на dump
Думаю что найдете в чем дело. Я смогла открыть with jVisualVm , вижу что heap занят классами зукипера, к сожалению для того чтобы проследить three depednencies ( кто держит кого) надо рыться с исходниках зукипера, кафки и наших.kostik78 wrote:Обычно наличие исходников и dump достаточно чтобы разобраться в чем дело. Найдите сервак с большим обьемом памяти и настройте ssh X forwarding и впередСабина wrote:
Так а что его отлавливать - момент когда память >95% четко отмечен, а так же и ошибки UNKNOWN_MEMBER_ID в логах. Вся загадка в том что все остальное BAU. Есть еше мысль enable zk or kafka debug, но это проишодт раз в сто лет - фиг отловишь. Вся надежда была на dump
Костя, а вы знакомы с такой штукойkostik78 wrote:Обычно наличие исходников и dump достаточно чтобы разобраться в чем дело. Найдите сервак с большим обьемом памяти и настройте ssh X forwarding и впередСабина wrote:
Так а что его отлавливать - момент когда память >95% четко отмечен, а так же и ошибки UNKNOWN_MEMBER_ID в логах. Вся загадка в том что все остальное BAU. Есть еше мысль enable zk or kafka debug, но это проишодт раз в сто лет - фиг отловишь. Вся надежда была на dump
Ну это ж нормально. У нас аппликуха базируется на Spring Boot& Spring Integration и часть промежуточных результатов пишется в ElasticSearch.Сабина wrote:Костя, а вы знакомы с такой штукойkostik78 wrote:Обычно наличие исходников и dump достаточно чтобы разобраться в чем дело. Найдите сервак с большим обьемом памяти и настройте ssh X forwarding и впередСабина wrote:
Так а что его отлавливать - момент когда память >95% четко отмечен, а так же и ошибки UNKNOWN_MEMBER_ID в логах. Вся загадка в том что все остальное BAU. Есть еше мысль enable zk or kafka debug, но это проишодт раз в сто лет - фиг отловишь. Вся надежда была на dump
https://blogs.oracle.com/dholmes/entry/ ... concurrent" onclick="window.open(this.href);return false;
в частности со свойством - parallelLockMap ?
Из того что я вижу heap доминирован by instances of org.apache.zookeeper.proto.CreateResponse
последние имеют свойство classloader - > parallelLockMap
и в етой HashMap parallelLockMap сидят наши мессаджи которые приходят от системы, которая сильно глючила в последнее время ( то есть была задержка). Может GC потoму и запаздывает что пока весь Record не процессится он с хипа не пропадает ? А он не процессится потому что other remote system is slow (bottleneck)
Ну классно .. молодецСабина wrote:Спасибо Вячеслав, ваши слова подтвердили мои findings, правда лоадер там этот ни причем оказался. я вчера докопалась таки до сути