АТЛАНТА — Когда системы становятся достаточно большими, даже очень небольшая оптимизация может привести к очень большой экономии.
Именно этот урок преподал технический сотрудник OpenAI Фабиан Понсе перед основной аудиторией на конференции KubeCon+CloudNativeCon North America 2025, которая проходит на этой неделе в Атланте.
Проблема наблюдаемости OpenAI в масштабе
Каждая итерация ChatGPT OpenAI приносила большие улучшения, а также увеличивала количество кластеров Kubernetes и увеличивала объемы трафика. «И на порядки больше телеметрии, чтобы все это работало», — сказал Понсе.
Чтобы все работало гладко, OpenAI требует «абсолютно огромного объема телеметрии и делает ее быстрой, запрашиваемой и применимой в масштабе», — сказал он.
Критическая роль Fluent Bit в телеметрии данных
OpenAI запускает Fluent Bit, платформу наблюдения, управляемую Cloud Native Computing Foundation, на каждом узле Kubernetes. Он перерабатывает файлы журналов и обогащает их образцами сетевых потоков, форматирует результаты и отправляет их в соответствующие хранилища данных.
Благодаря архитектуре Fluent Bit генерирует 10 ПБ данных в день, которые хранятся в Clickhouse.
Стремление к эффективному использованию ресурсов в условиях стремительного роста
OpenAI, как признался Понсе, имеет «абсолютно ненасытный аппетит» к графическим процессорам. Генеральный директор OpenAI Сэм Альтман планирует использовать более 1 миллиона графических процессоров к концу года и обещает увеличить это число в 100 раз.
И всем этим графическим процессорам для работы также потребуются процессоры.
Таким образом, несмотря на эти гигантские заказы на закупку, инженеры компании по наблюдению все равно по-прежнему заботятся об эффективном использовании ресурсов. Поэтому одна из задач — сделать Fluent Bit максимально «бережливым».
Используя perf, инструмент Linux для сбора данных о производительности, команда наблюдения изучила циклы ЦП, которые использовал Fluent Bit. Понсе предположил, что большая часть работы, которую выполнял Fluent D, будет заключаться в подготовке и форматировании входящих данных.
Обнаружение неожиданного узкого места процессора с помощью perf
Но что удивило Понсе, так это то, что это было совсем не так. Вместо этого по крайней мере 35% данных было пережевано единственной функцией (fstatat64), целью которой было выяснить, насколько велики файлы журналов, прежде чем читать их.
Поэтому команда отключила эту возможность — и результаты были сразу очевидны:
«Результаты говорят сами за себя», — сказал собравшимся Фабиан Понсе. «У нас есть новый шаблон нагрузки, который использует примерно вдвое меньше процессорного времени, выполняя при этом ту же самую работу».
Каждый раз, когда записывается новый файл, Fluent Bit выполняет fstatat64, чтобы прочитать размер файла.
«Если процесс постоянно создает новые журналы, строка за строкой, то Fluent Bit будет участвовать в гонках и продолжать запускать fstatat64 каждый раз, когда это происходит», — объяснил Понсе. «Это сожжет массу дополнительных вычислительных ресурсов».
И оказывается, что компания на самом деле не нуждалась в этой информации, по крайней мере, на таком уровне нюансов.
Влияние отключения голодной функции
Хотя команда технического обслуживания знала, что это изменение снизит загрузку ЦП, возможно, их простят за то, что они не осознали, какую экономию можно получить.
Фактически, когда Fluent Bit был модифицирован системно, он «вернул около 30 000 ядер ЦП в наши кластеры Kubernetes», — сказал Понсе.
«Если мы сможем вернуть процессор в каждый узел, то, возможно, это будет еще один микросервис, который мы сможем разместить на данном хосте», — сказал он.
Команда продолжила оптимизировать Fluent Bit и другими способами, хотя эта настройка оказала наибольшее общее влияние. Инженеры компании готовят для Fluent Bit патч, который позволит пользователям указать более низкий порог уведомлений.
Ключевые выводы по оптимизации производительности
Вывод для Понсе был ясен: всегда полезно воспользоваться «любимым профилировщиком» и посмотреть, что происходит под капотом.
Как однажды посоветовал знаменитый программист Golang Роб Пайк в своей книге «Пять правил программирования»: «Вы не можете предсказать, где программа будет проводить свое время. Узкие места возникают в неожиданных местах».
А в больших распределенных системах эти маленькие узкие места могут стоить дорого, если их не устранить.
Вы можете насладиться всем разговором здесь:
ТЕНДЕНЦИОННЫЕ ИСТОРИИ YOUTUBE.COM/THENEWSTACK Технологии развиваются быстро, не пропустите ни одной серии. Подпишитесь на наш канал YouTube, чтобы смотреть все наши подкасты, интервью, демонстрации и многое другое. ПОДПИСАТЬСЯ Группа, созданная в Sketch. Джоаб Джексон — старший редактор The New Stack, специализирующийся на облачных вычислениях и системных операциях. Он освещал вопросы ИТ-инфраструктуры и ее развития более 30 лет, в том числе работал в IDG и Government Computer News. До этого он… Подробнее от Джоава Джексона
