Когда Meta начала искать лучший планировщик ЦП для Linux для своего огромного парка серверов, это началось не в центре обработки данных. Отправной точкой стал портативный игровой ПК. В недавнем техническом докладе на конференции Linux Plumbers’ Conference в Токио инженеры Meta подробно рассказали, как они реализуют SCX-LAVD, планировщик Linux с малой задержкой, первоначально разработанный Valve для Steam Deck, в промышленных серверных средах с системами обмена сообщениями, службами кэширования и другими критически важными компонентами инфраструктуры. Неожиданный вывод: планировщик, созданный для обеспечения плавной работы игр под нагрузкой, оказался хорошо подходящим для крупных дата-центров.
На базовом уровне планировщик процессора определяет, какие программы выполняются, на каких ядрах процессора и в какое время. Стандартный планировщик Linux должен работать везде — на телефонах, ноутбуках, настольных компьютерах и серверах, что делает его чрезвычайно осторожным и универсальным. Мета-задача принципиально отличается. Компания управляет сверхмощными машинами с сотнями процессорных ядер, очень разнообразными рабочими нагрузками и, что самое главное, строгими требованиями к задержке. В такой среде подход «достаточно хорош для всего» часто оказывается недостаточным. Вместо создания отдельного планировщика для каждого сервиса компания Meta хотела получить что-то близкое к стандартному решению для всего парка серверов, обычному «универсальному» решению, которое могло бы автоматически адаптироваться без ручной настройки. Именно здесь появился SCX-LAVD.
SCX-LAVD построен на основе sched_ext, относительно новой платформы Linux, которая позволяет подключать к ядру альтернативные планировщики без существенного изменения самого ядра. В своей простейшей форме sched_ext позволяет компаниям экспериментировать с различными стратегиями планирования без необходимости создавать собственные вилки Linux или поддерживать большие наборы исправлений. Аббревиатура LAVD означает виртуальный дедлайн с учетом задержки. Название достаточно точно описывает принцип работы. Вместо использования статических приоритетов или ручных подсказок планировщик постоянно отслеживает поведение задач, как часто они уходят в сон, просыпаются или блокируются, и на основе этого оценивает, какие задачи чувствительны к задержкам. Таким задачам раньше назначаются «виртуальные сроки», что увеличивает вероятность их быстрого выполнения в условиях высокой загруженности.
Изначально такой подход был продиктован потребностями игровых сценариев. В Steam Deck пропущенные сроки планирования приводят к потере кадров, зависаниям или медленному отклику на ввод. В центрах обработки данных аналогичные проблемы проявляются в виде медленных веб-запросов, задержек в доставке сообщений или нарушений целевых показателей уровня обслуживания. Приложения разные, но основная проблема одна.
В своем отчете инженеры Meta описали ряд проблем, с которыми они столкнулись при масштабировании LAVD на серверное оборудование. В системах с десятками ядер, разделяющих одну очередь планирования, конкуренция за ресурсы становится узким местом. Фиксированные задачи, то есть потоки, которые могут выполняться только на одном конкретном ядре, создавали ненужные препятствия для других процессов. Сервисы с интенсивной сетевой активностью тратили столько времени на обработку прерываний, что механизмы учета справедливости планировщика начали работать некорректно.
Эти проблемы вызвали изменения в подходах LAVD к управлению очередями задач, временными интервалами и учетом использования процессора. В некоторых случаях Meta добавляла логику, чтобы лучше сохранять локальность кэша или компенсировать перегрузку ядер сетевыми прерываниями, эффективно рассматривая их как «более медленные» процессоры. Важно отметить, что эти изменения не требовали настройки для каждой отдельной службы или определения приоритетов вручную. В этом ключевая привлекательность LAVD для Meta – адаптация основана на наблюдаемом поведении, а не на жестко запрограммированных правилах.
Отдельно инженеры обратились к очевидному вопросу: не повредит ли оптимизация планировщика для мета-серверов его первоначальному варианту использования в игре. По их словам, на текущем этапе изменения нейтральны или даже полезны для Steam Deck, а функции, не имеющие отношения к игровой среде, можно просто отключить с помощью опций ядра. При этом они признали, что эксперимент продолжается и окончательные выводы еще впереди.
