Ефективність: чому швидше не завжди краще

Швидкість проти ефективності: різниця, що платить за ваші рахунки

«Швидше» — це вимір: нижча затримка, вища пропускна спроможність, більше запитів на секунду. «Ефективно» — це відношення: скільки цінності ви отримуєте за одиницю витрат,
ризику та операційних зусиль. Якщо швидкість — спортивний автомобіль, ефективність — нудна машина, яку реально обслуговувати, страхувати й паркувати.

У продакшн-системах рідко потрібна максимальна швидкість. Потрібна достатня швидкість з передбачуваною поведінкою.
Шлях до «швидше» часто лежить прямо через:

• Більшу варіативність (хвостова затримка погіршується)
• Змагання за ресурси (шумний сусід всередині вашої ж машини)
• Приховані залежності (оптимізація залежить від умов, які ви не гарантуєте)
• Крихкість (маленька зміна ламає велику припущену умову)

Ефективні системи проектують навколо обмежень: CPU, пропускної здатності пам’яті, затримки вводу/виводу, джитеру мережі, локальності кешу, чергування і людей.
Люди — це реальне обмеження. Ваш інженер на виклику — не відновлювальний ресурс.

Ефективність — це тричастинний контракт

1. Продуктивність: виконувати SLO у штатному режимі й під навантаженням, з прийнятною хвостовою затримкою.
2. Вартість: тримати економіку одиниці роботи в розумних межах (вартість на запит, на ГБ зберігання, на згенерований звіт).
3. Операбельність: зміни тестовані, спостережувані та відкатувані о 02:13.

Ось неприємна правда: більшість «проектів на швидкість» насправді — це проекти стресу. Ви підвищуєте завантаження, щоб вичавити більше виходу,
а потім дивуєтесь, коли теорія черг приходить як незваний гість.

Цитата, бо в ній вся робота в одному реченні. Вернер Фогельс (CTO Amazon) сформулював просто:
Усе ламається, постійно.

Якщо ваша оптимізація припускає, що все працює — це не оптимізація. Це майбутній інцидент.

Факти та історія: як ми вчились «на власних помилках»

Дебати про ефективність не нові. Вони виникають щоразу, коли ми робимо компонент швидшим і виявляємо, що просто перемістили вузьке місце кудись гірше.
Кілька конкретних фактів і історичних моментів, що важливі для сучасних систем:

1. Закон Амдала (1967): прискорення однієї частини системи має спадну віддачу, якщо решта залишається без змін.
   На практиці саме тому «2× швидше сховище» рідко робить «2× швидше сервіс».
2. Закон Літтла (теорія черг): середня кількість у системі = швидкість надходження × час у системі.
   Ви не можете «оптимізувати черги в нуль»; можете лише керувати швидкістю надходження, часом обслуговування або конкуренцією.
3. Скільки не росте частота CPU (середина 2000-х): через щільність потужності та тепло.
   Тому ми отримали більше ядер, а не нескінченно швидкі одиночні ядра — і тому паралелізм став обов’язковим і болючим.
4. «Стіна пам’яті»: швидкість CPU зростала швидше за затримку пам’яті десятиліттями.
   Сучасна продуктивність часто залежить від того, наскільки добре ви використовуєте кеші, а не від кількості GHz.
5. Нарахунок штрафу запису в RAID став класичною пасткою: більше дисків може дати більше пропускної здатності, але паритетні записи можуть примножувати IO і затримку.
6. Еволюція управління заторами в TCP: ми зрозуміли, що «шліть швидше» руйнує спільні мережі.
   Системи, що ігнорують конґестію, створюють самоіндуковані відмови.
7. Хвостова затримка стала проблемою першого класу у великих розподілених системах: p99 визначає користувацький досвід, а повтори підсилюють навантаження.
   Середня затримка — брехун з гарною поставою.
8. Впровадження SSD змінило моделі відмов: менше механічних збоїв, більше проблем з прошивкою, write amplification і раптові падіння продуктивності під тривалими записами.

Коли «швидше» робить гірше

«Швидше» може бути пасткою, бо підштовхує вас оптимізувати найлегше вимірюване, а не те, що обмежує бізнес-результат.
Кілька поширених способів, як швидкість стає анти-ефективністю:

1) Ви оптимізуєте пропускну спроможність і руйнуєте хвостову затримку

Багато виграшів у продуктивності — це «пакуйте більше», «чергуйте більше», «паралелізуйте більше». Чудово для пропускної спроможності. Не завжди — для часу відповіді.
Коли завантаження наближається до насичення, хвостова затримка зростає нелінійно. Медіана може залишатися спокійною. Ваш p99 перетворюється на фільм жахів.

