Как Protobuf съедал 411 ядер CPU на 100k RPS: физика GC в Go и перепроектирование gRPC-контрактов
Программный комитет ещё не принял решения по этому докладу
Целевая аудитория
Тезисы
Принято считать, что Protobuf «из коробки» гарантирует высокую скорость и компактность. Но что происходит, когда система перешагивает порог в 100 000 RPS, а входящий запрос содержит тысячи объектов?
На примере реального пайплайна агрегации в рекомендательной системе мы покажем, как «академически правильный» gRPC-контракт на Protobuf превращается в генератор мусора, сжигающий ресурсы сервера.
О чём поговорим:
Анатомия деградации: как standard protoc-gen-go в Go генерирует миллиарды аллокаций в секунду при анмаршалинге слоистых структур (oneof, google.protobuf.Timestamp, repeated messages).
Физика процесса: почему runtime.mallocgc и Mark Assist сборщика мусора блокируют бизнес-горутины, а Pointer Chasing разрушает кэш-линии CPU.
Прагматичный рефакторинг: как флаттеринг (flattening) структур, отказ от избыточных типы-обёрток и точечный переход на SoA (Structure of Arrays) снижают нагрузку на память.
Границы компромиссов: почему мы отказались от полного обнуления аллокаций через vtprotobuf + sync.Pool, выбрав баланс между безопасностью кода и производительностью.
Результаты: как изменение контрактов сэкономило 411 ядер CPU, 219 ГБ/с пропускной способности памяти и срезало 6.1 миллиарда объектов в секунду для GC.
Иван Синицын — технический лидер в Ozon Tech с более чем 8-летним опытом в IT. Он строил высоконагруженные системы, разрабатывал масштабируемые микросервисы для управления складскими процессами и создавал feature store для рекомендательной системы крупного ритейлера. Иван специализируется на Golang, оптимизации производительности, распределённых системах и эффективной обработке больших объёмов данных. Увлекается марафонами и садоводством.
Видео
Другие доклады секции
Языки программирования и технические стеки
