Роман Таранов (Сбер) - Темная сторона Java 

Мы написали свой велосипед. 6000 потоков - нормальная ситуация. Да-да, конечно, у России свой особый путь. )) Я так понимаю, JVM на серваке с не менее чем десятком Xeon по 52 core (ну надо же на чем то всю эту тьму потоков исполнять)?. )) Проблема не в потоках JVM м GC непосредственно, проблема в нативных потоках, переключении контекста и фрагментации памяти на уровне ОС. Проблема фрагментации памяти частично решается заменой менеджера хип памяти в Linux. В целом доклад поверхностный и в проблеме, походу, до конца не разобрались.

Это не тёмная стороны явы, это тёмная сторона программистов сбера, которые на собесах спрашивают принципы солид и знание документации

Доклад проточная вода, никакой конкретики

30 минут ни о чем видимо, доклад (на "отстань") ради доклада, чтобы сбер не просто так был первым в списке спонсоров презентация - "топ": ни одной метрики, ни параметров и каких-либо величин ответы на вопросы тоже шедевральны: 26:50 "ну.. э.. списка библиотек четкого нет.. э.. ну вот.. спринг.. э.." 27:41 "э.. точных замеров нет.. " 28:22 "э.. ну этот вопрос не до конца ясен.. четкого понимания нет.." з.ы. вообще такое ощущение, что и проблема выдуманная ради того, чтобы хоть что-то рассказать на JPoint-е

Страшно, очень страшно! Мы не знаем что это такое, если бы мы знали что это такое, мы не знаем что это такое!

А где это Spring использует JNI? Первый раз слышу.

Я правильно понимаю, что некоторые люди заплатили деньги за то, что бы это послушать?

сверхкритичный финансовый процессинг, а на мониторинге нету алертов на занятость свопа? это прям эпик фэйл, особенно с учётом того, что на осознание проблемы ушли месяцы.

дивився б це відео, не було б ніяких чорних сторін Андрей Паньгин - Память Java процесса по полочкам

Спасибо за доклад, интерено послушать такие кейсы

обрыв логов, внезапное падение, непостоянство падений. Что же может быть? По моему ответ очевиден на первом же признаке - тупо OOM. Вот и весь кейс. Ну и своп должен быть, лучше всего не меньше половине реальной ОЗУ (для СП). Плюс мониторинг использования ОЗУ в ОС. Плюс ОЗУ под линукс не освобождается джавой, если она сожрала память, то все она ее не отдаст. Сам участвовал в подобных расследованиях. Разрабам, не работавшим с "кровавым" энтерпрайзом, это наверное непривычно)) Кстати память сверх выделенной кучи, джава ест дай бог в энтепрайзе, поскольку нативный API используется самой джавой, например при обработке блобов. Свободную ОЗУ лучше держать равным >=0,5 от Xmx.

Спасибо, интересно было послушать, но чувствуется, что до конца в итоге толком не разобрались. Но, будем иметь ввиду о таким особенностях

Спасибо, очень интересный доклад. Не знал про эту особенность нативных функций.

Была проблема , очень давно, рвались подключения к сервису, выглядело как сетевая ошибка, а на самом деле из-за ошибки в jni падал замертво тред на другой стороне, при этом сервис работал как ни в чем не бывало, а джава тихонько писала дамп себе в папочку.

Сталкивался с тем жён не .net core )))

maloc

а какие библиотеки вы использовали ?

Слушать конечно было интересно, но не хватает конкретики, за полчаса доклада относительно полезной инфы - смотрите за ресурсами машины, играйтесь с JVM параметрами и читайте логи до конца. Качество полезности точно не "уровня Сбера", как неоднократно выразился докладчик

Немного странно что контейнер с приложенькой катастрофически аффектил хост систему. Ведро линукса должно было килять контейнер при первых признаках утечки памяти.

ух ))) детектив, прослушал на одном дыхании