2) Ви зменшуєте латентність, підвищуючи варіативність

Агресивне кешування, спекулятивні обчислення та асинхронні конвеєри можуть зменшити типовий час відповіді, одночасно збільшуючи крайні випадки.
Це прийнятно, якщо ваш SLO орієнтований на медіану. Більшість — ні. Користувачі не скаржаться на p50. Вони скаржаться: «іноді зависає».

3) Ви купуєте швидкість ціною складності

Складність — це відсоток відсотків, який ви платите за кожну майбутню зміну. Швидша система, що потребує трьох племінних експертів і повного місячного циклу для деплою,
не «краща». Це інструмент боргу надійності.

4) Ви створюєте ампліфікацію навантаження

Найлегша помилка з продуктивністю для пропуску — це ампліфікація:

• Підсилення читань: один запит викликає багато бекенд-читань.
• Підсилення записів: один запис стає багатьма записами (журнали, WAL, паритет, реплікація).
• Підсилення повторів: повільні відповіді призводять до повторів, що створюють більше навантаження й ще більшу повільність.

Жарт №1: Повторювати повільний запит без backoff — це як сигналити в заторі, щоб машини зникли. Задовольняє, але абсолютно неефективно.

5) Ви оптимізуєте неправильний рівень

Інженери зі зберігання бачать це постійно: команда додатку каже «нам потрібні швидші диски», а їхній сервіс фактично обмежений CPU при парсингу JSON,
або заблокований на DNS, або серіалізований на локальному замку. Диск невинний. Дашборди — ні.

Метрики, що справді важливі (і ті, що брешуть)

Ефективність можна виміряти, якщо припинити поклонятися одним лише числам. Правильні метрики відповідають на питання: «Що нас обмежує, скільки це коштує і наскільки це передбачувано?»

Користуйтесь цими

• p95/p99/p999 затримка по ендпоінту та по залежності (DB, cache, object store).
• Глибина черги (диск, NIC, пул потоків у додатку).
• Завантаження з сигналами насичення: CPU з run queue, IO з await, мережа з retransmits.
• Рівень помилок і рівень повторів (повтори — латентні помилки).
• Вартість за одиницю: вартість на запит, на GB-місяць, на запуск джоба.
• Рівень невдалих змін: оптимізація, що ламає деплої, — це не перемога.

Недовіряйте цим (якщо немає контексту)

• Середня затримка без перцентилів.
• Відсоток CPU без run queue і steal time.
• «% використання диска» окремо; потрібні latency/await і queue depth.
• Пропускна здатність мережі без втрат пакетів і retransmits.
• Хітрейт кешу без показників викидення і хвостової поведінки.

Табло ефективності

Якщо хочете одну сторінку для керівництва без брехні, відстежуйте:

• Виконання SLO (включно з хвостовою затримкою)
• Вартість за транзакцію (або за активного користувача, за звіт, за запуск пайплайна)
• Інциденти, що спричинені змінами продуктивності/масштабування
• Середній час виявлення вузького місця (MTTDB), бо ваш час важливий

План швидкої діагностики: знайти вузьке місце за хвилини

Мета — не «збирати всі метрики». Мета — швидко знайти обмежувальний ресурс, аби не починати випадкове налаштування.
Випадкове налаштування породжує фольклор.

Перше: підтвердіть симптом і область

1. Який перцентиль падає? p95 проти p99 — має значення.
2. Які ендпоінти? весь трафік чи один маршрут.
3. Які хости/поди? один шард чи системна проблема.
4. Що змінилося? деплой, конфіг, форма трафіку, поведінка залежності.

Друге: оберіть ймовірний клас вузького місця

Вирішіть, який із цих варіантів найбільш правдоподібний на основі графіків і режимів помилок:

• Насичення CPU: високий run queue, троттлінг, довгі GC, contention на замках.
• Тиск пам’яті: сторінкування, великі faults, thrash кешу, OOM kills.
• Затримка зберігання: високий await, queue depth, проблеми планувальника IO, помилки пристрою.
• Мережеві проблеми: retransmits, затримка DNS, втрата пакетів, SYN backlog.
• Зовнішня залежність: повільні запити DB, cache stampede, таймаути третьої сторони.

Третє: підтвердіть на одному хості і однією командою по шару

