Модуль 5.2: Планування CPU

Продуктивність Linux | Складність: [MEDIUM] | Час: 30–35 хв

Передумови

Перед початком цього модуля:

Обов’язково: Модуль 5.1: Метод USE
Обов’язково: Модуль 2.2: Контрольні групи (cgroups)
Бажано: Розуміння понять процесів та потоків (threads).

Що ви зможете робити після цього модуля

Після завершення цього модуля ви зможете:

Пояснити, як працює планувальник CPU в Linux (CFS, nice values, CPU affinity)
Діагностувати конкуренцію за CPU за допомогою mpstat, pidstat та perf
Налаштувати CPU pinning та ліміти CPU cgroup для навантажень, чутливих до продуктивності
Оцінити, чи навантаження обмежене CPU, I/O чи пам’яттю

Чому цей модуль важливий

Коли ваш под у Kubernetes “гальмує” (throttled) або застосунки працюють повільно попри наявність вільних ресурсів — у справу вступає планувальник (scheduler). Розуміння того, як Linux розподіляє час процесора, пояснює, чому ліміти CPU в Kubernetes працюють саме так.

Розуміння планування CPU допоможе вам:

Вирішувати проблеми з CPU throttling — чому под повільний при низькому завантаженні?
Правильно встановлювати ліміти — різниця між requests та limits.
Аналізувати продуктивність — чому load average та %CPU кажуть про різне.
Оптимізувати навантаження — підбирати розміри контейнерів на основі їх реальної поведінки.

Розуміння Load Average

Load average — це кількість процесів, які хочуть працювати (чекають на CPU) або чекають на ввід/вивід (I/O).

┌─────────────────────────────────────────────────────────────┐
│                    LOAD AVERAGE                             │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│  4-ядерна система, load average = 4.0:                      │
│  ┌─────┐ ┌─────┐ ┌─────┐ ┌─────┐                            │
│  │ П1  │ │ П2  │ │ П3  │ │ П4  │  ← 4 процеси працюють      │
│  │CPU 0│ │CPU 1│ │CPU 2│ │CPU 3│                            │
│  └─────┘ └─────┘ └─────┘ └─────┘                            │
│  Load = 4.0 = Ідеальна утилізація                           │
│                                                             │
│  4-ядерна система, load average = 8.0:                      │
│  ┌─────┐ ┌─────┐ ┌─────┐ ┌─────┐                            │
│  │ П1  │ │ П2  │ │ П3  │ │ П4  │  ← 4 працюють              │
│  │CPU 0│ │CPU 1│ │CPU 2│ │CPU 3│                            │
│  └─────┘ └─────┘ └─────┘ └─────┘                            │
│                                                             │
│  Черга: [П5] [П6] [П7] [П8]      ← 4 чекають                │
│                                                             │
│  Load = 8.0 = 100% завантаження + 100% черга                │
│                                                             │
└─────────────────────────────────────────────────────────────┘

Як Kubernetes транслює CPU в Linux

Kubernetes використовує абстракцію “міліядра” (millicores), але Linux про них нічого не знає. K8s перетворює ваші налаштування в параметри cgroups:

Kubernetes	Linux cgroups	Механізм
`cpu: "100m"` (request)	`cpu.shares = 102`	Відносна вага (пріоритет)
`cpu: "500m"` (limit)	`cpu.cfs_quota_us = 50000`	Жорстке обмеження часу

Shares (requests):

Гарантований мінімум під час конкуренції.
Якщо CPU вільний, под може використовувати хоч 100%, навіть якщо реквест малий.

Quotas (limits):

Жорстка “стеля”.
Навіть якщо CPU вільний на 90%, под із лімітом 500m не отримає більше 50% часу одного ядра.
Це викликає throttling (гальмування).

CPU Throttling та затримки (Latency)

Гальмування відбувається періодами (за замовчуванням 100мс). Якщо под вичерпав свою квоту в 50мс за перші 10мс періоду — він чекатиме наступні 90мс. Це створює різкі стрибки затримок (latency spikes).

# Перевірити гальмування контейнера в cgroups
cat /sys/fs/cgroup/cpu/cpu.stat
# nr_periods   - загальна кількість періодів
# nr_throttled - скільки разів було застосовано обмеження

Тест

Що входить у показник Load Average в Linux?

Відповідь
Процеси, що виконуються на CPU, процеси, що чекають своєї черги на CPU (runnable), та процеси, що чекають на завершення операцій вводу/виводу (I/O wait).
Яка різниця між CPU requests та CPU limits у Kubernetes?

Відповідь
Requests — це гарантована частка ресурсів під час високого навантаження на вузол (через `cpu.shares`). Limits — це жорстке обмеження, яке ніколи не дозволяє поду споживати більше вказаного, навіть якщо процесор вільний (через `cpu.cfs_quota_us`).
Чому низький % CPU може супроводжуватися високими затримками (latency)?

Відповідь
Через CPU throttling. Якщо ліміт дуже низький, додаток може швидко вичерпати свою мікро-квоту всередині 100-мілісекундного вікна і стати на паузу, чекаючи наступного вікна.
Яка команда показує кількість ядер CPU в системі?

Відповідь
`nproc` або `lscpu`.

Практична вправа

Завдання: Дослідити пріоритети та навантаження CPU.

Запустіть два ідентичні процеси з різними пріоритетами (nice):
Terminal window
```
nice -n 19 sha256sum /dev/zero &
nice -n 0 sha256sum /dev/zero &
```
Подивіться на розподіл CPU в top (колонка %CPU та NI):
Terminal window
```
top -bn1 | grep sha256sum
```
Перевірте кількість перемикань контексту (context switches):
Terminal window
```
vmstat 1 3  # Дивіться на колонку 'cs'
```
Вбийте процеси:
Terminal window
```
killall sha256sum
```

Критерії успіху: Ви бачите, як пріоритет (nice) впливає на частку часу, яку отримує процес від планувальника.

Підсумок

Load average показує загальну насиченість (CPU + I/O).
CFS намагається бути чесним з усіма процесами.
Requests — це пріоритет, Limits — це жорстка межа.
Throttling — головний ворог стабільної затримки (p99 latency).

Далі: Модуль 5.3: Керування пам’яттю — дізнайтеся, як Linux працює з RAM і чому ліміти пам’яті в Kubernetes набагато небезпечніші за ліміти CPU.