Мы написали свой велосипед. 6000 потоков - нормальная ситуация. Да-да, конечно, у России свой особый путь. )) Я так понимаю, JVM на серваке с не менее чем десятком Xeon по 52 core (ну надо же на чем то всю эту тьму потоков исполнять)?. )) Проблема не в потоках JVM м GC непосредственно, проблема в нативных потоках, переключении контекста и фрагментации памяти на уровне ОС. Проблема фрагментации памяти частично решается заменой менеджера хип памяти в Linux. В целом доклад поверхностный и в проблеме, походу, до конца не разобрались.
@@ghostl3r Потрясающе. 30 минут одной фразой. Демонстрирует квалификацию. Любой нормальный мониторинг сразу такую ситуацию обнаруживает, чем всё это время занимались совершенно непонятно.
Что ты несёшь? Причем тут РФ? А что им делать, как не писать "велосипед", если альтернатив нет ? Поражают такие альтернативно одаренные... Ещё и напыщенности хоть отбавляй. Мда
Была проблема , очень давно, рвались подключения к сервису, выглядело как сетевая ошибка, а на самом деле из-за ошибки в jni падал замертво тред на другой стороне, при этом сервис работал как ни в чем не бывало, а джава тихонько писала дамп себе в папочку.
сверхкритичный финансовый процессинг, а на мониторинге нету алертов на занятость свопа? это прям эпик фэйл, особенно с учётом того, что на осознание проблемы ушли месяцы.
30 минут ни о чем видимо, доклад (на "отстань") ради доклада, чтобы сбер не просто так был первым в списке спонсоров презентация - "топ": ни одной метрики, ни параметров и каких-либо величин ответы на вопросы тоже шедевральны: 26:50 "ну.. э.. списка библиотек четкого нет.. э.. ну вот.. спринг.. э.." 27:41 "э.. точных замеров нет.. " 28:22 "э.. ну этот вопрос не до конца ясен.. четкого понимания нет.." з.ы. вообще такое ощущение, что и проблема выдуманная ради того, чтобы хоть что-то рассказать на JPoint-е
Слушать конечно было интересно, но не хватает конкретики, за полчаса доклада относительно полезной инфы - смотрите за ресурсами машины, играйтесь с JVM параметрами и читайте логи до конца. Качество полезности точно не "уровня Сбера", как неоднократно выразился докладчик
Немного странно что контейнер с приложенькой катастрофически аффектил хост систему. Ведро линукса должно было килять контейнер при первых признаках утечки памяти.
обрыв логов, внезапное падение, непостоянство падений. Что же может быть? По моему ответ очевиден на первом же признаке - тупо OOM. Вот и весь кейс. Ну и своп должен быть, лучше всего не меньше половине реальной ОЗУ (для СП). Плюс мониторинг использования ОЗУ в ОС. Плюс ОЗУ под линукс не освобождается джавой, если она сожрала память, то все она ее не отдаст. Сам участвовал в подобных расследованиях. Разрабам, не работавшим с "кровавым" энтерпрайзом, это наверное непривычно)) Кстати память сверх выделенной кучи, джава ест дай бог в энтепрайзе, поскольку нативный API используется самой джавой, например при обработке блобов. Свободную ОЗУ лучше держать равным >=0,5 от Xmx.
OOM по xmx все таки выдаст эксепшен в логи, а вот когда снаружи linux прихлопнет jvm, там да, обрыв логов симптом весьма характерный. В остальном это конечно какой то испанский стыд для sre, что не определяется, что залезли в своп, что работал oom killer, что в мониторах не видели общую память сервера.
Это не тёмная стороны явы, это тёмная сторона программистов сбера, которые на собесах спрашивают принципы солид и знание документации
Как же в точку!
Мы написали свой велосипед. 6000 потоков - нормальная ситуация. Да-да, конечно, у России свой особый путь. ))
Я так понимаю, JVM на серваке с не менее чем десятком Xeon по 52 core (ну надо же на чем то всю эту тьму потоков исполнять)?. ))
Проблема не в потоках JVM м GC непосредственно, проблема в нативных потоках, переключении контекста и фрагментации памяти на уровне ОС.
Проблема фрагментации памяти частично решается заменой менеджера хип памяти в Linux.
В целом доклад поверхностный и в проблеме, походу, до конца не разобрались.
Да проще там проблема, просто забыли про off-heap память jvm.
@@ghostl3r Потрясающе. 30 минут одной фразой. Демонстрирует квалификацию. Любой нормальный мониторинг сразу такую ситуацию обнаруживает, чем всё это время занимались совершенно непонятно.
Что ты несёшь? Причем тут РФ? А что им делать, как не писать "велосипед", если альтернатив нет ? Поражают такие альтернативно одаренные... Ещё и напыщенности хоть отбавляй. Мда
Спасибо за доклад, интерено послушать такие кейсы
Страшно, очень страшно! Мы не знаем что это такое, если бы мы знали что это такое, мы не знаем что это такое!
Доклад проточная вода, никакой конкретики
А где это Spring использует JNI? Первый раз слышу.
Спасибо, очень интересный доклад. Не знал про эту особенность нативных функций.
дивився б це відео, не було б ніяких чорних сторін
Андрей Паньгин - Память Java процесса по полочкам
Была проблема , очень давно, рвались подключения к сервису, выглядело как сетевая ошибка, а на самом деле из-за ошибки в jni падал замертво тред на другой стороне, при этом сервис работал как ни в чем не бывало, а джава тихонько писала дамп себе в папочку.
Спасибо, интересно было послушать, но чувствуется, что до конца в итоге толком не разобрались. Но, будем иметь ввиду о таким особенностях
а какие библиотеки вы использовали ?
Не православньіе, от англосаксов
Я правильно понимаю, что некоторые люди заплатили деньги за то, что бы это послушать?
сверхкритичный финансовый процессинг, а на мониторинге нету алертов на занятость свопа?
это прям эпик фэйл, особенно с учётом того, что на осознание проблемы ушли месяцы.
Сталкивался с тем жён не .net core )))
30 минут ни о чем
видимо, доклад (на "отстань") ради доклада, чтобы сбер не просто так был первым в списке спонсоров
презентация - "топ": ни одной метрики, ни параметров и каких-либо величин
ответы на вопросы тоже шедевральны:
26:50 "ну.. э.. списка библиотек четкого нет.. э.. ну вот.. спринг.. э.."
27:41 "э.. точных замеров нет.. "
28:22 "э.. ну этот вопрос не до конца ясен.. четкого понимания нет.."
з.ы. вообще такое ощущение, что и проблема выдуманная ради того, чтобы хоть что-то рассказать на JPoint-е
Парню нужно было выступить, чтобы выполнить KPI и получить премию. Ну что вы пристали...
Слушать конечно было интересно, но не хватает конкретики, за полчаса доклада относительно полезной инфы - смотрите за ресурсами машины, играйтесь с JVM параметрами и читайте логи до конца.
Качество полезности точно не "уровня Сбера", как неоднократно выразился докладчик
По-моему, наоборот.
Как раз таки такой уровень и есть в сбере.
Немного странно что контейнер с приложенькой катастрофически аффектил хост систему. Ведро линукса должно было килять контейнер при первых признаках утечки памяти.
там нет контейнера
обрыв логов, внезапное падение, непостоянство падений. Что же может быть? По моему ответ очевиден на первом же признаке - тупо OOM. Вот и весь кейс. Ну и своп должен быть, лучше всего не меньше половине реальной ОЗУ (для СП). Плюс мониторинг использования ОЗУ в ОС. Плюс ОЗУ под линукс не освобождается джавой, если она сожрала память, то все она ее не отдаст. Сам участвовал в подобных расследованиях. Разрабам, не работавшим с "кровавым" энтерпрайзом, это наверное непривычно)) Кстати память сверх выделенной кучи, джава ест дай бог в энтепрайзе, поскольку нативный API используется самой джавой, например при обработке блобов. Свободную ОЗУ лучше держать равным >=0,5 от Xmx.
OOM по xmx все таки выдаст эксепшен в логи, а вот когда снаружи linux прихлопнет jvm, там да, обрыв логов симптом весьма характерный.
В остальном это конечно какой то испанский стыд для sre, что не определяется, что залезли в своп, что работал oom killer, что в мониторах не видели общую память сервера.
maloc
ух ))) детектив, прослушал на одном дыхании
Надеюсь, это был сарказм
@@ZhekaKozlov нет, почему сарказм, люблю такие истории. Сам в таких периодически участвую. С бубном даже танцую :)