CPU-Limits убивают производительность: пора переосмыслить управление ресурсами

Основная информация

• ID статьи: 2510.10747
• Название: CPU-Limits kill Performance: Time to rethink Resource Control
• Авторы: Chirag Shetty (UIUC), Sarthak Chakraborty (UIUC), Hubertus Franke (IBM Research), Larisa Shwartz (IBM Research), Chandra Narayanaswami (IBM Research), Indranil Gupta (UIUC), Saurabh Jha (IBM Research)
• Классификация: cs.DC (распределённые вычисления), cs.OS (операционные системы), cs.PF (производительность)
• Дата публикации: октябрь 2025 г. (препринт arXiv)
• Ссылка на статью: https://arxiv.org/abs/2510.10747

Аннотация

В данной работе авторы ставят под сомнение фундаментальный механизм управления вычислительными ресурсами в облачных приложениях — ограничения CPU (CPU-Limits). Несмотря на то, что как академические исследования, так и промышленная практика считают CPU-Limits необходимыми, авторы предоставляют эмпирические доказательства того, что CPU-Limits фактически снижают производительность приложений и увеличивают затраты. В работе утверждается, что приложения, чувствительные к задержкам, должны полностью отказаться от CPU-Limits, что требует фундаментального переосмысления автомасштабирования и моделей выставления счётов, при этом указывая на обоснованное применение CPU-Limits в специфических сценариях (таких как фоновые задачи).

Предпосылки и мотивация исследования

Определение проблемы

Управление ресурсами CPU для контейнеризированных микросервисов является центральной проблемой облачных вычислений. Текущий основной подход заключается в строгом ограничении использования CPU контейнерами через механизм CPU-Limits (c.limit), реализованный на основе Linux cpu.cfs_quota_us. Однако авторы наблюдают значительный разрыв между теорией и практикой в реальных развёртываниях.

Значимость проблемы

1. Влияние на производительность: Дросселирование, вызванное CPU-Limits, приводит к резкому ухудшению задержки приложений и может вызвать каскадные отказы
2. Проблемы затрат: Коэффициенты безопасности, установленные для избежания дросселирования, приводят к избыточной конфигурации ресурсов на 25-45%
3. Сложность операций: Инженеры DevOps должны выполнять сложные компромиссы между множеством детальных ограничений CPU

Ограничения существующих подходов

Существующие исследования автомасштабирования (такие как FIRM, Cilantro, Autothrottle и др.) основаны на предположении о необходимости CPU-Limits и сосредоточены на оптимизации значений ограничений, а не на критике самого механизма. Авторы обнаружили, что все эти подходы становятся неэффективными при удалении CPU-Limits.

Мотивация исследования

Через интервью с инженерами надёжности сайтов (SRE) и анализ онлайн-дискуссий авторы обнаружили разногласия в операционном сообществе относительно CPU-Limits. Многие практики уже начали удалять CPU-Limits для улучшения производительности, что контрастирует с основным мнением академического сообщества.

Основные вклады

1. Оспаривание традиционных взглядов: Первое систематическое оспаривание необходимости CPU-Limits для приложений, чувствительных к задержкам, с достаточными эмпирическими доказательствами
2. Анализ производительности: Глубокий анализ механизмов негативного влияния CPU-Limits на задержку, надёжность и затраты
3. Проектирование альтернативных решений: Доказательство целесообразности и преимуществ управления ресурсами с использованием только CPU-Requests (c.req)
4. Предложение новой парадигмы: Введение моделей выставления счётов на основе производительности и проектирования неограниченного автомасштабирования
5. Реализация прототипа: Разработка прототипа YAAS (Yet Another AutoScaler), обеспечивающего экономию ресурсов на 51%
6. Классификация сценариев применения: Чёткое определение обоснованных сценариев использования CPU-Limits (таких как фоновые задачи, CPU-bound приложения)

Подробное описание методологии

Определение задачи

Целью исследования является переработка механизма управления ресурсами CPU для контейнеров, достижение лучшего компромисса между производительностью и затратами путём оптимизации CPU-Requests и использования узлов без применения CPU-Limits.

Основная структура аргументации

Авторы разработали дерево решений (рисунок 1) для систематического анализа различных сценариев конфигурации CPU-Limits:

