Queued.Max.Requests раньше это был скорее ограничивающая настройка. сейчас читаю, возможно

и уже смысл стала иметь, пробовал кто ставить 5000-10000?

думаете что упираетесь? а num.network.threads увеличивали? за NetworkProcessorAvgIdlePercent следите ?

ну думаю, знаю, часть сервисов не могут записать, num.network.threads и так 46 по числу ядер выделенных кафке

есть, нифига интересного, ну пишется по 6 млн в минуту, читается в 2 раза больше

Не, метрики именно про очередь, вдруг будет видно упирание в текущий лимит

надо посмотреть, не выводили ранее

чо нить типа kafka_server_request_queue_size, например. Но может быть херня, надо перебирать, их там дофига

Добый день. Поскажите, получилось проверить вот эту настройку? лучше/хуже стало? А то у меня тоже наблюдается странность - железных ресурсов куча, io, network threads куча, на стороне кафки ошибок нет, а клиенты когда их становится больше 500-600 начинают писать ошибки таймаутов записи в кафку... Думал накрутить еще network threads, background threads... Но может быть дело в предложенном вами queued.max.requests...

socket.send.buffer.bytes= socket.receive.buffer.bytes= socket.request.max.bytes= сколько? 600 клиентов это совсем копьё какой sysctl?

socket.send.buffer.bytes=102400 socket.receive.buffer.bytes=102400 socket.request.max.bytes=104857600 не совсем понял, вопрос "какой sysctl" - весь вывод показать или кокретных параметров?

ну ественно будет тупить socket.send.buffer.bytes=87108864 socket.receive.buffer.bytes=87108864 socket.request.max.bytes=368435456 надо хотя бы. 17 jvm zgc и 34 гб хипа

и тогда queued.max.requests нет смысла поднимать?