Когда компания Meta занялась поиском более совершенного планировщика ЦП Linux для своего огромного парка серверов, она начала не с анализа данных в дата-центре. Вместо этого отправной точкой стал портативный игровой ПК. В недавнем техническом докладе на конференции Linux Plumbers’ Conference в Токио инженеры Meta подробно рассказали о том, как они развертывают SCX-LAVD, планировщик Linux с низкой задержкой, первоначально разработанный компанией Valve для Steam Deck, на производственных серверах, поддерживающих все, от серверных частей обмена сообщениями до служб кэширования. Удивительный вывод: планировщик, разработанный для обеспечения быстрого отклика игр при нагрузке, оказался отлично подходит и для масштабных нагрузок дата-центров.
В общих чертах, планировщик ЦП решает, какие программы и когда будут выполняться на ядрах ЦП. Стандартный планировщик Linux должен работать везде — на телефонах, ноутбуках, настольных компьютерах, серверах, — что делает его чрезвычайно консервативным. Задача Meta иная: компания эксплуатирует огромные машины с сотнями ядер ЦП, чрезвычайно разнообразными рабочими нагрузками и, что самое важное, строгими целевыми показателями задержки. В такой среде “достаточно хорошо везде” зачастую недостаточно. Вместо того, чтобы создавать собственный планировщик для каждой службы, Meta хотела получить что-то близкое к общему планировщику для всего парка, “универсальный” планировщик, который мог бы адаптироваться автоматически без ручной настройки. Именно здесь на помощь пришел SCX-LAVD.
SCX-LAVD построен на базе sched_ext, относительно новой платформы Linux, которая позволяет подключать альтернативные планировщики к ядру без значительной модификации ядра. Проще говоря, sched_ext позволяет компаниям безопасно и постепенно экспериментировать с различными стратегиями планирования, вместо того чтобы создавать форк Linux или поддерживать огромные наборы патчей.
LAVD расшифровывается как Latency-Aware Virtual Deadline (виртуальный дедлайн с учетом задержки), и название говорит само за себя, если вы внимательны. Вместо того, чтобы полагаться на статические приоритеты или ручные подсказки, планировщик постоянно наблюдает за поведением задач, как часто они спят, просыпаются и блокируются, а затем оценивает, какие из них чувствительны к задержкам. Эти задачи получают более ранние “виртуальные дедлайны”, что увеличивает их шансы на быстрое выполнение, когда система загружена.
Первоначально этот подход был мотивирован играми. На Steam Deck пропущенные сроки планирования приводят к пропущенным кадрам, заиканиям или замедленной реакции на ввод. Как оказалось, в дата-центре те же самые сбои проявляются в виде медленных веб-запросов, задержек сообщений или невыполненных целевых показателей уровня обслуживания. Совершенно разные приложения, но, по сути, одна и та же проблема.
В презентации инженеры Meta описали несколько проблем, которые возникли при масштабировании LAVD до оборудования серверного класса. На машинах с десятками ядер, совместно использующих одну очередь планирования, конкуренция стала узким местом. Закрепленные задачи, то есть потоки, которые могут выполняться только на одном конкретном ядре, вызывали ненужные помехи. Службы с интенсивным использованием сети тратили столько времени на обработку прерываний, что учет справедливости планировщика нарушался.
Эти проблемы потребовали изменений в том, как LAVD обрабатывает очереди задач, временные интервалы и учет ЦП. В ряде случаев Meta добавила логику для улучшения сохранения локальности кэша или для компенсации перегруженных сетевыми прерываниями ядер, фактически рассматривая их как “более медленные” ЦП. Важно отметить, что эти исправления не требовали настройки для каждой службы или ручной расстановки приоритетов. В этом и заключается основная привлекательность LAVD для Meta: он адаптируется на основе наблюдаемого поведения, а не жестко запрограммированных правил.
Инженеры также затронули очевидный вопрос: не повредит ли оптимизация планировщика для серверов Meta его первоначальному игровому варианту использования? По их словам, на данный момент изменения либо нейтральны, либо полезны для Steam Deck, а функции, которые не применимы, можно просто отключить с помощью флагов ядра. Тем не менее, они признали, что эксперимент продолжается.
Поскольку Linux становится общей основой для всего, от портативных консолей до гипермасштабируемых серверов, инновации в одном углу экосистемы все чаще перетекают в другие. В данном случае та же логика планирования, которая помогает игровому ПК за 400 долларов работать быстро, может также помочь вовремя перемещать миллиарды сообщений. Это прекрасная демонстрация силы программного обеспечения с открытым исходным кодом и убедительный аргумент в пользу того, как прилив поднимает все лодки.
(*) Имейте ввиду, редакции некоторых западных изданий придерживаются предвзятых взглядов в освящении некоторых новостей, связанных с Россией.
8/9
Автор – Zak Killian