1. limit = req: Приводит к увеличению затрат, требует коэффициента безопасности 25-45%
2. limit > req:
   • Если ограничение никогда не достигается, оно не требуется
   • Если ограничение может быть достигнуто, это приводит к "зависанию" автомасштабирования или резкому ухудшению задержки

Доказательство достаточности CPU-Requests

Авторы доказывают достаточность использования только CPU-Requests на двух уровнях:

Гарантии планировщика CFS: Планировщик Linux CFS обеспечивает гарантии пропорциональной справедливости, гарантируя, что Pod P_i с CPU-Requests r_i на узле с общим CPU C получит минимум (r_i/Σr_j) × C времени CPU.

Контроль оркестратора: Оркестраторы, такие как Kubernetes, гарантируют, что сумма CPU-Requests всех контейнеров на узле не превышает ёмкость узла, делая CPU-Requests абсолютной минимальной гарантией.

Проектирование прототипа YAAS

YAAS основан на двух ключевых управляющих переменных:

1. Overage (U-R): Разница между фактическим использованием Pod и выделенным количеством
2. Использование узла (N): Общее использование CPU на узле, где находится Pod

Основная стратегия:

• Поддержание overage ≥ 0, увеличение ресурсов только при угрозе нарушения SLO
• Оптимизация использования узла через миграцию Pod
• Комбинирование вертикального и горизонтального масштабирования

Экспериментальная установка

Набор данных

Использованы два микросервисных приложения из DeathStarBench:

• HotelReservation (HR): Система бронирования отелей
• SocialNetwork (SN): Приложение социальной сети

Экспериментальная среда

• Платформа: Кластер Amazon EC2
• Модели нагрузки: Переменная нагрузка запросов, моделирующая реальную производственную среду
• Метрики оценки:
  • Сквозная задержка хвоста (P99)
  • Использование ресурсов CPU
  • Количество и время сходимости масштабирования
  • Эффективность затрат

Методы сравнения

• Традиционный HPA (Horizontal Pod Autoscaler) на основе CPU-Limits
• Вручную оптимизированная конфигурация CPU-Limits
• Различные настройки коэффициента безопасности (20%-30%)

Результаты экспериментов

Основные результаты

Влияние на задержку:

• Установка CPU-Limits только на одном Pod (из 19) приводит к ухудшению сквозной задержки хвоста в 5 раз
• CPU-Limits повреждают производительность двумя механизмами: дросселирование отдельных запросов и формирование очередей между запросами

Анализ затрат:

• Избежание дросселирования требует избыточной конфигурации ресурсов на 25-45%
• Простое удаление CPU-Limits экономит 38% ресурсов
• YAAS дополнительно обеспечивает экономию ресурсов на 51%

Производительность масштабирования:

• При увеличении нагрузки на 25% повышение порога масштабирования с 60% до 70% увеличивает время выполнения SLO в 4 раза
• Демонстрирует влияние CPU-Limits на чувствительность автомасштабирования

Абляционные эксперименты

Анализ коэффициента безопасности: Различные приложения требуют разных коэффициентов безопасности:

• nginx-thrift: 30%
• user-timeline-service: 45%

Механизм формирования очередей: Теоретический анализ и экспериментальная проверка показывают, как CPU-Limits формируют очереди при низкой нагрузке, в то время как CPU-Requests не создают эту проблему.

Анализ конкретных случаев

Многотенантные сценарии: Эксперименты показывают, что при совместном размещении двух приложений CPU-Requests эффективно защищают соответствующие приложения от влияния приложений с всплесками, в то время как CPU-Limits наоборот ухудшают производительность.

Каскадные отказы: Длинные очереди, вызванные CPU-Limits, могут привести к превышению памяти Pod, вызвав перезагрузку Pod, что в свою очередь может привести к достижению других Pod ограничений или истечению времени ожидания запросов.

Связанные работы

Исследования автомасштабирования

Авторы систематически анализируют работы по автомасштабированию из недавних топовых конференций и обнаруживают, что все они зависят от CPU-Limits:

• FIRM: Использует обучение с подкреплением для оптимизации CPU-Limits
• Cilantro: Основан на онлайн-обратной связи для корректировки распределения ресурсов
• Autothrottle: Двухуровневый подход для обработки целей SLO
• Ursa: Управление ресурсами, управляемое анализом