Не розпорошуйтеся. Візьміть найгірше уражений хост і запустіть вузький набір перевірок. Якщо сигнал слабкий — розширюйте.
Ваше завдання — змусити вузьке місце «здатися».

Четверте: вирішіть — пом’якшити зараз чи виправити

• Пом’якшити зараз: знизити навантаження, обмежити конкуренцію, обережно збільшити таймаути, відкотити, масштабуватися.
• Виправити потім: тонке налаштування, рефакторинг, перевиконання індексів, зміна архітектури, планування потужностей.

Практичні завдання: команди, вивід і рішення (12+)

Це реальні команди, які можна виконати на Linux-хостах (а також кілька для ZFS/Kubernetes, якщо вони у вас є).
Кожне завдання містить: команду, приклад виводу, що це означає і яке рішення приймається.

Завдання 1: Перевірити load і run queue (насичення CPU проти «завантажено, але нормально»)

cr0x@server:~$ uptime
 02:41:12 up 17 days,  6:03,  2 users,  load average: 18.92, 17.40, 12.11

Значення: Load average значно вище за кількість ядер часто сигналізує про насичення CPU або runnable треди, що застрягли на IO. Це метрика «хтось чекає».

Рішення: Якщо load високий — негайно перевірте run queue CPU і IO wait далі (не припускайте автоматично «потрібно більше CPU»).

Завдання 2: Подивитись CPU, iowait і steal (врахуйте віртуалізаційний податок)

cr0x@server:~$ mpstat -P ALL 1 3
Linux 6.5.0-18-generic (api-3)  01/12/2026  _x86_64_  (8 CPU)

02:41:22 PM  CPU   %usr  %nice   %sys %iowait  %irq  %soft  %steal  %idle
02:41:23 PM  all  72.11   0.00  12.44    9.83  0.00   0.62    3.90   1.10
02:41:23 PM    0  81.00   0.00  10.00    6.00  0.00   1.00    2.00   0.00

Значення: %iowait вказує на час CPU, що витрачається на очікування зберігання; %steal — на конкуренцію з гіпервізором.

Рішення: Високий iowait → йти шляхом зберігання. Високий steal → перемістити навантаження, змінити клас інстансу або зменшити чутливість до шумних сусідів.

Завдання 3: Виявити топ-споживачів CPU і чи це user time чи kernel time

cr0x@server:~$ top -b -n 1 | head -n 20
top - 14:41:28 up 17 days,  6:03,  1 user,  load average: 18.92, 17.40, 12.11
Tasks: 318 total,  12 running, 306 sleeping,   0 stopped,   0 zombie
%Cpu(s): 72.1 us, 12.4 sy,  0.0 ni,  1.1 id,  9.8 wa,  0.0 hi,  0.6 si,  3.9 st
MiB Mem :  32028.7 total,    614.2 free,  28970.1 used,   2444.4 buff/cache

  PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+ COMMAND
18231 app       20   0 2445684 812340  10920 R  386.7   2.5  19:33.11 api-server

Значення: Високий system time (%sy) може вказувати на роботу, що інтенсивно звертається до системних викликів: мережа, диск, перемикання контексту.

Рішення: Якщо один процес домінує — профілюйте його. Якщо домінує system time — перевірте мережу і IO перед «оптимізацією коду».

Завдання 4: Підтвердити тиск пам’яті (page faults, swap activity)

cr0x@server:~$ vmstat 1 5
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
12  2  524288  60212  10240 2011224   45   61   220  1350 8200 22000 66 14  2 12  6

Значення: Ненульові si/so вказують на свопінг. «b» заблоковані процеси і високий «r» в run queue показують contention.

Рішення: Якщо відбувається свопінг: зменшіть використання пам’яті, виправте витоки, налаштуйте кеші або додайте RAM. Не намагайтеся «оптимізувати IO», поки відбувається paging.

Завдання 5: Перевірити OOM kills і тиск memory cgroup (контейнери брешуть)

cr0x@server:~$ dmesg -T | tail -n 8
[Mon Jan 12 02:34:10 2026] Memory cgroup out of memory: Killed process 18231 (api-server) total-vm:2445684kB, anon-rss:790120kB, file-rss:2480kB, shmem-rss:0kB
[Mon Jan 12 02:34:10 2026] oom_reaper: reaped process 18231 (api-server), now anon-rss:0kB, file-rss:0kB, shmem-rss:0kB

Значення: Ваша «проблема з латентністю» може бути перезапусками. OOM може проявлятися як спорадичні p99 спайки і дивні хвилі повторів.

