топики - это замы топов в компании, они должны предоставить к совету директором данные
Я в данный момент имею ситуацию, что несколько консьюмеров простаивает часть времени. При этом - один топик-1 имеет в несколько раз больше партиций, чем другие, в этом плане он уникален - консьюмеров значительно меньше, чем суммарное количество партиций во всех топиках - простаивание выглядит так - консьюмер читает-читает, потом внезапно в процессе чтения того самого уникального топика-01 замирает на часок, не переключаясь на другие. Разраб меня уверяет, что надо поднять количество партиций на всех топиках, чтоб они были как этот один, уникальный. Но меня все мучают сомнения. У меня совершенно точно не могут простаивать консьюмеры, потому что из меньше, чем это пресловутое суммарное число партиций на все топики
консьюмеры оперируют поколениями в которых брокер проводит перебалансировку консьюмер-групп
возможно у вас неравномерное распределение сообщений по партициям, поэтому часть консьюмеров вычитав свои партиции сидят и ждут новые сообщения. А переключаться на другие партиции они будут только если в других топиках пропадут их консьюмеры и начнётся перебалансировка то что у вас консьюмеров меньше чем общее число партиций - ещё ни о чём не говорит, некоторые приложения имеют свои внутренние потоки каждый из которых может выступать как самостоятельный консьюмер
а какая тебе разница сколько партиций у топика? больше не меньше, хуже не будет
Ну там в три раза надо поднимать, это ж все накладные расходы
какие? откуда вы эту дурь берёте, поделитесь, тоже курнуть хочу
Глубоко не искал, это да, но рассуждал так, что где-то надо хранить всю мету относительно партиций и т.п. Ссылки я не приведу, но попадалось такое в статьях
так, а причем тут кафка? она же инструмент всего лишь
если у вас не облако с платой на каждый кб, тьо вообще плевать, кафке надо рф+1(то есть для прода мин кол-во хостов 4), 6 cpu, 32 ram и ssd в каждый хост\вм, и она 3,5 млн сообщений в минуту на таком конфиге принимает, если поставить zgc и 17 jvm, какие накладнгые расходы боже
а на 21 джавке кафка отказывается работать?
не тестил ещё, пока ток на 19 пробовал
Насчёт zgc ещё интересный момент - он значительно увеличивает потребление heap приложением. Не сравнивали насколько при этом страдает производительность? Ведь Kafka выигрывает от page cache, если есть свободная оперативная память. При этом несмотря на паузы g1gc даёт не меньший throughput за счёт более эффективной сборки мусора. Если latency не важен. Может ошибаюсь, конечно.
в каком месте? у меня 6,5 млн в минуту сообщений сейчас на проде, потребление хипа 10 гб из 32 выделенных контейнеру
А с g1gc сколько было? На обычных приложениях zgc потребляет x3-4 хипа по сравнению со стандартным. Kafka вроде вообще к хипу не требовательна
она хип только при восстановлении юзает, вот тогда ей и 300 может быть мало
но когда у тебя задержки 10 мс против 130 на G1, вывод очевиден)))
G1 во всём хуже сейчас, при 11 java он ещё имел смысл, начиная с 17 - никакого если heap больше 30 гб, до 10 гб да, смысла юзать zgc смысла юзать нет никакого, причём самое интересное, чем больше буферы у кафки, тем хуже G1 и больше даёт zgc
Обсуждают сегодня