Промышленная практика

• Классификация QoS Kubernetes требует установки CPU-Limits для критических контейнеров
• Облачные провайдеры (такие как GCP Autopilot) автоматически применяют CPU-Limits
• Лучшие практики многотенантности рекомендуют использование CPU-Limits

Выводы и обсуждение

Основные выводы

1. CPU-Limits вредны: Для приложений, чувствительных к задержкам, CPU-Limits либо вредны (вызывают дросселирование), либо бесполезны (никогда не достигаются)
2. CPU-Requests достаточны: Гарантии современных оркестраторов и планировщиков делают CPU-Requests достаточными для обеспечения изоляции ресурсов
3. Новое пространство проектирования: Удаление CPU-Limits открывает новые возможности оптимизации на основе overage и использования узлов
4. Необходимость смены парадигмы: Требуется переработка автомасштабирования и моделей выставления счётов

Ограничения

1. Область применения: Главным образом ориентирована на приложения, чувствительные к задержкам; фоновые задачи и другие сценарии по-прежнему требуют CPU-Limits
2. Масштаб экспериментов: Эксперименты основаны на конкретных микросервисных бенчмарках, требуется проверка в большем масштабе
3. Развёртывание в производстве: Прототип YAAS требует дополнительной инженерной работы для использования в производстве
4. Экосистема: Требуется согласованное изменение оркестраторов, систем мониторинга и выставления счётов

Направления будущих исследований

1. Интеллектуальное планирование: Планирование, осведомлённое о помехах, с учётом микроархитектурных ресурсов (кэш, полоса пропускания памяти)
2. Выставление счётов на основе производительности: Модели выставления счётов на основе выполнения SLO, а не использования ресурсов
3. Вертикальное масштабирование: Оптимизация вертикального масштабирования в среде без CPU-Limits
4. Многомерная оптимизация: Совместная оптимизация масштабирования Pod и масштабирования узлов

Глубокая оценка

Преимущества

1. Революционная точка зрения: Смелое оспаривание фундаментальных предположений в области, имеющее важное академическое значение
2. Достаточные эмпирические доказательства: Многомерная поддержка точки зрения через теоретический анализ, экспериментальную проверку и промышленные исследования
3. Практическая ценность: Предоставляет конкретные альтернативные решения и реализацию прототипа с прямым применением
4. Систематический анализ: Всесторонний анализ проблемы с точек зрения производительности, затрат и надёжности
5. Сбалансированная точка зрения: Критикует неправильное использование CPU-Limits, но указывает на обоснованные сценарии их применения

Недостатки

1. Ограничения экспериментов: Эксперименты в основном основаны на двух микросервисных приложениях, требуется проверка на более широком спектре типов приложений
2. Проверка в производстве: Отсутствуют данные долгосрочной проверки в крупномасштабной производственной среде
3. Анализ совместимости: Недостаточный анализ затрат на модификацию существующих систем и инструментов
4. Рассмотрение безопасности: Недостаточно глубокое обсуждение потенциальных рисков безопасности при удалении CPU-Limits

Влияние

Академическое влияние:

• Может вызвать смену парадигмы в области управления ресурсами
• Предоставляет новые направления проектирования для исследований автомасштабирования
• Оспаривает лучшие практики, установленные более десяти лет назад

Промышленное влияние:

• Предоставляет облачным провайдерам новые пути оптимизации затрат
• Может повлиять на будущее проектирование оркестраторов, таких как Kubernetes
• Стимулирует инновации в моделях выставления счётов на основе производительности

Применимые сценарии

Прямое применение:

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

Требующие осторожности:

• Многотенантные среды (требуют дополнительных механизмов изоляции)
• Смешанные рабочие нагрузки, содержащие фоновые задачи
• Сценарии со строгими требованиями соответствия использованию ресурсов

Библиография

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

• Официальную документацию Kubernetes и лучшие практики
• Недавние исследования автомасштабирования из топовых конференций (OSDI, NSDI, EuroSys и др.)
• Документацию ядра Linux по планированию CPU и контрольным группам
• Практический опыт и тематические исследования из промышленности

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