Рішення: Виправте limits/requests, використання пам’яті або спайки навантаження. Не ганяйтеся за примарами зберігання.

Завдання 6: Затримка диска і queue depth (щиросердний тест IO)

cr0x@server:~$ iostat -x 1 3
Linux 6.5.0-18-generic (api-3)  01/12/2026  _x86_64_  (8 CPU)

Device            r/s     w/s   rkB/s   wkB/s  aqu-sz  await  r_await  w_await  %util
nvme0n1         220.0   980.0  8120.0 42100.0    9.40   8.60     2.10     10.10  97.80

Значення: Високий %util плюс високий await вказують на насичення; aqu-sz показує глибину черги. w_await вище за r_await часто вказує на тиск записів.

Рішення: Якщо насичено: зменшіть write amplification (пакетування, поведінка fsync), перемістіть «гарячі» дані на швидше сховище або масштабуйтесь горизонтально.

Завдання 7: Знайти процеси, що виконують IO

cr0x@server:~$ sudo iotop -b -n 1 | head -n 12
Total DISK READ: 12.34 M/s | Total DISK WRITE: 78.22 M/s
  PID  PRIO  USER     DISK READ  DISK WRITE  SWAPIN      IO>    COMMAND
21011 be/4  postgres  1.10 M/s   62.50 M/s   0.00 %  35.22 %  postgres: checkpointer
18298 be/4  app       0.25 M/s    8.10 M/s   0.00 %   5.10 %  api-server

Значення: Якщо checkpointer або завдання compact домінують у записах, латентність вашого додатку може бути колатеральною шкодою.

Рішення: Налаштуйте контрольні точки/компакти БД, перемістіть їх поза піком або ізолюйте IO (cgroups, окремі томи).

Завдання 8: Стан файлової системи і опції монтування (тихі вбивці продуктивності)

cr0x@server:~$ mount | grep -E ' /var/lib/postgresql| /data'
/dev/nvme0n1p2 on /var/lib/postgresql type ext4 (rw,relatime,discard,errors=remount-ro)

Значення: Опції на кшталт discard можуть шкодити стійкій продуктивності записів на деяких SSD-конфігураціях.

Рішення: Розгляньте плановий fstrim замість безперервного discard, якщо тривалі записи важливі і ваша комбінація SSD/контролера цього не любить.

Завдання 9: Перепередачі й втрати в мережі (пропускна здатність — не завжди ваша проблема)

cr0x@server:~$ ss -s
Total: 1542 (kernel 0)
TCP:   912 (estab 803, closed 72, orphaned 0, synrecv 4, timewait 72/0), ports 0

Transport Total     IP        IPv6
RAW       0         0         0
UDP       14        12        2
TCP       840       812       28
INET      854       824       30
FRAG      0         0         0

cr0x@server:~$ netstat -s | grep -E 'retransmit|segments retransmited|RTO'
    144523 segments retransmited

Значення: Retransmits свідчать про втрати або конґестію. Це проявляється як хвостова затримка навіть коли середня пропускна здатність здається нормальною.

Рішення: Дослідіть помилки NIC, черги, невідповідність MTU або стан мережі вище по ланцюгу перед тим, як масштабувати обчислювальні ресурси.

Завдання 10: Затримка DNS (залежність, про яку всі забувають)

cr0x@server:~$ resolvectl statistics
DNSSEC supported: no
Transactions: 124532
  Current Transactions: 0
Cache Size: 4096
Cache Hits: 100122
Cache Misses: 24410
DNSSEC Verdicts: 0

cr0x@server:~$ dig +stats api.internal A
;; Query time: 148 msec
;; SERVER: 127.0.0.53#53(127.0.0.53) (UDP)
;; WHEN: Mon Jan 12 02:41:55 UTC 2026
;; MSG SIZE  rcvd: 54

Значення: 148ms на DNS-запит може отруїти p99, якщо ви виконуєте їх на кожен запит або після викидання кешу.

Рішення: Виправте здоров’я резолвера, збільшіть кешування, зменшіть per-request lookup і встановіть розумні TTL.

Завдання 11: Чергу на рівні додатку (потоки, backlog, пули з’єднань)

cr0x@server:~$ ss -lntp | grep ':443'
LISTEN 0 4096 0.0.0.0:443 0.0.0.0:* users:(("nginx",pid=1123,fd=8))

Значення: Розмір listen backlog і тиск на accept queue можуть спричиняти спорадичні затримки з’єднань, що нагадують «випадкову латентність».

