ScyllaDB спонсировала этот пост.
Если вы знаете P99 CONF, вы, вероятно, не можете дождаться P99 CONF 2025. Премьера состоится в вашем браузере 22 и 23 октября, а в программе будет множество новых докладчиков, а также несколько давних фаворитов.
Если вы еще не знакомы с P99 CONF, это бесплатное двухдневное мероприятие сообщества, посвященное разработке производительности и низкой задержке. Он намеренно виртуальный, высокоинтерактивный и глубоко технический. В этом году вы можете рассчитывать на инженерный опыт из первых рук от таких компаний, как Clickhouse, Gemini, Arm, NVIDIA, Pinterest, Rivian/Volkswagen, Meta, Wayfair, Disney, Turso, Neon, PlanetScale, ScyllaDB и многих других, чтобы перечислять их здесь.
Поскольку до P99 CONF 2025 осталось всего несколько дней (подробнее об этом позже), мы подумали, что сейчас самое время поделиться некоторыми из самых обсуждаемых сессий P99 CONF 2024. Вы также можете просмотреть более 200 технических докладов с низкой задержкой (бесплатно и без ограничений) в библиотеке по требованию.
Зарегистрируйтесь на P99 CONF, бесплатно и виртуально.
Шаблоны низкой задержки
Пекка Энберг (соучредитель и технический директор Tueso)
Пекка Энберг начинает свое выступление с навязчивой мысли: «Латентность скрывается повсюду». Но, к счастью для зрителей, Энберг одержимо думал о задержке как с точки зрения инженера базы данных, так и с точки зрения автора книги «Задержка». Вероятно, именно поэтому Энберг может предоставить чрезвычайно полный обзор того, как найти, измерить и устранить задержку всего за 30 минут.
Энберг начинает с рассмотрения того, почему задержка имеет значение, почему задержка хвоста оказывает большее влияние, чем думает большинство людей, и почему средние задержки по сути бессмысленны. Ловушка скоординированного упущения здесь заслуживает особого внимания, опираясь на то, что Гил Тен представил в прошлом программном докладе P99 CONF «Показатели и последствия страдания».
Далее Энберг делится тремя способами устранения задержек: избегать перемещения данных, избегать работы и избегать ожидания. Перемещение байтов неизбежно требует времени, поэтому могут помочь совместное размещение, репликация или кэширование. Делать меньше – это зачастую самая большая победа. Выбирайте правильные алгоритмы, избегайте динамического распределения памяти по горячему пути и не позволяйте тяжеловесной синхронизации или операционной системе препятствовать вашему прогрессу. Даже такая мелочь, как переключение контекста, может снизить задержку.
Если вы не можете еще больше сократить задержку, пришло время ее скрыть. Энберг рассматривает практические стратегии, такие как распараллеливание обработки запросов, хеджирование запросов между серверами и использование облегченных потоков. В заключение он напоминает, что настройка системы тоже имеет значение: такие вещи, как масштабирование ЦП, обмен данными и обработка прерываний, могут увеличить или уменьшить задержку. Итог: измеряйте хвост, атакуйте его со всех сторон и сделайте низкую задержку первоклассной целью проектирования.
Уменьшите (задержку)
Бенджамин Кейн (заслуженный инженер American Express) и Тайлер Ведин (вице-президент, инженер по надежности сайтов глобальной платежной сети в American Express)
Команда American Express Payments Network недавно завершила четырехлетний проект по обновлению платформы карточных платежей компании. Система должна была быть достаточно быстрой, чтобы обрабатывать огромные объемы глобально распределенных транзакций с низкой задержкой и чрезвычайной отказоустойчивостью. Он также должен был быть достаточно гибким, чтобы команда могла быстро меняться в зависимости от часто меняющихся потребностей платежной индустрии.
Кейн и Ведин решают проблемы, возникающие при разбиении ранее монолитной системы на распределенные сервисы: добавление сетевых переходов, межрегиональные задержки, зависимость от устройств с отслеживанием состояния и бесчисленные «бумажные сокращения», которые снижают производительность и доступность.
Они устранили узкие места с помощью ячеистой архитектуры, локальности данных и межсервисной связи на основе HTTP/2. Каждая ячейка была автономной и имела собственный кластер Kubernetes, данные и вспомогательные сервисы. Таким образом, транзакции могут обрабатываться локально без переходов между регионами. Данные распределялись с использованием трех подходов (в порядке предпочтения): предварительно загруженный кэш сквозного чтения для статических значений, репликация для конечной согласованности и сходство транзакций, когда требовалась строгая согласованность. Вызовы служб были переведены на HTTP/2 с помощью Service Mesh (Envoy) для балансировки нагрузки, а зависимость от устройств с отслеживанием состояния была снижена за счет использования прямой и безопасной связи между модулями.
Главный урок получен? По словам Кейна: «Чтобы добиться низкой задержки, вы должны сосредоточиться на локальности: выбрать наиболее прямой путь. Чтобы получить низкую задержку, вы должны ограничить свои зависимости. Передайте данные в свои ячейки или узлы заранее, чтобы они были там, когда транзакция в них нуждается. Вам также необходимо использовать асинхронную связь вместо синхронной. Самое главное, вы должны сделать задержку и отказоустойчивость первоклассными функциями вашей платформы. Это то, что мы сделали с самого начала. Мы определили соглашения об уровне обслуживания [service-level agreements]установили цели ниже, чем в соглашениях об уровне обслуживания, и сделали это основной частью платформы. Если задержка была не такой, какой должна быть, мы останавливали процесс разработки и исправляли ее».
Испытание на 1 миллиард рядов в Голанге
Шраддха Агравал, старший инженер-программист Ceph, IBM
Насколько быстро может идти Го? Это то, что Шраддха Агравал пыталась обнаружить в своем подходе к соревнованию «1 миллиард рядов» (1BRC). Если вы пропустили это в прошлом году, 1BRC был задуман как увлекательное исследование того, насколько далеко можно продвинуть современную Java для агрегирования 1 миллиарда строк из текстового файла. Но его создатель Гуннар Морлинг также ожидал, что оно «будет интересно примерно дюжине людей». В конечном итоге сотни людей реализовали задачу на Go, Rust, C/C++, C#, Fortran и даже в базах данных — так что этот проект превзошёл ожидания во всех отношениях.
Бонус: Морлинг также представил приемы обмена ключевыми докладами P99 CONF 2024, которые самые быстрые решения 1BRC использовали для обработки входного файла задания размером 13 ГБ менее чем за две секунды.
Начав с простой базовой реализации с нулевым параллелизмом, Агравал измерил шестиминутное время выполнения синтаксического анализа и агрегирования данных. После этого она использовала инструменты производительности Go для управления каждым шагом оптимизации. Внедрение параллелизма путем создания примерно 10 000 горутин (по одной на город) сократило время примерно до 4,5 минут, но также привело к увеличению накладных расходов на канал и планировщик. Переход от небуферизованных к буферизованным каналам, пакетная обработка строк и переосмысление структур данных обеспечили постепенные улучшения. И она сократила затраты времени и памяти, заменив арифметику с плавающей запятой целочисленной арифметикой и сохранив только мин/макс/сумму/счет вместо списков полных значений.
Компактный дизайн в стиле MapReduce позволил сэкономить больше секунд. Файл был прочитан частями по 64 МБ, проанализирован параллельно девятью рабочими горутинами и объединен в сводные карты с помощью редуктора. Поскольку их кормил один продюсер, это означало всего 10 горутин. Это сократило трафик канала с 10 миллионов элементов до 512 и сократило время выполнения до 28 секунд.
В видео Агравал шаг за шагом проведет вас через весь путь, со множеством графиков пламени, советами по инструментам и уроками, извлеченными на этом пути.
Контейнерная сеть с нулевыми издержками с помощью eBPF и Netkit
Лиз Райс, директор по открытому коду в Isolvant (теперь часть Cisco)
Запуск приложений внутри контейнеров может привести к удивительному увеличению сетевых издержек. Тесты на 100-гигабитном Ethernet показывают, что приложения, работающие непосредственно на хосте, достигают скорости, близкой к проводной. Однако, как только они помещаются в контейнер, пропускная способность падает примерно до двух третей. Именно об этом говорила вечная фаворитка P99 CONF Лиз Райс в своем выступлении на P99 CONF 2024.
Райс объяснила падение пропускной способности двумя основными причинами. Во-первых, пакеты дважды пересекают сетевой стек. Во-вторых, обратное давление TCP позволяет снизить ограничения буфера сокетов, что приводит к потере пакетов, а также к ограничению пропускной способности.
Оттуда она показала, как eBPF может обойти верхний сетевой стек хоста. Вспомогательные функции, добавленные в Linux 5.10 (bpf_redirect_peer и bpf_redirect_neigh), могут более эффективно перенаправлять пакеты между пространствами имен. Это приближает пропускную способность к производительности родного хоста: в ее тестах она составляет около 90 гигабит. Дополнительные улучшения появились в TCX — переработанном способе подключения программ eBPF к сетевому стеку.
Следующим шагом Райс стали сетевые устройства, представленные в Linux 6.6. Эти минимальные, программируемые с помощью BPF устройства заменяют виртуальные соединения Ethernet и устраняют очереди. Они также позволяют перенаправлять пакеты в контексте потока приложения. Это окупается как с точки зрения пропускной способности, так и с точки зрения задержки: контейнеризованные приложения обеспечивают такую же сетевую производительность, как и работа непосредственно на хосте.
Наконец, Райс показывает, что эти достижения уже интегрированы в Cilium, что делает работу контейнерной сети с нулевыми издержками доступной в последних ядрах.
Далее в отношениях любви и ненависти Sordid DB/OS
Энди Павло, доцент Университета Карнеги-Меллона
Докладчик представил довольно красочный и исчерпывающий тезис своего доклада. Мы не думали, что наш вариант сможет передать это должным образом — так что вот, как выразился Павел.
«Системы управления базами данных (СУБД) — это прекрасное, свободное по духу программное обеспечение, которое не хочет ничего, кроме как помочь пользователям хранить данные и получать к ним доступ как можно быстрее. Для достижения этой цели СУБД потратили десятилетия, пытаясь любой ценой избегать операционных систем (ОС). Такое избегание необходимо, потому что операционные системы всегда пытаются навязать свою волю СУБД и подавить их амбиции посредством неискренней семантики системных вызовов, немасштабируемых структур данных на уровне ядра и чрезмерное копирование данных.
«Многие попытки обойти ОС с помощью методов обхода ядра или специального оборудования сопряжены с такими высокими затратами на проектирование/НИОКР, что лишь немногие СУБД поддерживают их. В конце концов, СУБД застревают в неправомерных отношениях: им нужна ОС для запуска своего программного обеспечения и предоставления им базовых функций (например, распределения памяти), но им не нравится, как ОС с ними обращается. Однако новые технологии, такие как eBPF, которые позволяют СУБД безопасно запускать собственный код внутри ядро ОС, чтобы переопределить его функциональность, готовы положить конец этой борьбе за власть.
«В этом докладе я представляю новый подход к проектированию под названием «обход пользователя» для создания высокопроизводительных систем и сервисов баз данных с помощью eBPF. Я обсуждаю последние разработки в eBPF, имеющие отношение к сообществу СУБД, и какие части СУБД наиболее удобны для его использования. И я представляю дизайн BPF-DB, встроенной СУБД, написанной на eBPF, которая обеспечивает транзакции ACID для многоверсионных данных и полностью работает в Linux ядро».
Присоединяйтесь к сообществу P99 CONF 2025.
Как и сообщество P99 CONF, команда P99 CONF не может прекратить оптимизацию и настройку. И это подводит нас к P99 CONF 2025. Вот краткий обзор того, что стоит на повестке дня:
- Алексей Миловидов: «Путешествие Clickhouse’s C++ и Rust»
- Чип Хьюен: «Оптимизация вывода LLM»
- Санчай Джаверия: «Создание потоковых приложений Pinterest с помощью Apache Flink»
- Саахил Хурана, Маркус Ким: «Подпоток push-уведомлений Rivian с мегафильтром»
- Кристиан Веласкес: «Методы оптимизации памяти, которые позволили Uber P99 работать меньше 1 мс»
- Джеффри Блейк: «Нахождение точек производительности в стогах сена с помощью APerf»
- Танель Подер: «Эффективное постоянное наблюдение за потоками с помощью eBPF»
- Глаубер Коста: «Почему мы переписываем SQLite на Rust»
- Эй Джей. Стайвенберг: «Как мы перестроили расширение Datadog Lambda на Rust»
- Кристиан Шварц: «Переработка стека Neon IO: Rust+tokio+io_uring+O_DIRECT»
Если вы заинтригованы этими докладами, а также техническими дискуссиями об искусственном интеллекте и машинном обучении, распределенных системах данных, Kubernetes и наблюдаемости, присоединяйтесь к нам, чтобы получить массу знаний и технических развлечений.
Зарегистрируйтесь на P99 CONF, бесплатно и виртуально.
ScyllaDB спроектирована для обеспечения предсказуемой производительности в любом масштабе. Его используют организации, которым требуется сверхнизкая задержка, даже при рабочих нагрузках, превышающих 1 млн операций в секунду. Наша уникальная архитектура использует возможности современной инфраструктуры, что приводит к меньшему количеству узлов, меньшему администрированию и меньшим затратам. Узнайте больше Последние новости от ScyllaDB ТЕНДЕНЦИОННЫЕ ИСТОРИИ YOUTUBE.COM/THENEWSTACK Технологии развиваются быстро, не пропустите ни одного эпизода. Подпишитесь на наш канал YouTube, чтобы смотреть все наши подкасты, интервью, демонстрации и многое другое. ПОДПИСАТЬСЯ Группа, созданная в Sketch. Синтия Данлоп пишет о разработке и тестировании программного обеспечения гораздо дольше, чем ей хотелось бы признать. В настоящее время она является старшим директором по контент-стратегии в ScyllaDB. Узнайте больше от Синтии Данлоп
