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