Рішення: Якщо бачите SYN backlog або проблеми з accept queue (через ss і лічильники ядра), налаштуйте backlog і усуньте пікову нестабільність upstream.

Завдання 12: Тиск планувальника ядра (перемикання контексту може бути вузьким місцем)

cr0x@server:~$ pidstat -w 1 3
Linux 6.5.0-18-generic (api-3)  01/12/2026  _x86_64_  (8 CPU)

02:42:10 PM   UID       PID   cswch/s nvcswch/s  Command
02:42:11 PM  1001     18231   2200.00   9800.00  api-server

Значення: Висока кількість невільних переключень контексту свідчить про contention: замки, run queue pressure або занадто багато потоків.

Рішення: Зменшіть concurency, виправте замки, або профілюйте «гарячі» місця. Більше потоків — не завжди більше швидкості.

Завдання 13: Перевірка реальності ZFS (ARC, dirty data, стан пулу)

cr0x@server:~$ sudo zpool status
  pool: tank
 state: ONLINE
config:

        NAME        STATE     READ WRITE CKSUM
        tank        ONLINE       0     0     0
          mirror-0  ONLINE       0     0     0
            sda     ONLINE       0     0     0
            sdb     ONLINE       0     0     0

errors: No known data errors

cr0x@server:~$ sudo arcstat 1 1
    time  read  miss  miss%  dmis  dm%  pmis  pm%  mmis  mm%  arcsz     c
14:42:25  9721   812      8    49    6   621   76   142   18   28.3G  30.0G

Значення: Низький miss% зазвичай означає, що читання обслуговуються з кешу; якщо повільно — ваше вузьке місце не в сирому read IO.

Рішення: Якщо ARC hit rate хороший, а затримка погана — дивіться на записи, синхронізацію, фрагментацію чи зависання додатку.

Завдання 14: Kubernetes throttling (швидкий код, повільні квоти)

cr0x@server:~$ kubectl top pod -n prod | head
NAME                         CPU(cores)   MEMORY(bytes)
api-7f8c9d7b5c-2kq9m          980m         610Mi
api-7f8c9d7b5c-8tqz1          995m         612Mi

cr0x@server:~$ kubectl describe pod api-7f8c9d7b5c-2kq9m -n prod | grep -i thrott
  cpu throttling:  38% (cgroup)

Значення: CPU throttling породжує спайки латентності, що виглядають як «GC» або «випадкова повільність».

Рішення: Підвищіть CPU limits, правильно вкажіть requests, або зменшіть CPU на запит. Не купуйте «швидші вузли», поки поди обмежені.

Три корпоративні міні-історії з польових боїв

Міні-історія 1: Інцидент через хибне припущення

Середньої величини SaaS-компанія мала чистий графік: більше трафіку, більше CPU і регулярне зростання латентності щоранку в понеділок.
Припущення було миттєве й упевнене: «Ми обмежені CPU. Масштабуйте API-ноди».

Вони зробили це. Двічі. Латентність покращувалась близько години, а потім поверталась назад. Витрати зросли постійно, що точно привернуло увагу фінансів.
Ротація on-call отримала нове хобі: дивитись на графіки і відчувати себе осудженою ними.

Справжньою причиною була залежність: сервіс метаданих, який робив синхронні DNS-запити для кожного запиту, бо команда «оптимізувала» локальний кеш.
Коли кеш резолвера почав інтенсивно оновлюватись під понеділковим трафіком, час DNS-запитів виріс і спричинив каскад затримок при встановленні з’єднань.
Сервери API були «завантажені» в основному тому, що вони чекали.

Виправлення було нудним: відновити кешування, додати невеликий in-process TTL кеш для резольвених endpoint-ів і обмежити concurrency під час деградації резолвера.
Масштабування CPU лишилось як міра потужності, а не як забобон.

Урок не в тому, що «DNS повільний». Урок: ніколи не робіть припущення про вузьке місце з однієї метрики. Високий CPU може бути симптомом очікування так само, як причиною повільності.

Міні-історія 2: Оптимізація, що дала відкат

Велика аналітична платформа мала нічне завдання, яке тривало годинами. Хтось профілював і виявив багато дрібних записів у БД.
Пропозиція виглядала елегантно: збільшити розмір батчів і зробити записи асинхронними. У стенді робота прискорилась. Усі аплодували.

У продакшні робота теж стала швидшою — до певного моменту. Через ~40 хвилин латентність записів БД підскочила, реплікація відстала, а читання почало хитатись.
On-call відкотив джоб. Система поверталась до нормального стану повільно, як після поганого рішення.

