Как связано время старта приложения и ребалансировка консьюмер группы?
У вас что - приложение запускается, читает и обрабатывает сообщение и гасится? Это какая-то полная хрень, как и часовые таймауты на обработку сообщения. Кафка вообще не для этого.
Странная статья. "Однажды, копаясь в админке ...", "Мы нашли настройку Xmx..." Странно что не упомянута проблема поиска выхода из vi ))) Инженеры-то у вас есть вообще в команде, знающие или способные разобраться в протоколе oauth/openid-connect, ну или которые знают что такое вообще application server. По статье такое впечатление что в "Магните" сплошной молодой, дружный коллектив и google-driven-development.
Используйте сборки bellsoft ( https://bell-sw.com/pages/downloads/ ) — там есть всё, что нужно, до сих пор поддерживается java 8, есть 11-я и все промежуточные версии. Всё бесплатно для любого использования, кому нужно — есть коммерческая поддержка.
Отличный доклад на эту тему с какого-то из джокеров: https://m.youtube.com/watch?v=EupF3VNXPPQ
"99% процентов перфомансной оптимизации — это исправление ТУПЕЙШИХ ошибок"
15-20 Мб RSS? Чё-то с трудом верится. Хотя всякое, конечно, бывает. На том сервисе, на котором я экспериментировал, он отъел плюс/минус столько же, сколько и в JVM режиме.
Кваркус (https://quarkus.io) компилируется в натив уже очень давно, в коде при этом ничего править или добавлять не нужно.
Для того, чтобы собрать приложение (jax-rs, cdi, jpa) в натив уходит примерно 10 минут полной загрузки четырёхядерной машины и 8 гб памяти.
Стартует оно быстро, это правда. Но в процессе старта есть задачи, не связанные с инициализацией jvm — накатить liquibase, подцепиться к кафке и т.п., по ним очевидно нет выигрыша во времени. В потреблении памяти и ЦПУ принципиальных различий не замечено, что вполне естетственно.
Вообщем мы пока решили что овчинка выделки не стоит. Хотя всё это, конечно, интересно и т.п.
Вообще, по нашим наблюдениям, в обычном jvm режиме кваркус сравнимой функциональности стартует примерно в 5 (пять) раз быстрее спринг-бута при тех же ограничениях по железу.
Разницу по широте, по долготе не сработает, длина параллелей зависит от удалённости от экватора.
И миля это не один градус по меридиану, а одна угловая минута (1/60 градуса).
Аккаунт либо котролируется баблом (и выражает точку зрения плательщика) либо нет (ведётся ткзть для души). Чем частное бабло лучше государственного — для здравомыслящего человека неясно.
Ну и что-то голос америки и всякие там радио свобода никто не спешит помечать. Вот ведь какая загогулина.
> Можете привести примеры таких (классов) приложений?
Почти все кэши, например Apache Ignite. В любом приложении, где надо хранить много данных в памяти, стоит посмотреть на такую возможность.
> И где по вашему мнению эти данные хранятся и как определить сколько они заняли выделенных им ресурсов?
Вне зависимости от «моего мнения» :-) они хранятся в оперативной памяти вне java хипа, т.е. настройка Xmx на их хранение не действует (и GC туда не ходит). Максимальный размер, который можно съесть в off heap, хранится в настройках приложения (каких именно — зависит от конкретного приложения).
> А где им место?
На отдельных серверах с «честной» файловой системой, вне кубера. Всё равно вы не сможете отмасштабировать тот же самый PostgreSQL просто увеличив кол-во подов.
Для некоторых классов приложений Xmx вообще слабо связан с реальным потреблением памяти, так как данные выносятся в off-heap. Странно что за 3 года эксплуатации явы в кубере они это не осознали )
На самом деле проблема выглядит если не надуманной, то уж явно преувеличенной. Гоняем яву в кубере (опеншифт) на проде уже несколько лет, полёт нормальный. А вот liveness/readyness пробы при старте stateful контейнеров это боль, да.
Вообще stateful штукам (БД, Кафка и т.п.) не место в кубере, особенно на распределённой ФС. Проблем много, выгода неочевидна.
До 2024 СБП будет бесплатной, насколько я знаю.
Очень удобная система, хотя как включить её в Сбере найти непросто )
Как связано время старта приложения и ребалансировка консьюмер группы?
У вас что - приложение запускается, читает и обрабатывает сообщение и гасится? Это какая-то полная хрень, как и часовые таймауты на обработку сообщения. Кафка вообще не для этого.
Navionics, iSailor - это не движки, конечно, это продукты.
Но роутить по воде, при условии, что у них есть данные по нужным участкам они умеют. Причём с учётом осадки судна.
Про майнинг прямо в точку.
Огромные ресурсы спускаются даже не в унитаз, а просто в никуда.
Странная статья.
"Однажды, копаясь в админке ...", "Мы нашли настройку Xmx..." Странно что не упомянута проблема поиска выхода из vi )))
Инженеры-то у вас есть вообще в команде, знающие или способные разобраться в протоколе oauth/openid-connect, ну или которые знают что такое вообще application server. По статье такое впечатление что в "Магните" сплошной молодой, дружный коллектив и google-driven-development.
Извините.
Существуют ли в стране - "глобальном ИТ гиганте" аналоги Яндекс или WeChat?
Используйте сборки bellsoft ( https://bell-sw.com/pages/downloads/ ) — там есть всё, что нужно, до сих пор поддерживается java 8, есть 11-я и все промежуточные версии. Всё бесплатно для любого использования, кому нужно — есть коммерческая поддержка.
Извините.
Отличный доклад на эту тему с какого-то из джокеров: https://m.youtube.com/watch?v=EupF3VNXPPQ
"99% процентов перфомансной оптимизации — это исправление ТУПЕЙШИХ ошибок"
А чем помогает сортировка полей json по алфавиту, как это увеличивает шанс нахождения повторяющихся фрагментов?
Кваркус (https://quarkus.io) компилируется в натив уже очень давно, в коде при этом ничего править или добавлять не нужно.
Для того, чтобы собрать приложение (jax-rs, cdi, jpa) в натив уходит примерно 10 минут полной загрузки четырёхядерной машины и 8 гб памяти.
Стартует оно быстро, это правда. Но в процессе старта есть задачи, не связанные с инициализацией jvm — накатить liquibase, подцепиться к кафке и т.п., по ним очевидно нет выигрыша во времени. В потреблении памяти и ЦПУ принципиальных различий не замечено, что вполне естетственно.
Вообщем мы пока решили что овчинка выделки не стоит. Хотя всё это, конечно, интересно и т.п.
Вообще, по нашим наблюдениям, в обычном jvm режиме кваркус сравнимой функциональности стартует примерно в 5 (пять) раз быстрее спринг-бута при тех же ограничениях по железу.
Расслабьтесь, никаких инопланетян не существует. Никто не прилетит, я узнавал.
Разницу по широте, по долготе не сработает, длина параллелей зависит от удалённости от экватора.
И миля это не один градус по меридиану, а одна угловая минута (1/60 градуса).
Странная затея. Если участвует производитель — то почему не сделать 3d модели по чертежам?
Аккаунт либо котролируется баблом (и выражает точку зрения плательщика) либо нет (ведётся ткзть для души). Чем частное бабло лучше государственного — для здравомыслящего человека неясно.
Ну и что-то голос америки и всякие там радио свобода никто не спешит помечать. Вот ведь какая загогулина.
Почти все кэши, например Apache Ignite. В любом приложении, где надо хранить много данных в памяти, стоит посмотреть на такую возможность.
> И где по вашему мнению эти данные хранятся и как определить сколько они заняли выделенных им ресурсов?
Вне зависимости от «моего мнения» :-) они хранятся в оперативной памяти вне java хипа, т.е. настройка Xmx на их хранение не действует (и GC туда не ходит). Максимальный размер, который можно съесть в off heap, хранится в настройках приложения (каких именно — зависит от конкретного приложения).
> А где им место?
На отдельных серверах с «честной» файловой системой, вне кубера. Всё равно вы не сможете отмасштабировать тот же самый PostgreSQL просто увеличив кол-во подов.
Для некоторых классов приложений Xmx вообще слабо связан с реальным потреблением памяти, так как данные выносятся в off-heap. Странно что за 3 года эксплуатации явы в кубере они это не осознали )
На самом деле проблема выглядит если не надуманной, то уж явно преувеличенной. Гоняем яву в кубере (опеншифт) на проде уже несколько лет, полёт нормальный. А вот liveness/readyness пробы при старте stateful контейнеров это боль, да.
Вообще stateful штукам (БД, Кафка и т.п.) не место в кубере, особенно на распределённой ФС. Проблем много, выгода неочевидна.
Рекомендую также глянуть старый, но всё ещё актуальный доклад с jpoint на эту тему:
https://youtu.be/3UP0o2gkeRQ