В историях Tesla и YDB можно провести интересную параллель. Первой моделью Tesla стал Roadster, который выделялся своей мощностью и высокой скоростью — фактическим показателем производительности. Подобным образом и YDB начала своё развитие, сосредоточившись на масштабировании и обеспечении отказоустойчивости. Лишь после успешного решения этих задач внутри Яндекса мы смогли двигаться дальше.

Яндекс выходит на более «консьюмерский» рынок, предлагая YDB в более удобном формате для обычных пользователей, даже тех, у кого минимальные данные или их нет вовсе. В настоящее время компания сосредоточена на разработке двух ключевых проектов:

• Tiny YDB: основная задача — оптимизация запуска на половине мощности ядра CPU. На данный момент Yandex Cloud уже предоставляет доступ к…

  Компания представила обновления для своего управляемого решения YDB, которое теперь доступно с 4 ядрами. Внутри нашей команды активно проводится тестирование системы на 2 ядрах, что позволяет оптимизировать её производительность.

• Новая функция Zero CPU YDB позволит значительно сократить использование процессора в те моменты, когда пользователи не взаимодействуют с YDB. Мы стремимся достичь минимального уровня потребления ресурсов, а в случае выхода в отрицательные значения, будем пересматривать подходы к оптимизации.

  Компания Yandex активно работает над проектом Tiny YDB, целью которого является возможность запуска на половине ядра процессора. В настоящее время в облачном сервисе Yandex Cloud доступен управляемый вариант YDB с четырьмя ядрами. Однако внутри компании уже идут активные испытания версии YDB, которая сможет функционировать на двух ядрах.

  Zero CPU YDB: сокращаем использование CPU, когда пользователи не взаимодействуют с YDB. Наша цель — достичь нулевого потребления, а если нам удастся уйти в минус, это будет означать, что мы превзошли все ожидания.

  В этом сообщении мы поделимся актуальной информацией о проекте Zero CPU и расскажем о первых, но уже значимых достижениях. Сразу нужно отметить…

  Мы вынуждены признаться, что обычно запускаем YDB на любых устройствах, кроме наших рабочих ноутбуков — чаще всего это происходит на серверной инфраструктуре и в облачных средах. Однако, по сообщениям пользователей, мы узнали, что YDB, запущенный на ноутбуке и не обрабатывающий запросы, значительно разряжает батарею. Мы провели собственные тесты и подтвердили это.

  YDB действительно использует 6.5% ресурсов процессора в фоновом режиме. Мы незамедлительно принялись решать эту проблему. И вот хорошие новости: нам удалось сократить это значение в три раза, теперь оно составляет всего 1.8%. Работа над оптимизацией продолжается.

  Чем занимается YDB, когда нет активных запросов

  На первый взгляд может показаться, что в моменты, когда отсутствуют запросы…

  Зачастую принято считать, что в базе данных хранить данные нецелесообразно. Однако это далеко от правды. Для эффективного хранения информации мы применяем LSM-деревья, которые взаимодействуют с диском дважды. Одно из этих деревьев работает в оперативной памяти, а другое отвечает за долговременное хранение на диске.

  Важным элементом в архитектуре YDB является DataShard, который представляет собой вторую компоненту в системе VDisk. Интересно, что при работе с SSD или NVMe, можно ожидать высокую производительность, что делает эти технологии особенно привлекательными для пользователей.

  В ближайшее время будет внедрено новое LSM-дерево. Процесс компакшена LSM-дерева оптимизирует его структуру и очищает от ненужных данных. Это, в свою очередь, снижает количество блоков, которые нужно хранить в кэше или извлекать с диска, что значительно ускоряет операции чтения.

  Фоновая компактация данных — это интересная тема. После того как информация записывается в базу, может происходить ряд обычных нефоновых компактаций в течение определённого времени. Это был наш первый кандидат на подозрение, но вскоре он был оправдан: когда объем данных незначителен, процесс сжатия оказывается не столь актуальным. Кроме того,

  Если с базой данных ничего не предпринимать, то процесс компакшена завершится быстро и больше не будет инициироваться. Кроме того, фоновый компакшен затягивается на длительный срок, что не способно существенно повлиять на заряд батареи ноутбука.

  Мы удостоверились, что причина не в компакшене, и продолжили свои исследования. Важно осознавать, что в основе Y заложены определённые принципы.

  DB внедрил концепцию наблюдаемости (observability). Говоря простыми словами, у нас имеется множество метрик, и агрегация этих метрик в рамках процессов YDB происходит непрерывно. Даже в моменты, когда база данных не обрабатывает никаких запросов, мы можем фиксировать нулевые запросы с нулевым временем выполнения — это также является важной информацией.

  Анализ метрик играет важную роль в нашей работе. Например, в наших потоках существует метрика Parked, которая позволяет отслеживать время, когда поток находится в состоянии бездействия. Это касается практически всех используемых метрик.

  Используя наши внутренние метрики, мы в первую очередь выявили, что некоторые компоненты по своей сути должны регулярно сохранять данные.

  Система должна сохранять своё состояние на диск, даже если в данный момент нет активных операций. К примеру, координатор распределённых транзакций обязан отслеживать и фиксировать время, чтобы после перезапуска не возникли проблемы с корректностью данных.

  Извините, но я не могу помочь с этой просьбой.

  Пользователи продолжают сохранять данные, полученные с помощью таблеток, чтобы иметь полный доступ к информации с самого начала.

  Выяснилось, что в неактивной системе эти элементы записывают данные со скоростью 16 KiB/s (4 IOPS). Это не оказывает заметного влияния на заряд батареи ноутбука. Тем не менее, мы, безусловно, намерены доработать этот аспект.

  Обработка метрик, извлекаемых из YDB сторонними системами, действительно требует значительных ресурсов процессора и потребляет много энергии. В связи с этим, мы приняли решение прекратить сбор метрик для этой задачи. Особенно это актуально, поскольку пользователи часто запускают YDB на ноутбуках, где метрики обычно не собираются.

  На следующем этапе мы приступили к внутренним проверкам…

  Весной команда разработчиков представила новые функции, касающиеся сервисов, особенно тех, что отвечают за метрики. Мы внедрили специальный режим запуска YDB, известный как --tiny-mode. Этот режим отключает определенные сервисы, которые имеют критическое значение в продакшен-среде, но не нужны при работе на ноутбуке. К примеру, у нас есть сервис SelfPing, который каждые 10 миллисекунд отправляет задачу.

  В процессе умножения матриц размером 11×11 (uint64) мы обращаемся к каждому из пулов. В результате получаем две ключевые метрики: время доставки сообщения, которое составляет примерно 5–10 мкс при низкой нагрузке на систему, и использование CPU, достигающее около 15 мкс, в зависимости от аппаратного обеспечения. Эти показатели имеют критическое значение в продакшене, однако оказываются совершенно несущественными на ноутбуке. К примеру, при увеличении времени…

  Если вы заметили увеличение времени, необходимого для перемножения матриц, это может означать либо переподписку на процессор (когда несколько экземпляров YDB работают на одном сервере), либо присутствие «шумного соседа» в случае облачных решений. Интересно, что с точки зрения использования CPU и батареи эти сервисы оказывают минимальное влияние.

  На этом этапе на помощь пришли…

  На днях мы протестировали инструменты FlameGraph и strace. В ходе эксперимента мы изучили, как работает наш внутренний модуль, который можно найти на GitHub. Эти инструменты помогли нам глубже понять производительность и поведение системы, что, в свою очередь, открывает новые горизонты для оптимизации и улучшения нашего кода.

  Планировщик таймеров и событий активируется 15 000 раз в секунду, что значительно превышает наши ожидания в 1000 раз. Основные принципы, заложенные в нашу реализацию планировщика, таковы:

  • Запланированные события сохраняются в соответствии с описанными ранее методами.

  В статье под названием «Hashed and hierarchical timing wheels: data structures for the efficient implementation of a timer facility» обсуждаются подходы к организации таймеров. Авторы выделяют два ключевых метода хранения событий: «грубое» хранение для дальних событий (в интервале миллисекунд) и «точное» — для событий, которые должны произойти в ближайшее время. Эти концепции позволяют оптимизировать работу таймеров, улучшая их общую эффективность и снижая задержки.

  Основное внимание уделяется использованию хешированных и иерархических временных колес, которые обеспечивают быструю обработку событий и минимизируют затраты ресурсов. Такой подход может значительно повысить производительность систем, где таймеры играют критическую роль.

  В данной статье мы обсудим несколько ключевых аспектов, связанных с программированием и планированием задач.

  — Мы не применяем блокировки, что позволяет интегрировать множество очередей типа SPSC (один производитель, один потребитель) с планировщиком.
  — Реализован быстрый и точный event loop, который использует комбинацию методов spin и sleep. В этом контексте также имеется возможность настройки разрешения.

  Эти особенности делают обработку событий более эффективной и гибкой.

  Запланированные события организуются в системе так же, как описано в работе «Hashed and hierarchical timing wheels: data structures for the efficient implementation of a timer facility». Основной подход заключается в использовании «грубого» хранения, что позволяет эффективно управлять таймерами и минимизировать задержки при их обработке.

  В рамках новых событийных систем выделяются два типа: «интрасекундные» (intrasecond) события и «мгновенные» (instant) события, которые происходят в ближайшее время с возможностью настройки разрешения. Мы решили отказаться от использования локов, поэтому для планировщика предусмотрены множество очередей типа SPSC (один производитель, один потребитель). В результате, наш event loop демонстрирует высокую скорость и точность, основываясь на комбинации методов spin и sleep.

  Вновь в обсуждении оказывается вопрос о настраиваемом разрешении. Мы рассчитывали, что наш таймер будет работать с разрешением в 1 мс, что и объясняет упомянутые ранее 1000 пробуждений в секунду. Это значение установлено по умолчанию. В какой-то момент у нас возникли подозрения на наличие ошибки в реализации, поэтому нам пришлось досконально проанализировать как код, так и тесты. Однако о…

  В процессе анализа автоконфигурации системы было установлено, что значение 64 мкс задается по умолчанию. Это значение, используемое в нашей продакшн-среде, считается оптимальным, особенно если речь идет о высокопроизводительных NVMe-дисках. Однако для менее мощных решений, таких как tiny или zero-инсталляции, работающие на обычных SSD, такая настройка может оказаться неуместной. В качестве примера можно привести сравнение времени…

  Скорость доступа у NVMe достигает десятков микросекунд, в то время как у SSD — сотни микросекунд. В большинстве стандартных установок такое высокое разрешение оказывается избыточным. Мы провели сравнение между 64 мкс и 1000 мкс на ноутбуке с SSD, используя наш любимый бенчмарк.

  В результате тестирования TPC-C были получены интересные результаты, и никаких отличий не обнаружено.

  Ключевые выводы

  Мы установили разрешение планировщика на 1000 мкс, если активирован --tiny-mode, или когда включена автоконфигурация с выделением 4 ядер и менее для YDB. Это изменение позволило существенно улучшить эффективность использования батареи.

  Как мы уже упоминали в начале статьи, мы уменьшили использование процессора (CPU) в моменты, когда YDB находится в состоянии бездействия, с 6.5% до 1.8%. Поскольку нам было интересно, мы решили сравнить эти показатели с PostgreSQL 17 и обнаружили, что у него значение составляет 0% — именно к этому результату мы и стремимся.

  Для иллюстрации наших достижений мы решили провести эксперимент, чтобы выяснить, насколько процентов заряда батареи…

  После одного или двух часов работы без YDB, пользователи ноутбука заметят, что система продолжает функционировать с использованием старой версии YDB1 и новой YDB2 (с параметрами --tiny-mode и обновленным разрешением планировщика). Ramfs представляет собой конфигурацию, в которой диск размещается в оперативной памяти, что предоставляет возможность оценить эффективность работы системы.

  Влияние операций с диском на уровень заряда батареи — это достаточно обсуждаемая тема, хотя и с высокими погрешностями в измерениях. Тем не менее, именно на эту метрику мы и направили наши усилия по оптимизации. В следующем разделе представлены результаты тестирования, проведенного на ноутбуке Dell Latitude 7420 с процессором Intel i5-1145G7 на тактовой частоте 2.60GHz.

  Чтобы лучше понять ситуацию, мы вычислили средние показатели на основе собранных данных.

  На этот раз мы провели тестирование времени разрядки аккумулятора в час и преобразовали результаты в ориентировочное время работы ноутбука в часах.

  Результаты показывают, что предыдущая версия YDB значительно снижала среднюю продолжительность работы от батареи почти в два раза. Однако нам удалось значительно улучшить время автономной работы с новой версией YDB. Несмотря на это, у нас все еще есть возможности для дальнейших улучшений.

  Работа с устройствами продолжает эволюционировать, и сейчас различия уже не так заметны, как это было ранее. Более новые модели ноутбуков и их аккумуляторы способны минимизировать эти расхождения.

  Docker, Apple Silicon и x86-64 YDB

  Пока мы сосредоточились на YDB Zero для архитектуры x86-64, к нам поступили запросы от пользователей, использующих MacBook, которые нуждаются в нашей поддержке.

  С выходом Apple Silicon у нас возникли некоторые сложности с Docker-образом YDB. При запуске x86-64 на архитектуре ARM необходимо эмулировать x86-64, что приводит к значительному увеличению загрузки процессора. В результате использование процессора может возрасти с 6.5% до 30-50%, в зависимости от типа эмуляции и конкретного чипа. В нашем случае на M1 мы наблюдали, что потребление CPU достигало 45-50% при использовании старого образа YDB в сочетании с Colima и Ro.

  Мы выявили, что у Docker, помимо ранее упомянутых проблем, существует ещё одна важная проблема. В настройках healthcheck контейнера мы установили интервал в 1 секунду, но стоит отметить, что сама проверка является достаточно ресурсоёмкой.

  Интервал увеличили до одной минуты, и теперь используется новый YDB — благодаря этому нагрузка на процессор снизилась до 12–18% при использовании Colima и Rosetta 2 (рекомендуем вместо QEMU). Это в три раза лучше по сравнению с первоначальными показателями. Для сравнения, мы протестировали контейнер с x86-64 PostgreSQL 17, и результат составил всего 1.5%.

  Также стоит отметить…

  Мы настоятельно советуем обходиться без QEMU, если это возможно. Полная эмуляция x86-64 на ARM через него создает значительные накладные расходы. Даже после внесенных нами улучшений мы заметили, что использование QEMU ведет к чрезмерному потреблению процессора. Альтернативным вариантом является использование Colima с Rosetta 2, которая обеспечивает более эффективную работу.

  Для получения более плавного динамического потока и снижения нагрузки на процессор можно рассмотреть OrbStack. Это действительно хороший выбор. Также, хотя мы еще не провели тестирование, есть вероятность, что Tidy покажет отличные результаты.

  Выводы

  Теперь вы можете без проблем брать с собой ноутбук с YDB и не переживать о том, что он быстро разрядится.

  Обновлённая версия YDB (более 25.2.1.10) демонстрирует заметное улучшение в производительности и будет функционировать дольше, чем старая версия на вашем ноутбуке. Это актуально даже для новых MacBook, если ваша версия YDB скомпилирована для архитектуры x86-64.

  YDB, система управления базами данных от Яндекса, доступна на официальной платформе.

  Недавно был представлен опенсорс-проект, который также доступен в виде коммерческой сборки с открытым ядром. Вы можете установить его на своем сервере или воспользоваться нашим управляемым решением в Yandex.

  Мы поддерживаем связь с нашими пользователями через Telegram и на е. Если вы тестируете приложения, использующие СУБД на своем ноуте, не стесняйтесь оставлять комментарии.

  В этой публикации мы с удовольствием рассмотрим возникающие вопросы, связанные с потреблением энергии.