Відкат був класичний: більші асинхронні батчі підсилювали write amplification і тиск на контрольні точки. Фонові процеси записувача і checkpointer почали «боротись» з навантаженням.
IO-черги заповнились. Латентність стала нелінійною. Джоб, що «закінчувався швидше», також спричинив тимчасовий збій зберігання.

Остаточне рішення не було «назавжди менші батчі». Це було контрольоване пропускання: rate limiting на записи, планування поза піком і ізоляція IO БД на окремі томи.
Система стала повільнішою у вузькому сенсі — джоби тривали довше — але стабільною і передбачуваною. Оце і є ефективність.

Жарт №2: Найшвидша база — та, яку ви випадково не бенчмаркуєте продакшн-аутеджем.

Міні-історія 3: Нудна, але правильна практика, що врятувала день

Платіжний сервіс працював на змішаних фізичних і віртуальних хостах з жорстким SLO і невеликою любов’ю до драми. У них була одна звичка:
кожна зміна продуктивності вимагала плану відкату і вимірюваного критерію успіху перед merge.

Одного дня зміна, що вплинула на поведінку connection pool, пішла в продакшн. Латентність не вибухнула одразу; вона почала поступово погіршуватись.
p95 трохи піднявся, p99 більше, і потім зріс рівень повторів. Сервіс не впав. Він просто став дорожчим у підтримці.

Дисципліна команди спрацювала. У них був дашборд з ретраями по ендпоінтах і сигналами насичення по залежностях.
Вони також мали canary rollout з автоматичним відкатом при регресії хвостової затримки. Зміна відкотилась сама до того, як більшість клієнтів помітили.

Постмортем не був героїчним. Він був практичним. Вони підкоригували ліміти пулу, додали jittered backoff і оновили навантажувальні тести, щоб відповідати реальним сплескам трафіку.
Ніякого нового заліза. Жодних нічних масштабувань. Лише компетентність і стриманість.

Урок: ефективність — це операційна гігієна. Система лишалась достатньо швидкою, бо команда була достатньо дисциплінованою.

Поширені помилки: симптом → коренева причина → виправлення

Ось режими відмов, що повторюються в інцидентах продуктивності — особливо тих, що спричинені ініціативами «зробити швидше».
Кожен приклад містить конкретне виправлення, бо загальні поради породжують повтори інцидентів.

1) Симптом: p99 спайки латентності, p50 виглядає нормально

Коренева причина: чергування під час сплесків; залежність має джитер; повтори підсилюють навантаження; паузи GC.

Виправлення: додайте backpressure (обмеження concurrency), реалізуйте jittered exponential backoff і інструментуйте латентності залежностей окремо від загальної.

2) Симптом: CPU високий, масштабування не допомагає

Коренева причина: contention на замках, накладні витрати ядра або очікування на IO/мережу при інтенсивних переключеннях контексту.

Виправлення: зменшіть кількість потоків, профілюйте contention (mutex/lock profiling) і ізолюйте повільні залежності; перевірте через pidstat -w і flamegraphs.

3) Симптом: %util диска близько 100%, але пропускна здатність не вражає

Коренева причина: дрібні випадкові IO, sync-записи, write amplification або зловмисний фоновий процес.

Виправлення: змінити патерни IO (пакетування з обмеженнями, а не безмежне), налаштувати fsync, відокремити WAL/логи і ідентифікувати IO-важкі процеси за допомогою iotop.

4) Симптом: «Ми замінили на швидші SSD, але не стало швидше»

Коренева причина: вузьке місце перемістилось на CPU, пропускну здатність пам’яті, мережу або серіалізацію додатку; також можлива контенція PCIe lane.

Виправлення: вимірюйте end-to-end; перевірте CPU steal, run queue і «гарячі» місця в додатку. Швидші компоненти не виправлять серіалізований код.

5) Симптом: спайки латентності під час деплоїв

Коренева причина: холодні кеші, thundering herd при старті, хвилі з’єднань або автоскейлінгова нестабільність.

Виправлення: підігрівайте кеші поступово, рознесіть старт, використовуйте connection pooling і обмежуйте ініціалізаційні завдання.

6) Симптом: періодичні спайки латентності кожні N хвилин

Коренева причина: планові завдання (checkpoints, compaction, бекапи), cron-шторми або автомоментальні знімки.

Виправлення: перенесіть завдання поза пік, обмежте їх пропускну здатність або ізолюйте ресурси. Підтвердіть, зіставивши часові мітки з логами завдань і IO-графіками.

