Недавно столкнулся с парадоксом: новые ноды с топовыми процессорами работали медленнее старых. Latency прыгал, поды реагировали с задержками, а CPU вроде бы простаивал. Виновник оказался неожиданным - энергосберегающие режимы процессора (C-states). Расскажу, как мы это выяснили и починили.

Что такое C-states?

C-states (CPU states) - это режимы энергосбережения процессора. Чем выше номер C-state, тем глубже “сон” процессора:

  • C0 - активная работа
  • C1 - легкий сон (clock gating)
  • C2 - глубже, отключаются части кэша
  • C3 - еще глубже, flush L3 кэша
  • C6/C7 - почти полное отключение ядра

Проблема: выход из глубокого сна занимает время. Для C6 это может быть 100+ микросекунд.

Симптомы проблемы

1. Нестабильный latency

# Пинг между подами
64 bytes: time=0.180 ms
64 bytes: time=2.451 ms  # WTF?
64 bytes: time=0.156 ms
64 bytes: time=1.893 ms

2. Скачущее время ответа API

p50: 15ms
p95: 45ms
p99: 180ms  # Слишком большой разброс

3. CPU простаивает, но приложение тормозит

kubectl top nodes
# CPU: 30%
# Но приложения жалуются на производительность

Диагностика

1. Проверяем текущие C-states

# Смотрим доступные состояния
cat /sys/devices/system/cpu/cpu0/cpuidle/state*/name
POLL
C1
C1E
C6

# Проверяем время в каждом состоянии
grep . /sys/devices/system/cpu/cpu0/cpuidle/state*/time

2. Мониторим переходы в реальном времени

# turbostat показывает статистику C-states
turbostat --interval 1
Core CPU Avg_MHz Busy% C1%   C6%   
-    -   800     20.5  15.2  64.3  # 64% времени в C6!

3. Проверяем latency пробуждения

# Смотрим задержки для каждого состояния
grep . /sys/devices/system/cpu/cpu0/cpuidle/state*/latency
state0/latency:0      # POLL
state1/latency:2      # C1
state2/latency:10     # C1E
state3/latency:133    # C6 - вот наша проблема

Решения

Вариант 1: Отключить C-states через kernel параметры

# /etc/default/grub
GRUB_CMDLINE_LINUX="intel_idle.max_cstate=1 processor.max_cstate=1"

# Применяем
sudo update-grub
sudo reboot

Вариант 2: Настройка через BIOS

  • Отключить C-states
  • Отключить Intel SpeedStep
  • Включить Performance mode

Вариант 3: Динамическое управление (рекомендую)

# Скрипт для критичных нод
#!/bin/bash
# disable-cstates.sh

# Отключаем C-states глубже C1
for cpu in /sys/devices/system/cpu/cpu*/cpuidle/state*/disable; do
    state=$(echo $cpu | grep -o 'state[0-9]')
    if [[ $state > "state1" ]]; then
        echo 1 > $cpu
    fi
done

# Устанавливаем performance governor
for gov in /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor; do
    echo performance > $gov
done

Вариант 4: CPU pinning для критичных подов

apiVersion: v1
kind: Pod
metadata:
  name: latency-sensitive-app
spec:
  containers:
  - name: app
    resources:
      requests:
        cpu: "4"
        memory: "8Gi"
      limits:
        cpu: "4"
        memory: "8Gi"
    # Привязка к конкретным CPU
    nodeSelector:
      node-role.kubernetes.io/compute: "true"

Результаты

До оптимизации:

  • p99 latency: 180ms
  • Разброс ping: 0.15-2.5ms
  • CPU C6 time: 60%+

После отключения глубоких C-states:

  • p99 latency: 35ms (-80%!)
  • Разброс ping: 0.15-0.25ms
  • CPU C6 time: 0%
  • Потребление энергии: +15-20%

Best Practices

1. Разделяйте ноды по типам нагрузки

# Latency-sensitive ноды (C-states отключены)
kubectl label nodes worker-1 workload-type=latency-sensitive

# Batch processing ноды (C-states включены)
kubectl label nodes worker-2 workload-type=batch

2. Используйте Node Affinity

affinity:
  nodeAffinity:
    requiredDuringSchedulingIgnoredDuringExecution:
      nodeSelectorTerms:
      - matchExpressions:
        - key: workload-type
          operator: In
          values:
          - latency-sensitive

3. Мониторинг C-states

# Prometheus экспортер для C-states
apiVersion: v1
kind: ConfigMap
metadata:
  name: node-exporter-config
data:
  config: |
    --collector.cpu_info
    --collector.cpufreq

Когда НЕ отключать C-states

  1. Dev/Test окружения - экономия энергии важнее
  2. Batch jobs - им все равно на latency
  3. Idle ноды - пусть спят

Автоматизация

DaemonSet для управления C-states:

apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: cpu-performance-tuner
spec:
  selector:
    matchLabels:
      name: cpu-performance-tuner
  template:
    spec:
      hostPID: true
      containers:
      - name: tuner
        image: alpine
        securityContext:
          privileged: true
        command: ["/bin/sh", "-c"]
        args:
        - |
          # Отключаем C-states для production нод
          if [[ "$NODE_ROLE" == "production" ]]; then
            for state in /sys/devices/system/cpu/cpu*/cpuidle/state[2-9]/disable; do
              echo 1 > $state 2>/dev/null || true
            done
          fi
          sleep infinity

Итоги

C-states - это компромисс между энергоэффективностью и производительностью. Для latency-critical приложений в Kubernetes:

  1. Измерьте baseline с включенными C-states
  2. Тестируйте с отключенными глубокими состояниями
  3. Найдите баланс для вашей нагрузки
  4. Автоматизируйте настройку через DaemonSet

Не забывайте: это не серебряная пуля. Но если видите нестабильный latency на современном железе - проверьте C-states первым делом.

P.S. Аналогичные проблемы могут быть с P-states (частота процессора) и с NUMA. Но это уже другая история…