7) Симптом: Kubernetes-поди «використовують 1 ядро», але латентність висока

Коренева причина: троттлінг CPU через ліміти; невідповідність requests/limits; contention на вузлі.

Виправлення: відрегулюйте CPU limits/requests, використайте менше але більших подів якщо накладні витрати домінують, і відстежуйте метрики троттлінгу явно.

8) Симптом: мережеві графіки виглядають нормально, але клієнти таймаутять

Коренева причина: втрата пакетів, retransmits, затримка DNS або SYN backlog під сплеском.

Виправлення: перевірте retransmits, статистику NIC, здоров’я резолвера; налаштуйте backlog і зменшіть churn з’єднань через keep-alives/пули.

Контрольні списки / покроковий план

Контрольний список A: Перед тим як щось оптимізувати

1. Напишіть мету у формі SLO: «p99 < X ms при Y RPS з error rate < Z.»
2. Визначте бюджет: допустиме збільшення витрат, складності, ризику.
3. Опишіть план відкату. Якщо ви не можете відкотити — ви не «налаштовуєте», ви «сподіваєтесь».
4. Оберіть вікно вимірювання і реалістичну форму навантаження (включно зі сплесками і викиданням кешу).
5. Захопіть базову лінію: перцентилі, метрики насичення і латентності залежностей.

Контрольний список B: Послідовність безпечної оптимізації (порядок важливий)

1. Приберіть роботу: уникайте непотрібних викликів, зменшіть розміри payload, уникайте дублювання серіалізації.
2. Приберіть ампліфікацію: зупиніть шторм повторів, зупиніть N+1 запити, зменшіть write amplification.
3. Контролюйте конкуренцію: встановіть ліміти, застосуйте backpressure, захистіть залежності.
4. Покращіть локальність: кешування з межами, розміщення даних, зменшення міжзонного трафіку.
5. Тільки потім масштабуйтесь: масштабування горизонтально, якщо робота незмінна і виміряно, що ресурс насичений.

Контрольний список C: План ефективності для зберігання

1. Спочатку виміряйте затримку і глибину черги (await, aqu-sz), а не тільки пропускну здатність.
2. Визначте синхронно-інтенсивних записувачів (WAL, журналювання, fsync-патерни).
3. Відокремте «гарячі» шляхи записів від холодних даних, де можливо (логи/WAL проти файл даних).
4. Підтвердіть опції файлової системи; уникайте «прапорців продуктивності», яких не розумієте.
5. Плануйте ємність з запасом: сховище, що близьке до заповнення, уповільнюється і потім ви собі не дуже сподобаєтесь.

Контрольний список D: Якщо треба «зробити швидше» під тиском

1. Оберіть один важіль з низьким радіусом ураження: масштабування стейтлес-тіру, rate-limit кривдників, відключення некритичних фіч.
2. Спостерігайте хвостову затримку і error rate 10–15 хвилин після зміни.
3. Якщо хвіст покращився, але витрати вибухнули — розглядайте це як пом’якшення, а не як рішення.
4. Заплануйте реальне виправлення: видаліть роботу, виправте ампліфікацію, ізолюйте залежності.

Що робити замість «швидше»: проектування для ефективної продуктивності

Проектуйте під хвостову поведінку, а не під героїчні бенчмарки

Бенчмарки потрібні, але типовий бенчмарк — це пряма лінія: постійне навантаження, теплі кеші, ніяких деплоїв, без інжекції відмов.
Продакшн не пряма лінія. Це збірка дивних вівторків.

Ефективні системи трактують хвостову затримку як вхідний параметр проєктування:

• Використовуйте таймаути і бюджети на кожну залежність.
• Скасовуйте роботу, коли клієнт пішов.
• Не повторюйте одразу; повторюйте з backoff і jitter, і обмежуйте кількість спроб.
• Віддавайте перевагу ідемпотентним операціям, щоб повтори не створювали корупції даних або дублювань записів.

Цілі щодо завантаження — це не моральне судження

Існує культ «тримати все на 80% завантаження». Звучить ефективно. Іноді — безрозсудно.
Високе завантаження прийнятне, коли варіативність низька і робота передбачувана. Розподілені системи — не низьковаріативні.

Для latency-sensitive сервісів мета часто така: нижче середнє завантаження, щоб зберегти голову запасу для сплесків.
Цей запас запобігає колапсу чергування під час піків трафіку, промахів кешу, відмов і деплоїв.

Знайте клас вашого вузького місця, потім обирайте оптимізацію

Роботи з продуктивності стають дорогими, коли їх роблять сліпо. Один запит «зробіть швидше» має різні відповіді залежно від того, що саме насичено:

• Обмежено CPU: зменште CPU на запит, покращіть алгоритми, зменшіть вартість серіалізації, використайте кращі структури даних.
• Обмежено пам’яттю: покращіть локальність, зменшіть алокації, зменшіть робочий набір, налаштуйте кеші з явними межами.
• Обмежено IO: зменшіть sync-записи, пакетування з обмеженнями, змініть патерни доступу, ізолюйте томи.
• Обмежено мережею: стискайте, зменшуйте чаттер, колокалізуйте залежності, виправляйте втрати/retransmits.
• Обмежено contention/замками: зменшіть спільний стан, шардуйте, обережно використайте lock-free структури, уникайте глобальних mutex.

FAQ

1) Якщо користувачі скаржаться, що повільно, чи не варто просто зробити швидше?

Спочатку зробіть передбачуваним. Користувачі більше ненавидять непослідовність, ніж «немаксимальну швидкість».
Виправте хвостову латентність, повтори і таймаути, перш ніж ганятися за бенчмарками.

2) Яке найпростішe визначення ефективності для SRE-команди?

Виконувати SLO з мінімальними витратами і мінімальним операційним ризиком. Якщо приріст швидкості підвищує кількість інцидентів — це не ефективно, навіть якщо гарно виглядає на графіку.

3) Чому масштабування іноді не зменшує латентність?

Бо ви не обмежені тим ресурсом, який масштабували. Або обмежені спільною залежністю (DB, кеш, мережа, сховище).
Масштабування також може підвищити накладні витрати на координацію і churn з’єднань.

4) Чи кешування завжди вигідне для ефективності?

Ні. Кеші можуть створювати stampede, підвищувати варіативність, приховувати питання свіжості даних і ускладнювати інвалідaцію.
Кешуйте з явними межами, спостерігайте викидання й сплески промахів, проектуйте для холодних стартів.

5) Як зрозуміти, чи проблема з сховищем — в латентності чи в пропускній здатності?

Дивіться на await, глибину черги (aqu-sz) і кореляцію з p99 сервісної латентності.
Висока пропускна здатність зі стабільною низькою латентністю — це ок. Низька пропускна здатність з високою латентністю зазвичай вказує на дрібні випадкові IO або синхронні записи.

6) Чому повтори все погіршують?

Повтори підвищують навантаження саме тоді, коли система найменш здатна його витримати. Ось retry amplification.
Використовуйте експоненційний backoff з jitter, обмежуйте спроби і трактуйте таймаути як сигнал для зниження навантаження.

7) Яка найбільша помилка «швидше» в контейнеризованому середовищі?

Ігнорування троттлінгу і ефектів шумних сусідів. Ваш додаток може бути «швидким», але обмеженим cgroup.
Відстежуйте CPU throttling, тиск пам’яті і насичення вузла.

8) Коли купівля швидшого обладнання — дійсно правильна відповідь?

Коли вузьке місце виміряне, стійке і робота невідворотна — і коли зміна не підвищить операційну крихкість.
Навіть тоді віддавайте перевагу масштабуванню і ізоляції замість героїчного тюнінгу однієї ноди, коли питання — надійність.

9) Який найшвидший спосіб марно витратити час у інженерії продуктивності?

Оптимізувати, керуючись інтуїцією. Спочатку виміряйте, змінюйте одну річ за раз і верифікуйте тим самим навантаженням.

Подальші кроки, що працюють у реальному продакшні

Якщо взяти одне: перестаньте питати «як зробити швидше?» і почніть питати «за що ми платимо цю швидкість?»
Ефективність — це дисципліна робити компроміси прозорими.

1. Оберіть одне SLO, орієнтоване на користувача, і відстежуйте хвостову затримку, помилки і повтори по залежностях.
2. Прийміть план швидкої діагностики і репетируйте його в робочий час, а не під час інцидентів.
3. Побудуйте ворота змін продуктивності: метрики успіху, план відкату і канаркова валідація p95/p99.
4. Приберіть ампліфікацію (повтори, N+1, write amplification) перед масштабуванням.
5. Витрачайте запас свідомо: тримайте достатній slack, щоб поглинати сплески, деплои і відмови без колапсу черг.

Ви не виграєте в продакшні, будучи найшвидшими в кімнаті. Ви виграєте, будучи достатньо швидкими, послідовно, поки всі інші відновлюють систему після своїх «оптимізацій».