Рішення на одній сторінці: що вибрати і коли

Використовуйте PostgreSQL коли…

• Потрібні складні запити (containment, перевірка наявності, вкладені фільтри) і ви хочете, щоб оптимізатор мав варіанти. JSONB + GIN у PostgreSQL — це набір інструментів для «дорослого» використання.
• Вам потрібні обмеження навколо напівструктурованих даних: CHECK-обмеження, expression-індекси, згенеровані колонки та функціональні індекси — усе це перша категорія громадян.
• Очікуєте, що JSON залишиться довше, ніж квартал. PostgreSQL зазвичай краще «старіє», коли JSON стає частиною основної схеми.
• Ви компетентно керуєте VACUUM. PostgreSQL винагородить вас, але тільки якщо ви поважаєте роботу MVCC з прибиранням.

Використовуйте MySQL коли…

• Використання JSON — це переважно зберігання документа й вибірка, а не важке аналітичне фільтрування. Якщо запити — «взяти за id, повернути blob», MySQL цілком підходить.
• Ви покладаєтесь на згенеровані колонки, щоб проектувати «гарячі» JSON-шляхи в індексовані скалярні значення. Це практичний шлях MySQL до передбачуваності.
• Ви вже стандартизувалися на MySQL операційно і JSON — невелика частина навантаження. Послідовні операції кращі за теоретичну елегантність.

Що я порадив би команді в продакшені

Якщо ваші колонки JSON — це тимчасове рішення (швидкий інгест, нормалізувати пізніше), обирайте ту СУБД, якою ваша команда вже вміє керувати. Але якщо JSON — це контракт інтерфейсу (події, конфігурації, feature flags, атрибути користувача) і ви очікуєте запитів всередині нього в масштабі, PostgreSQL зазвичай безпечніший довгостроковий вибір.

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

Цитата, яка має бути в кожному on-call runbook: «Сподівання — це не стратегія.» — широко повторюваний операційний афоризм (парафраз). З JSON сподіватися, що база «сама розбереться», — це як купити собі інцидент на вихідні.

Факти та історія: як ми дійшли до цього

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

8 фактів, які варто тримати в голові

1. PostgreSQL додав JSON у 9.2 (2012), а потім представив JSONB у 9.4 (2014) для бінарного зберігання та кращої індексації.
2. MySQL представив власний тип JSON у 5.7 (2015); до того це був TEXT з надією та регулярними виразами.
3. JSONB нормалізує порядок ключів і видаляє дублікати ключів (перемагає останній ключ). Це чудово для індексації, але може дивувати, якщо ви хочете зберегти «рівно те, що надіслали».
4. MySQL теж зберігає JSON у бінарному форматі і валідовує JSON при вставці, уникаючи деяких жахів з «невалідними blob».
5. GIN-індекси в PostgreSQL спочатку були створені для повнотекстового пошуку, потім стали робочою конячкою для containment у JSONB.
6. Згенеровані колонки в MySQL існують з 5.7, і вони — причина того, чому багато MySQL-деплойментів з JSON не розвалюються.
7. MVCC у PostgreSQL означає, що оновлення створюють нові версії рядків; великі оновлення JSON можуть посилювати роздування, якщо VACUUM відстає.
8. Формати реплікації важливі: row-based binlog у MySQL і logical decoding у PostgreSQL поводяться по-різному при частих оновленнях JSON і «гарячих» рядках.

Семантика JSON: що насправді зберігають рушії

MySQL: JSON — це тип, але ставтеся до нього як до документа, якщо ви не проектуєте поля

Тип JSON у MySQL — це не «TEXT з міткою». Він валідовується, зберігається в бінарному представленні й маніпулюється JSON-функціями.
Це хороша новина. Операційна реальність така, що ви рідко отримаєте стабільну продуктивність, якщо не зробите одне з двох:
(1) зберігати JSON переважно для запису й читати за первинним ключем, або (2) виносити часто запитувані шляхи в згенеровані колонки й індексувати їх.

MySQL охоче дозволить вам написати запит, що виглядає селективним, але не є індексованим. Оптимізатор зробить, що зможе, а потім просканує.
Іноді ви можете врятувати ситуацію функціональними індексами (залежить від версії) або згенерованими колонками, але потрібно діяти навмисно.

PostgreSQL: JSONB — для запитів; JSON (текст) — для збереження точного вводу

PostgreSQL дає дві філософії:
json зберігає оригінальний текст (включаючи пробіли та порядок ключів), а
jsonb зберігає декомпозований бінарний формат, оптимізований для операторів і індексації.
Якщо вам потрібна продуктивність, майже завжди варто обирати JSONB.

Оператори PostgreSQL виразні: containment (@>), перевірка наявності (?, ?|, ?&),
вилучення шляхом (->, ->>, #>, #>>), а також запити JSON path.
Ця виразність може стати пасткою: люди пишуть хитрі фільтри, які виглядають дешевими, але стають CPU-залежними під час декомпресії або зависають на індексі, що не відповідає предикату.

Жарт 1/2: JSON — як ящик для мотлоху — все вміщується, поки вам не треба знайти ножиці.

Індексація JSON: де народжується або втрачається продуктивність

Індексація в MySQL: згенеровані колонки — це дорослий хід

В MySQL індексація довільних JSON-виразів покращувалась з часом, але найнадійніша операційна схема досі:
визначити згенеровані колонки для кількох JSON-шляхів, які ви запитуєте постійно, привести їх до стабільних скалярних типів і проіндексувати.
Це дає три переваги:

• Дає оптимізатору звичайний B-tree індекс, який він розуміє.
• Уникає повторного вилучення JSON під час виконання.
• Змушує вас визнати, які поля насправді є частиною «реальної схеми».

Ловушка: зміни в схемі стають повільнішими і політично більш чутливими, бо тепер JSON-blob має щупальця в DDL і міграціях.
Це не баг. Це ціна за те, що ви робите з напівструктурованих даних структуру (бо вона нею стає, щойно ви на неї опираєтесь).

Коли індексація JSON у MySQL дає збій на практиці

• Надто динамічні предикати (різні JSON-шляхи залежно від вводу користувача) штовхають до сканувань.
• Порівняння JSON-рядків з числами викликає неявні приведення типів і ламає використання індексів.
• Використання функцій у WHERE без індексованого виразу змушує оптимізатор знехтувати індексом і робити все повільно.

Індексація в PostgreSQL: GIN потужний, але потрібно обирати клас оператора

Історія індексації JSONB у PostgreSQL сильніша, але це не магія. GIN-індекси можуть прискорити containment і перевірку наявності ключів,
але вони мають різні класи операторів:

• jsonb_ops: індексує більше типів операцій, але може бути більшим за розміром.
• jsonb_path_ops: компактніший і швидший для containment, але підтримує менше операторів.

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

Expression-індекси: практичний міст між JSON і реляційним

Якщо ви часто фільтруєте по одному витягнутому полю (наприклад, payload->>'customer_id'), expression-індекс може бути компактнішим за широкий GIN
за розміром і передбачуваністю. Також ним легше оперувати, оцінюючи селективність.

Жарт 2/2: GIN-індекс — як кофеїн — неймовірний, коли влучно застосований, шкода, коли перестаратися.

Шаблони запитів, що розділяють «нормально» від «горить»

Шаблон 1: «Отримати за id і повернути JSON» (відносно безпечно)

І MySQL, і PostgreSQL добре з цим справляються. Домінуючий витрат — це I/O і розмір рядка, а не JSON-функції.
Де команди потрапляють у пастку — повільне наростання: JSON росте, рядок збільшується, ефективність кешу падає, і раптом «прості читання» стають дисковими читаннями.

Шаблон 2: «Фільтрація за ключами JSON з великою кардинальністю» (індекс або помирай)

Якщо ви фільтруєте за user_id, tenant_id, order_id всередині JSON, ви фактично фільтруєте за реляційним ключем.
Не прикидайтеся, що це гнучко. Виведіть це: згенерована колонка + індекс у MySQL, expression-індекс у Postgres або зробіть це справжньою колонкою.
Це не ідеологія. Це про уникнення повних сканів і нестабільних планів виконання.

Шаблон 3: «Ad-hoc аналітика по JSON» (бережіться повільного наростання)

JSON привабливий для аналітики, бо самопояснюваний. У продакшн OLTP-базах це пастка.
Ad-hoc аналітика зазвичай:

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

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

Шаблон 4: часткові оновлення JSON (гарячі рядки, важкі логи)

Обидві СУБД можуть оновлювати шляхи всередині JSON, але характеристики продуктивності різняться, а операційний вплив схожий:
часті оновлення великих JSON-документів означають більше записаних байтів, більше коливань індексів, більше роботи для реплікації і більше інвалідизації кешу.

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

Оновлення, WAL/binlog і відставання реплік

MySQL: реалії обсягу binlog і row-based реплікації

У MySQL великі оновлення JSON можуть породжувати великі binlog-події — особливо при row-based реплікації. Якщо ви оновлюєте багато рядків або великі документи, ваші репліки платять за це.
Відставання реплік рідко є «проблемою репліки». Це проблема ампліфікації записів додатком.

Також слід стежити за розміром транзакцій і частотою комітів. Навантаження, що оновлює JSON пачками, може створити неприємні сплески: тиск на fsync,
затримки flush binlog і беклог SQL-потоку репліки.

PostgreSQL: тиск WAL + churn MVCC

PostgreSQL записує WAL для змін, а MVCC означає, що оновлення створюють нові версії рядків. Часті оновлення великого поля JSONB дадуть:
більше WAL, більше «мертвих» кортежів, більше роботи для vacuum і потенційно більше роздування індексів.

Відставання реплік проявляється як backlog у WAL sender або затримка відтворення. Важливо відрізняти:
репліка не встигає застосовувати зміни (CPU/I/O при застосуванні) проти
праймар породжує забагато WAL (ампліфікація записів).

Операційні поради

• Вимірюйте байти WAL/binlog за секунду під час піку. Це найближче до «правди» про ампліфікацію записів.
• Розділяйте або виокремлюйте гарячі JSON-поля, якщо частота оновлень висока.
• У PostgreSQL налаштуйте autovacuum для таблиць з інтенсивними оновленнями JSON, інакше борг vacuum проявиться як борг латентності.

Зберігання і I/O: роздування, перезапис сторінок і поведінка кешу

Розмір рядка і кеш: ваш невидимий податок

Колонки JSON збільшують рядки. Більші рядки означають менше рядків на сторінці. Менше рядків на сторінці означає більше читань сторінок для тієї самої кількості логічних рядків.
Це проявляється як:

• Вищий churn буферного пулу в MySQL (InnoDB).
• Більше обертання shared_buffers у PostgreSQL.
• Більший тиск на сторінковий кеш ОС.

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

Роздування у PostgreSQL: MVCC означає, що ви винні колектору vacuum

PostgreSQL не оновлює на місці; він створює нові версії рядків. Якщо JSONB великий і часто оновлюється, накопичуються мертві кортежі, а індекси
піддаються змінам. Autovacuum може впоратися з багатьма випадками, але йому потрібні правильні пороги. Налаштування за замовчуванням призначені бути безпечними для початківців, а не оптимальними для вашого безладу.

MySQL: вторинні індекси та тиск undo/redo

InnoDB має власну ампліфікацію записів: redo logs, undo logs, doublewrite buffer, обслуговування вторинних індексів.
Великі оновлення JSON збільшують кількість затриманих байтів і можуть штовхнути вас у збій flush-логів. Ви побачите це як періодичні сплески латентності,
«раптом повільні коміти» і відставання реплік.

Практичні завдання: 14 команд, які можна запустити сьогодні

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

Завдання 1 (MySQL): підтвердити використання JSON і тиск на розмір

cr0x@server:~$ mysql -e "SELECT table_schema, table_name, column_name, data_type FROM information_schema.columns WHERE data_type='json' ORDER BY table_schema, table_name;"
+--------------+------------+-------------+-----------+
| table_schema | table_name | column_name | data_type |
+--------------+------------+-------------+-----------+
| app          | events     | payload     | json      |
| app          | users      | attrs       | json      |
+--------------+------------+-------------+-----------+

Значення: тепер ви знаєте, які таблиці кандидати на JSON-проблеми.
Рішення: скоротіть список до топ-1–3 таблиць за кількістю рядків і частотою оновлень. Саме там індексація й вибір схеми мають значення.

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

cr0x@server:~$ mysql -e "SELECT table_name, table_rows, ROUND(data_length/1024/1024,1) AS data_mb, ROUND(index_length/1024/1024,1) AS index_mb FROM information_schema.tables WHERE table_schema='app' ORDER BY data_length DESC LIMIT 10;"
+------------+------------+---------+----------+
| table_name | table_rows | data_mb | index_mb |
+------------+------------+---------+----------+
| events     |    4821031 |  8120.4 |   2104.7 |
| users      |     820114 |  1190.8 |    412.2 |
+------------+------------+---------+----------+

Значення: таблиці з великою вагою JSON зазвичай роздувають data_mb.
Рішення: якщо data_mb росте швидше, ніж бізнес, потрібно обмежити розмір payload, стиснути дані на вході або нормалізувати гарячі поля.

Завдання 3 (MySQL): знайти повільні JSON-предикати в slow log

cr0x@server:~$ sudo pt-query-digest /var/log/mysql/mysql-slow.log --limit 5
#  1.2s user time, 40ms system time, 27.31M rss, 190.55M vsz
# Query 1: 0.68 QPS, 0.31x concurrency, ID 0xA1B2C3D4 at byte 91234
# Time range: 2025-12-28T00:00:00 to 2025-12-28T01:00:00
# Attribute    pct   total     min     max     avg     95%  stddev  median
# ============ === ======= ======= ======= ======= ======= ======= =======
# Exec time     62   180s    120ms     12s    540ms     3s   900ms   300ms
# Rows examine  90  1200M      10   2.5M   360k   1.1M   500k   200k
# Query: SELECT ... WHERE JSON_EXTRACT(payload,'$.customer.id') = ?

Значення: rows examined — ваш «податок на сканування». JSON_EXTRACT у WHERE без індексу — типовий підозрюваний.
Рішення: створіть згенеровану колонку для цього шляху (або функціональний індекс, якщо доречно) і перепишіть запит, щоб використовувати її.

Завдання 4 (MySQL): перевірити, чи використовує запит індекс

cr0x@server:~$ mysql -e "EXPLAIN SELECT id FROM app.events WHERE JSON_UNQUOTE(JSON_EXTRACT(payload,'$.customer.id'))='12345' LIMIT 10\G"
*************************** 1. row ***************************
           id: 1
  select_type: SIMPLE
        table: events
   partitions: NULL
         type: ALL
possible_keys: NULL
          key: NULL
      key_len: NULL
          ref: NULL
         rows: 4821031
     filtered: 10.00
        Extra: Using where

Значення: type: ALL і відсутність key означають повний перегляд таблиці.
Рішення: не налаштовуйте спочатку буфери. Виправляйте схему/запит: згенерована колонка + індекс або редизайн.

Завдання 5 (MySQL): додати згенеровану колонку для гарячого JSON-шляху

cr0x@server:~$ mysql -e "ALTER TABLE app.events ADD COLUMN customer_id VARCHAR(64) GENERATED ALWAYS AS (JSON_UNQUOTE(JSON_EXTRACT(payload,'$.customer.id'))) STORED, ADD INDEX idx_events_customer_id (customer_id);"
Query OK, 0 rows affected (2 min 41 sec)
Records: 0  Duplicates: 0  Warnings: 0

Значення: STORED-згенерована колонка матеріалізує значення, індекс стає доступним.
Рішення: перепишіть запити додатка, щоб фільтрувати за customer_id замість JSON_EXTRACT у WHERE. Потім перевірте EXPLAIN.

Завдання 6 (MySQL): перевірити, чи оптимізатор тепер використовує новий індекс

cr0x@server:~$ mysql -e "EXPLAIN SELECT id FROM app.events WHERE customer_id='12345' LIMIT 10\G"
*************************** 1. row ***************************
           id: 1
  select_type: SIMPLE
        table: events
         type: ref
possible_keys: idx_events_customer_id
          key: idx_events_customer_id
      key_len: 258
          ref: const
         rows: 120
        Extra: Using index

Значення: ви перейшли від сканування мільйонів до торкання ~120 рядків.
Рішення: запустіть у прод, але слідкуйте за латентністю запису: підтримка нового індексу підвищує вартість записів.

Завдання 7 (MySQL): перевірити відставання репліки та тиск на застосування

cr0x@server:~$ mysql -e "SHOW REPLICA STATUS\G" | egrep "Seconds_Behind_Source|Replica_SQL_Running|Replica_IO_Running|Last_SQL_Error"
Replica_IO_Running: Yes
Replica_SQL_Running: Yes
Seconds_Behind_Source: 87
Last_SQL_Error:

Значення: відставання є, хоча потоки працюють. Зазвичай застосування не встигає за записами.
Рішення: виміряйте швидкість binlog і розмір транзакцій; зменшіть обсяг оновлень JSON або змініть батчинг до того, як звинувачувати репліку.

Завдання 8 (PostgreSQL): перелічити JSON/JSONB колонки та їх таблиці

cr0x@server:~$ psql -d appdb -c "SELECT table_schema, table_name, column_name, data_type FROM information_schema.columns WHERE data_type IN ('json','jsonb') ORDER BY 1,2,3;"
 table_schema | table_name | column_name | data_type
--------------+------------+-------------+-----------
 public       | events     | payload     | jsonb
 public       | users      | attrs       | jsonb
(2 rows)

Значення: охоплення. Як і в MySQL: знайдіть кілька таблиць, що мають найбільший вплив.
Рішення: фокусуйтеся на таблицях з великою частотою оновлень і запитами, що впливають на клієнтів.

Завдання 9 (PostgreSQL): знайти найгірші JSON-запити за загальним часом

cr0x@server:~$ psql -d appdb -c "SELECT calls, total_exec_time::bigint AS total_ms, mean_exec_time::numeric(10,2) AS mean_ms, rows, query FROM pg_stat_statements WHERE query ILIKE '%jsonb%' OR query ILIKE '%->%' OR query ILIKE '%@>%' ORDER BY total_exec_time DESC LIMIT 5;"
 calls | total_ms | mean_ms | rows |                   query
-------+----------+---------+------+-------------------------------------------
 18211 |   932144 |   51.20 |    0 | SELECT ... WHERE payload @> $1
  4102 |   512030 |  124.82 |    0 | SELECT ... WHERE (payload->>'customer')= $1
(2 rows)

Значення: у вас гарячі запити, а не теоретичні проблеми.
Рішення: запустіть EXPLAIN (ANALYZE, BUFFERS) на топ-обвинувачах і побудуйте правильний індекс для форми предикату.

Завдання 10 (PostgreSQL): переглянути план запиту JSONB з інформацією про буфери

cr0x@server:~$ psql -d appdb -c "EXPLAIN (ANALYZE, BUFFERS) SELECT id FROM events WHERE payload @> '{\"customer\":{\"id\":\"12345\"}}'::jsonb LIMIT 10;"
                                                          QUERY PLAN
------------------------------------------------------------------------------------------------------------------------------
 Limit  (cost=0.42..8.44 rows=10 width=8) (actual time=0.088..0.146 rows=10 loops=1)
   Buffers: shared hit=42
   ->  Index Scan using idx_events_payload_gin on events  (cost=0.42..22134.77 rows=26235 width=8) (actual time=0.086..0.141 rows=10 loops=1)
         Index Cond: (payload @> '{"customer": {"id": "12345"}}'::jsonb)
         Buffers: shared hit=42
 Planning Time: 0.412 ms
 Execution Time: 0.182 ms
(7 rows)

Значення: index scan + переважно попадання у буфери = здорово.
Рішення: зберігайте цей індекс, якщо він підтримує основні продуктові шляхи. Якщо він лише для ad-hoc запитів — не платіть за нього вартість записів.

Завдання 11 (PostgreSQL): створити цільовий GIN-індекс (обрати клас оператора)

cr0x@server:~$ psql -d appdb -c "CREATE INDEX CONCURRENTLY idx_events_payload_pathops ON events USING gin (payload jsonb_path_ops);"
CREATE INDEX

Значення: concurrent build уникає блокування записів (ціною часу і додаткової роботи).
Рішення: використовуйте jsonb_path_ops, коли домінує containment; інакше розглядайте jsonb_ops або expression-індекси.

Завдання 12 (PostgreSQL): побудувати expression-індекс для одного гарячого шляху

cr0x@server:~$ psql -d appdb -c "CREATE INDEX CONCURRENTLY idx_events_customer_id_expr ON events ((payload->'customer'->>'id'));"
CREATE INDEX

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

Завдання 13 (PostgreSQL): перевірити сигнали роздування і ефективність autovacuum

cr0x@server:~$ psql -d appdb -c "SELECT relname, n_live_tup, n_dead_tup, last_autovacuum, last_vacuum FROM pg_stat_user_tables ORDER BY n_dead_tup DESC LIMIT 5;"
 relname | n_live_tup | n_dead_tup |    last_autovacuum     |     last_vacuum
---------+------------+------------+------------------------+------------------------
 events  |    4809123 |     912044 | 2025-12-28 00:41:12+00 | 2025-12-22 03:11:02+00
 users   |     820104 |      12033 | 2025-12-28 00:38:01+00 | 2025-12-23 02:08:40+00
(2 rows)

Значення: мертві кортежі в events великі; autovacuum працює, але може бути недопровідним для рівня churn.
Рішення: налаштуйте autovacuum для конкретної таблиці, зменшіть частоту оновлень великого JSONB або виокреміть гарячі змінні поля.

Завдання 14 (Системний рівень): визначити, чи ви обмежені I/O або CPU

cr0x@server:~$ iostat -x 1 5
Linux 6.1.0 (db01) 	12/29/2025 	_x86_64_	(16 CPU)

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
          22.11    0.00    6.34   18.90    0.00   52.65

Device            r/s     rkB/s   rrqm/s  %rrqm  r_await rareq-sz     w/s     wkB/s   w_await wareq-sz  aqu-sz  %util
nvme0n1         320.0  18240.0     0.0   0.00    4.20    57.00   410.0  24576.0    9.80    59.95   6.10   92.0

Значення: високий %util і значний iowait вказують на насичення сховища. JSON-навантаження часто збільшують I/O через більші рядки і churn індексів.
Рішення: спочатку виправте шаблони запитів/індексів; якщо все ще насичено — масштабувати IOPS (кращі диски) або знизити ампліфікацію записів (зміни в схемі/дизайні).

Швидкий план діагностики

Коли JSON-запити повільні, люди витрачають години на суперечки про «вибір СУБД» замість того, щоб знайти реальний горловий вузол.
Цей план — порядок дій під час інциденту — бо він швидко сходиться до висновку.

Перше: доведіть, чи це скан, пропущений індекс або сирий I/O

• MySQL: запустіть EXPLAIN для повільного запиту. Якщо type: ALL, зупиніться і виправте предикат/індекс.
• PostgreSQL: запустіть EXPLAIN (ANALYZE, BUFFERS). Якщо бачите sequential scans на великих таблицях — потрібен відповідний індекс або перепис запиту.
• Система: перевірте iostat -x. Якщо сховище завантажене, скани і роздування будуть головними підозрюваними.

Друге: кількісно оцініть ампліфікацію записів і тиск на реплікацію

• MySQL: перевіряйте відставання реплік і патерни росту binlog; великі оновлення JSON часто корелюють із стрибками відставання.
• PostgreSQL: перевіряйте генерацію WAL і мертві кортежі; інтенсивні оновлення JSON можуть перетворити vacuum на постійну фонову кризу.

Третє: перевірте ефективність кешу і наростання розміру рядка

• Чи ваш гарячий робочий набір все ще в пам’яті, або ріст JSON його витіснив?
• Чи ви додали широкий GIN-індекс, який подвоїв вартість записів?
• Чи хтось почав робити ad-hoc фільтри по неіндексованих ключах JSON?

Четверте: виправте найменшу річ, що змінює криву

• Підніміть гарячі ключі в реальні колонки (найкраще) або згенеровані/expression колонки (наступний крок).
• Додайте правильний індекс під форму предикату, потім валідуйте з EXPLAIN.
• Якщо оновлення — проблема, виокреміть змінні поля з JSON blob.

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

Помилка 1: «Запит виглядає селективним, але повільний»

Симптоми: латентність росте з розміром таблиці; EXPLAIN показує повний скан; CPU піки під час навантаження.

Корінь: вилучення JSON у WHERE без індексованого виразу (MySQL), або невідповідність між оператором і індексом (PostgreSQL).

Виправлення: MySQL: STORED згенерована колонка + B-tree індекс; PostgreSQL: expression-індекс або правильний клас оператора GIN; перепишіть предикат, щоб він відповідав індексу.

Помилка 2: «Додали GIN-індекс і записи стали повільніші»

Симптоми: зростає латентність вставок/оновлень; стрибає швидкість WAL/binlog; відставання реплік погіршується після створення індексу.

Корінь: широкий GIN-індекс на великому JSONB з частими оновленнями; висока вартість обслуговування індексу.

Виправлення: замінити на вузькі expression-індекси; використовувати jsonb_path_ops, якщо тільки containment; виокремити змінні поля; пересвідчитися, що цей запит потрібен в OLTP.

Помилка 3: «Postgres повільнішає з часом; vacuum не встигає»

Симптоми: ростуть розміри таблиць і індексів; запити гальмують; autovacuum працює постійно; багато мертвих кортежів.

Корінь: часті оновлення великих полів JSONB створюють багато мертвих кортежів; пороги autovacuum не налаштовані під рівень churn таблиці.

Виправлення: налаштувати autovacuum під таблицю; зменшити частоту/розмір оновлень; перемістити змінні дані в окрему таблицю; розглянути партиціювання для таблиць подій.

Помилка 4: «MySQL відстає після додавання JSON-фіч»

Симптоми: Seconds_Behind_Source зростає під час сплесків; репліки відновлюються повільно; коміти стрибкоподібні.

Корінь: великі row-based binlog-події від оновлень JSON; надто великі транзакції; забагато вторинних індексів на проєктованих полях JSON.

Виправлення: зменшити обсяг оновлень JSON; змінити батчинг; обмежити індексовані проекції лише дійсно гарячими шляхами; перевірити налаштування binlog/redo log і патерни комітів.

Помилка 5: «Ми зберегли все в JSON і тепер нам потрібні обмеження»

Симптоми: неконсистентні значення в JSON; валідація на рівні додатка дрейфує; запити мають обробляти відсутні ключі і неправильні типи.

Корінь: схема віддана на виконання коду додатка; відсутні інструменти примусових обмежень; міграції відкладені занадто довго.

Виправлення: підніміть ключові поля в колонки; додайте CHECK-обмеження (Postgres) або забезпечте через згенеровані колонки + NOT NULL (MySQL); введіть версіонування payload-ів.

Три корпоративні історії з полі бою JSON

1) Інцидент через хибне припущення: «JSON фактично безкоштовний для запитів»

Середня SaaS-компанія випустила «activity feed», підкріплений таблицею подій. Кожна подія мала JSON payload.
Продуктова команда хотіла фільтрацію: «показати тільки події, де payload.actor.role = ‘admin’». Легко, подумали вони.
Backend використовував MySQL, і перша реалізація використовувала JSON_EXTRACT у WHERE.

У стейджингу все було нормально. У проді це стало повільною катастрофою: таблиця events була великою, і фільтр був популярним.
Запит виглядав селективним, але робив повний скан, торкаючись мільйонів рядків на запит у піковий час.
CPU на максимумі, I/O насичене, і весь кластер розвинув симптом «усе повільне», що змушує керівництво заходити в канал інциденту.

Хибне припущення було не в тому, що «MySQL не може робити JSON». Воно полягало в тому, що «якщо предикат вузький, база оптимізує його».
Бази оптимізують те, що ви індексуєте, а не те, на що ви сподіваєтесь. Вилучення JSON без індексованого виразу — не вузька операція; це дорога операція, повторювана по багатьох рядках.

Виправлення було болісно простим: додати STORED згенеровану колонку для actor_role, індексувати її і змінити запит.
Постмортем додав правило: будь-який ключ JSON, який використовується в гарячому WHERE, має бути спроєктований і проіндексований або переміщений в реальну колонку.
Гнучка схема лишалася, але тільки там, де вона не на критичному шляху.

2) Оптимізація, що обернулася проти: «Просто додайте великий GIN-індекс»

Інша компанія працювала на PostgreSQL і мала одну величезну таблицю events з JSONB payload-ами.
Вони хотіли швидкий ad-hoc пошук для клієнтської підтримки, тому хтось додав широкий GIN-індекс на весь payload з використанням класу оператора за замовчуванням.
Швидкість запитів покращилася миттєво. Усі аплодували і перейшли далі.

Через два тижні латентність записів почала повільно повзти вгору. Активність autovacuum стала постійною. З’явилося відставання реплік під час піку.
GIN-індекс був дорогим у підтримці, бо payload-и були великі й часто оновлювалися полями enrichment.
Індекс також швидко ріс, збільшуючи навантаження на чекпойнти і I/O. Перемога в пошуку підтримки перетворилася на проблему «кожен API-ендпоінт став повільнішим».

Фіаско полягало не в тому, що GIN поганий. Воно полягало в тому, що вони проіндексували все для робочого навантаження, яке фактично не було критичним.
Індекс перетворив базу на пошукову систему. PostgreSQL це може робити, але ви платите в ампліфікації записів і роздуванні.

Остаточне вирішення: прибрати широкий індекс, додати два expression-індекси для кількох ключів, які використовувала служба підтримки,
і перенести повнотекстовий пошук з OLTP-шляху. Підтримка отримала свій робочий процес, а продакшн перестав платити податок на кожен запис.

3) Нудна, але правильна практика, що врятувала день: «Зробіть JSON контрактом, версіонуйте й тестуйте»

Фінтех-подібна команда зберігала метадані верифікації клієнта в JSONB у PostgreSQL. Там були вкладені поля, опціональні ключі й блоки від вендорів.
Вони знали, що ці дані будуть еволюціонувати, і також знали, що потрібно надійно запитувати кілька полів для звітів з комплаєнсу.
Тому вони зробили те, що здається нецікавим: додали колонку schema_version типу integer і писали явні міграції для змін форми payload.

Також вони підняли кілька критичних полів до реальних колонок: customer_id, verification_status і vendor_name.
Усе інше жило в JSONB. На додачу були CHECK-обмеження, що гарантували відповідність status відомому набору,
і тести додатка, які перевіряли сумісність схем JSON за версіями.

Через місяці вендор трохи змінив формат payload (поле перемістилося глибше).
Команди, що зберігають сирий JSON без контракту, зазвичай дізнаються про це тоді, коли звіти ламаються о 2-й ночі.
Ця команда виявила проблему в CI, бо тест валідації схеми впав і інструмент міграції змусив явне перетворення.

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

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

Якщо ви починаєте нову фічу з великою кількістю JSON

1. Запишіть топ-5 шаблонів запитів, які ви очікуєте протягом наступних шести місяців (не лише тиждень запуску).
2. Класифікуйте поля: незмінні vs змінні; часто фільтруються vs рідко фільтруються; велика кардинальність vs мала.
3. Підніміть «часто фільтровані, з великою кардинальністю» поля в реальні колонки (переважно) або згенеровані/expression колонки.
4. Оберіть стратегію індексування, специфічну для СУБД:
   • MySQL: STORED згенеровані колонки + B-tree індекси; уникайте JSON_EXTRACT у гарячих WHERE.
   • PostgreSQL: expression-індекси для гарячих шляхів; GIN для containment/перевірки наявності; вибирайте клас оператора свідомо.
5. Встановіть бюджети розміру payload (м’які й жорсткі обмеження). Ріст JSON безшумний, поки не стане критичним.
6. Плануйте еволюцію: додайте schema_version, документуйте трансформації і зробіть міграції рутиною.

Якщо ви вже випустили і все повільно

1. Знайдіть топ-3 запити за сумарним часом (slow log / pg_stat_statements).
2. Запустіть EXPLAIN з реальністю (MySQL EXPLAIN, Postgres EXPLAIN ANALYZE BUFFERS). Не гадати.
3. Додайте найменший індекс, що відповідає предикату (індекс на згенеровану колонку або expression-індекс) і перевірте зміну плану.
4. Виміряйте вартість на стороні запису після індексації (латентність комітів, швидкість WAL/binlog, відставання реплік).
5. Якщо оновлень багато, виокреміть змінні поля з JSON у окрему таблицю з правильним ключем.
6. Введіть обмеження для ad-hoc запитів (таймаути, read replicas або виділений шлях для звітності).

Якщо ви вирішуєте між MySQL і PostgreSQL для JSON сьогодні

• Вибирайте PostgreSQL, якщо запити по JSON — це продуктова фіча, а не реалізаційна деталь.
• Вибирайте MySQL, якщо JSON переважно для зберігання і ви готові проектувати гарячі ключі в індексовані згенеровані колонки.
• Оберіть СУБД, якою ваша команда вміє керувати в умовах інциденту. Теоретично краща функціональність не підніме вашого on-call о 3-й ранку.

FAQ

1) Чи завжди PostgreSQL кращий для JSON, ніж MySQL?

Ні. PostgreSQL зазвичай кращий для складних запитів і гнучкої індексації. MySQL може бути відмінним, якщо ви тримаєте використання JSON простим
або проектуєте гарячі шляхи в згенеровані колонки. «Завжди» — це шлях до аутейджів.

2) Чи варто зберігати JSON як TEXT/VARCHAR натомість?

Зазвичай ні. Ви втрачаєте валідацію і багато JSON-операторів. Якщо ви справді ніколи не запитуєте внутрішнє вміст JSON і лише зберігаєте/отримуєте його,
TEXT може працювати — але ви берете на себе ризик гігієни даних. Нативні типи JSON безпечніші для коректності.

3) Коли ключ JSON має стати реальною колонкою?

Якщо він використовується в join-ах, у гарячих WHERE, для сортування або потрібен для обмежень — це колонка. Якщо часто оновлюється,
скоріше за все, це колонка або окрема таблиця. JSON — для змінності, але не для основної ідентичності.

4) Чи вирішують GIN-індекси проблеми продуктивності JSONB у PostgreSQL?

Вони вирішують деякі проблеми. Але можуть створити інші (вартість записів, роздування, обслуговування).
Використовуйте GIN, коли ваші предикати відповідають containment/перевірці наявності і дані стабільні настільки, щоб виправдати write tax.

5) Який еквівалент GIN-індексу JSONB у MySQL?

Прямого еквіваленту немає. У MySQL зазвичай створюють згенеровані колонки, що витягують скалярні значення, і індексують їх.
Це інша філософія: ви вирішуєте заздалегідь, що важливо.

6) Як запобігти «випадковим ключам скрізь» у JSON?

Ставтеся до JSON як до контракту: версіонуйте його, валідовуйте і документуйте дозволені форми.
Примусьте критичні інваріанти базою даних (Postgres) або через згенеровані колонки + NOT NULL/касти типів (MySQL).

7) Чому часткові оновлення JSON досі дорогі?

Бо «часткове оновлення» на рівні SQL може все одно означати значне перезаписування й churn індексів на рівні зберігання,
плюс обсяг WAL/binlog. Великі документи, що часто оновлюються, будуть дорогими незалежно від того, як гарно виглядає SQL.

8) Чи можна використовувати JSON для мульти-тенантних даних і просто фільтрувати по tenant_id всередині JSON?

Можна, але не варто. Ізоляція орендарів належить реальній колонці з індексом.
Покладання tenant_id у JSON полегшує випадкове сканування по орендарях і ускладнює примусові обмеження й межі продуктивності.

9) Який найбезпечніший «гібридний» шаблон?

Зберігайте ключові поля як колонки (id, status, timestamps, foreign keys), зберігайте опційні/вендор-специфічні поля в JSON/JSONB,
і індексуйте лише невелику підмножину JSON-шляхів, які ви фактично запитуєте. Решта лишається гнучкою без росту витрат на основні запити.

Висновок: наступні кроки, що не принизять вас пізніше

JSON у MySQL і PostgreSQL вже не новинка. Це інструмент для продакшену — і як усі такі інструменти, він винагороджує дисципліну.
MySQL схильний вимагати від вас проектування структури з JSON і явного індексування. PostgreSQL дає більше виразних можливостей для запитів і індексування,
але виставить рахунок у WAL, роздуванні і обслуговуванні, якщо ви індексуєте занадто широко або часто оновлюєте великі JSONB-поля.

Практичні наступні кроки:

1. Визначте топ-3 JSON-запити за загальним часом і запустіть EXPLAIN з реальними статистиками виконання.
2. Підніміть топ-3 ключі JSON, які використовуються для фільтрації/джоїнів, у колонки або згенеровані/expression колонки й індексуйте їх.
3. Виміряйте ампліфікацію записів (WAL/binlog rate) до і після індексації; слідкуйте за відставанням реплік.
4. Введіть бюджет розміру payload і застосовуйте його на етапі інгесту.
5. Версіонуйте ваші JSON-пейлоади. Інакше майбутній ви витратить вихідні на розшифровку «чому цей ключ іноді існує».

Обирайте СУБД, що відповідає операційним сильним сторонам вашої команди, а потім проектуйте використання JSON так, ніби воно стане постійним — бо так зазвичай і буває.

Що насправді означає «повільне копіювання» (і чого це не стосується)

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

Три шаблони копіювання, які треба розрізняти

• Великі послідовні копії (наприклад, ISO, VHDX): мають йти ближче до лінійної швидкості, поки сервер може комітити записи достатньо швидко.
• Багато дрібних файлів (наприклад, дерева вихідного коду): домінують операції з метаданими (створення, setattr, close, rename), а не пропускна здатність.
• Змішані навантаження (домашні шари + ВМ + сканери): «повільно» часто означає head-of-line blocking — один поганий шаблон псує чергу для всіх.

Чого це зазвичай не стосується

Зазвичай це не «SMB повільний». SMB3 може бути дуже швидким. Зазвичай це не «ZFS повільний». ZFS може наситити серйозні мережі. Зазвичай це спайки затримки від sync-записів, дрібних випадкових I/O, посилення метаданих або поганого вирівнювання кешування, які проявляються в клієнті, що показує оптимістичні сплески швидкості.

Ще одне переналаштування: Windows Explorer — не бенчмарк, а візуалізатор тривоги. Той графік — швидше емоційний індикатор, ніж осцилограф.

Цікаві факти та історичний контекст (щоб поведінка стала зрозумілішою)

1. SMB1 vs SMB2/3 змінило все. SMB2 (ера Vista/2008) зменшила балакучість, збільшила розміри читань/записів і додала конвеєрування. Багато історій «SMB повільний» насправді — «ви застрягли на SMB1».
2. Samba починалася як проект з реверс-інженерії. Вона виросла з «змушує UNIX говорити з Windows» до рівня enterprise SMB-сервера. Деякі значення за замовчуванням консервативні, бо Samba має витримувати дивні клієнти.
3. ZFS групує записи. ZFS комітить дані в transaction group (TXG). Це робить пропускну здатність чудовою, але створює помітний «пульс», якщо фаза коміту затягується.
4. Sync-записи — це зобов’язання, а не відчуття. Коли SMB-клієнт просить забезпечити надійність, ZFS має безпечно закомітити. Якщо ваш пул не вміє робити low-latency fsync, ви отримаєте класичний графік «швидко, потім нуль».
5. SMB durable handles і leases змінили поведінку close/open. Сучасний Windows агресивно кешує. Це добре, поки додаток не вимагає семантики durable і не перетворює кешування на синхронний біль.
6. Recordsize важливіший для файлових шарів, ніж багато кому здається. recordsize ZFS формує I/O-амліфікацію. Неправильний recordsize не лише марнує місце — він додає зайві IOPS при дрібному випадковому доступі.
7. Стиснення часто допомагає SMB, навіть на швидких CPU. Багато офісних файлів добре стиснюються, знижуючи навантаження на диск і мережу. Перемога часто в латентності, а не в пропускній здатності.
8. SMB signing став поширенішим з міркувань безпеки. Увімкнення підпису — це податок на CPU. Налаштування «secure» інколи перетворюється на «securely slow», коли серверний CPU слабкий або обмежений одним потоком.

Швидкий план діагностики

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

По-перше: класифікуйте навантаження

• Один великий файл? Багато дрібних файлів? Додаток пише з вимогами до збереження (durability)?
• Швидкість падає через фіксовані інтервали (кожні кілька секунд)? Це пахне TXG commit latency.
• Трапляється лише на певних шарах (shares)? Це пахне властивостями dataset або опціями SMB share.

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

• Мережа: помилки інтерфейсу, повторні передачі, неправильний MTU, погане хешування LACP, Wi‑Fi клієнти, які поводяться як сервери.
• CPU: один ядро завантажене в smbd, наклад від signing/encryption, переривання, насичення softirq.
• Шлях зберігання: високий await на vdev, блокування шляху ZFS sync, відсутній/повільний SLOG, пул майже заповнений або фрагментований.

По-третє: перевірте поведінку sync (зазвичай це винуватець)

• Перевірте властивість dataset sync та налаштування Samba, які примушують sync (наприклад, strict sync).
• Виміряйте fsync-латентність з самого хоста SMB, а не з вашого ноутбука.
• Якщо потрібна семантика sync, забезпечте правильний SLOG-пристрій (з захистом від втрати живлення) або прийміть обмеження продуктивності ваших основних vdev.

По-четверте: ізолюйте випадок «багато дрібних файлів»

• Метадані — це навантаження. Перевірте atime, поведінку xattr та продуктивність дрібних блоків.
• Переконайтеся, що розташування пулу відповідає очікуванням по IOPS для метаданих (компроміс між mirror та RAIDZ).

По-п’яте: налаштовуйте лише те, що показали вимірювання

Якщо ви не можете показати before/after у латентності I/O, завантаженні CPU або повторних передачах, ви не налаштовуєте — ви декоруєте.

Припиніть здогадки: вимірюйте, куди йде час

SMB-копії — це переговори між клієнтом, який буферизує, і сервером, який комітить. Explorer показує «швидкість» на основі того, як швидко дані приймаються в буфери, а не того, наскільки швидко вони надійно записані. Тоді як ZFS може швидко прийняти дані в ARC і «грязні» буфери, а потім призупинитись під час коміту TXG. Саме ця пауза викликає нуль на графіку.

Ваш план вимірювань має відповісти на три питання:

1. Чи клієнт чекає на сервер (латентність), чи він просто не надсилає (обмеження клієнта)?
2. Чи сервер чекає на скидання на диск (sync-путь), чи на CPU (signing/encryption), чи на мережу?
3. Чи ZFS підсилює навантаження (несумісний recordsize, фрагментація, тиск на метадані)?

Інженерія надійності має просте правило: вимірюйте систему, яка у вас є, а не ту, якою ви хотіли б її бачити.

Парафраз (Gene Kim): «Покращення потоку означає знаходження та усунення обмеження». Ось у чому справа.

Реалії ZFS, які ускладнюють роботу з SMB

TXG і шаблон «швидко, потім нуль»

ZFS накопичує «брудні» дані в пам’яті і періодично комітить їх на диск як transaction group. Якщо фаза коміту затягується, система пригальмовує записувачів. Очима клієнта: швидкий сплеск, потім пауза. Повторюється. Це не «мережева нестабільність». Це збереження надійності зберігання.

Sync-записи: податок на надійність

Коли навантаження виконує синхронні записи (або сервер їх трактує як такі), ZFS має гарантувати, що дані на стабільному носії перед підтвердженням. На пулах без швидкого intent log (SLOG) sync-записи лягають на основні vdev. Якщо це RAIDZ на HDD, результат передбачуваний: біль з часовими відмітками.

Recordsize, ashift та I/O-ампліфікація

recordsize ZFS керує максимальною роздільною здатністю блоків для даних файлу. SMB-шерінги часто містять змішані розміри файлів; занадто великий recordsize не завжди шкодить послідовним читанням, але може нашкодити випадковим записам і частковим перезаписам. Занадто малий — збільшує накладні витрати на метадані і погіршує ефективність стиснення.

Метадані не «безкоштовні»

Копії дрібних файлів навантажують метадані: записи в директоріях, ACL, xattr, timestamps. ZFS може це обробити, але тільки якщо макет пулу і кешування розумні. Якщо ви побудували широкий RAIDZ для ємності і потім використовуєте його для метаданих важкого SMB-шару, ви фактично купили автобус і заявили його на мотогонку.

Заповненість пулу та фрагментація

Коли пул заповнюється, розміщення блоків ускладнюється, фрагментація зростає, і латентність зростає. Користувачі SMB відчують це як «все працювало минулого місяця». ZFS не забуває, як писати; йому просто виснажуються легкі місця для розміщення блоків.

Реалії SMB, які ускладнюють роботу з ZFS

Семантика копіювання Windows: буферизація, close і надійність

Windows може буферизувати записи й вимагати надійності лише при закритті файлу, залежно від прапорів додатка та конфігурації сервера. Деякі додатки (і деякі засоби безпеки) вимагають write-through семантики. Це миттєво перетворює навантаження з «переважно async» на «сильно sync».

Signing і шифрування: безпека має ціну CPU

SMB-підпис часто вимагається політиками. Може бути увімкнено шифрування для певних шарів. Обидва споживають CPU. Якщо сервер SMB має скромний CPU з швидким NIC, ви можете вдаритися в стелю, де мережа проста, а одне ядро працює на межі можливостей у криптоопераціях.

SMB3 Multichannel: чудово, коли працює, неважливо, коли ні

Multichannel може використовувати кілька NIC і черг RSS. При неправильному конфігу ви отримаєте єдиний TCP-потік, застряглий на одній черзі. Тоді хтось скаже «але у нас подвійний 10GbE», ніби сервер зобов’язаний зацікавитися.

Opportunistic locks, leases і антивірус

Кешування на клієнті (oplocks/leases) зменшує чати. Але засоби безпеки на кінцевих точках люблять відкривати файли, змушувати оновлювати атрибути і загалом ламати поведінку кешування. Це може перетворити копію «багато дрібних файлів» в шаленство системних викликів.

Жарт №1: Трасування проблем SMB схоже на офісну політику — кожен наполягає, що він вузьке місце, і всі вони якимось чином праві.

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

Нижче — реальні завдання, які ви можете виконати на SMB/ZFS сервері. Кожне містить, що означає вивід і яке рішення потрібно прийняти далі. Приклади орієнтовані на Linux + Samba + OpenZFS, бо саме там більшість тикетів «Windows копіювання повільне» живе.

Завдання 1: Підтвердіть стан пулу (бо продуктивність часто — симптом помираючого диска)

cr0x@server:~$ sudo zpool status -v tank
  pool: tank
 state: ONLINE
  scan: scrub repaired 0B in 04:12:19 with 0 errors on Tue Dec 10 03:20:01 2025
config:

        NAME                        STATE     READ WRITE CKSUM
        tank                        ONLINE       0     0     0
          mirror-0                  ONLINE       0     0     0
            ata-SAMSUNG_SSD_1TB_A   ONLINE       0     0     0
            ata-SAMSUNG_SSD_1TB_B   ONLINE       0     0     0

errors: No known data errors

Значення: «ONLINE» і чистий scrub означають, що ви не боретесь із прихованими ретраями чи навантаженням resilver. Якщо ви бачите DEGRADED, resilvering або checksum errors, припиніть тонке налаштування продуктивності і спочатку виправте апаратні проблеми.

Рішення: Якщо будь-який vdev показує помилки або триває resilver, заплануйте усунення та перевірте продуктивність після стабілізації.

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

cr0x@server:~$ zfs list -o name,used,avail,refer,mountpoint tank
NAME   USED  AVAIL  REFER  MOUNTPOINT
tank   38.2T 2.1T   96K    /tank

Значення: ~95% заповнений (38.2T used, 2.1T avail) — це зона ризику для багатьох навантажень. Розміщення ускладнюється; фрагментація зростає.

Рішення: Якщо використання понад ~80–85% і продуктивність важлива, плануйте звільнення місця або розширення. Жоден параметр Samba не переможе фізику.

Завдання 3: Визначте dataset, який використовує SMB share, і виведіть ключові властивості

cr0x@server:~$ sudo zfs get -H -o property,value recordsize,compression,atime,sync,xattr,acltype,primarycache,logbias tank/shares/engineering
recordsize	1M
compression	lz4
atime	on
sync	standard
xattr	sa
acltype	posixacl
primarycache	all
logbias	latency

Значення: У вас recordsize 1M (добре для великих послідовних файлів, ризиковано для часткових перезаписів), atime увімкнено (додаткові записи метаданих), sync standard (sync шанується), xattr у SA (часто добре), logbias latency (віддає перевагу SLOG якщо є).

Рішення: Якщо шар — «багато дрібних файлів», розгляньте recordsize=128K і atime=off. Якщо це образи ВМ, інша стратегія потрібна (ймовірно не через SMB).

Завдання 4: Виміряйте I/O-латентність пулу під час копіювання (істина в iostat)

cr0x@server:~$ sudo zpool iostat -v tank 1 5
                              capacity     operations     bandwidth
pool                        alloc   free   read  write   read  write
--------------------------  -----  -----  -----  -----  -----  -----
tank                        38.2T  2.1T     12   2400   3.1M   210M
  mirror-0                  38.2T  2.1T     12   2400   3.1M   210M
    ata-SAMSUNG_SSD_1TB_A      -      -      6   1250   1.6M   108M
    ata-SAMSUNG_SSD_1TB_B      -      -      6   1150   1.5M   102M
--------------------------  -----  -----  -----  -----  -----  -----

Значення: Висока кількість операцій запису (2400/s) з помірною пропускною спроможністю вказує на дрібні записи або sync-важке навантаження. Якщо пропускна здатність низька, але ops високі, ви обмежені IOPS або flush-путтям.

Рішення: Якщо записи дрібні й часті, дослідіть синхронні семантики, навантаження на метадані та невідповідність recordsize. Якщо ops низькі і пропускна здатність низька — підозрюйте мережу або обмеження SMB.

Завдання 5: Спостерігайте латентність по vdev через iostat (await — як сигнал тривоги)

cr0x@server:~$ sudo iostat -x 1 3
Linux 6.6.15 (server) 	12/25/2025 	_x86_64_	(16 CPU)

Device            r/s     w/s   rkB/s   wkB/s  avgrq-sz avgqu-sz   await  r_await  w_await  svctm  %util
nvme0n1           2.0   950.0    64.0 118000.0   248.0     3.20    3.4     1.2      3.4    0.6   58.0
nvme1n1           1.0   910.0    32.0 112000.0   246.0     3.05    3.3     1.1      3.3    0.6   55.0

Значення: ~3.3ms write await — це нормально для NVMe. Якщо під час копій ви бачите десятки/сотні ms, зберігання обмежує вашу пропускну здатність.

Рішення: Високий await + низький CPU + чиста мережа = проблема шляху зберігання (sync-записи, заповнений пул, повільні vdev або проблеми з SLOG).

Завдання 6: Перевірте, чи взагалі є у вас SLOG (і чи він щось робить)

cr0x@server:~$ sudo zpool status tank | sed -n '1,120p'
  pool: tank
 state: ONLINE
config:

        NAME                         STATE     READ WRITE CKSUM
        tank                         ONLINE       0     0     0
          mirror-0                   ONLINE       0     0     0
            ata-SAMSUNG_SSD_1TB_A    ONLINE       0     0     0
            ata-SAMSUNG_SSD_1TB_B    ONLINE       0     0     0
        logs
          nvme-SLOG_INTEL_OPTANE     ONLINE       0     0     0

Значення: Є окремий лог-пристрій. Добре. Але наявність не означає продуктивність; пристрій має бути швидким і захищеним від втрати живлення.

Рішення: Якщо існують sync-важкі навантаження і SLOG відсутній, вирішіть, чи потрібна вам семантика sync. Якщо так — додайте відповідний SLOG. Якщо ні — не підмінюйте це sync=disabled, якщо ви не готові втрачати підтверджені дані при відключенні живлення.

Завдання 7: Спостерігайте TXG-тротлінг і поведінку «брудних» даних

cr0x@server:~$ sudo arcstat 1 3
    time  read  miss  miss%  dmis  dm%  pmis  pm%  mmis  mm%  arcsz     c  avail
12:10:01   320    12      4     1    0    11    3     0    0   84.2G  96.0G  21.4G
12:10:02   410    16      3     2    0    14    3     0    0   84.2G  96.0G  21.4G
12:10:03   390    10      2     1    0     9    2     0    0   84.2G  96.0G  21.4G

Значення: ARC не має суттєвих промахів; кешування не є вашим поточним обмеженням. Якщо ARC малий відносно пам’яті або промахи стрімко зростають, можливо ви обмежені пам’яттю або маєте неправильні налаштування.

Рішення: Якщо під час читань промахи ARC високі, налаштуйте розмір пам’яті/ARC або набір робочих даних (або прийміть, що навантаження не кешується добре).

Завдання 8: Підтвердіть версію Samba і чи погоджується SMB3

cr0x@server:~$ smbd -V
Version 4.19.5-Debian

cr0x@server:~$ sudo smbstatus -b | sed -n '1,60p'
Samba version 4.19.5-Debian
PID     Username     Group        Machine                                   Protocol Version  Encryption           Signing
-------------------------------------------------------------------------------------------------------------------------
23144   user1        domain users  10.10.20.55 (ipv4:10.10.20.55:53122)     SMB3_11           -                    partial

Значення: SMB3_11 погоджено, це добре. Signing показано «partial» (залежить від конфігурації і клієнта). Якщо ви бачите SMB1 — у вас проблеми більші, ніж налаштування.

Рішення: Якщо виявлено SMB1, вимкніть його і усуньте сумісність клієнтів усвідомлено. Не тримайте SMB1 «через один старий сканер». Замініть сканер або ізолюйте його.

Завдання 9: Перевірте конфіг Samba на наявність «вбивць» sync (strict sync, sync always)

cr0x@server:~$ sudo testparm -sv | sed -n '/^\[engineering\]/,/^\[/{p}'
[engineering]
	path = /tank/shares/engineering
	read only = No
	vfs objects = acl_xattr
	strict sync = Yes
	sync always = No

Значення: strict sync = Yes змушує Samba виконувати більше flush-ів. Це класичне налаштування «ми ввімкнули його для безпеки», яке може знищити пропускну здатність.

Рішення: Якщо у вас немає суворої вимоги відповідності, виставте strict sync = No і перевірте коректність додатків. Якщо потреба є — інвестуйте в SLOG і низьколатентне зберігання.

Завдання 10: Перевірте, чи увімкнено SMB signing/encryption і чи є CPU-обмеження

cr0x@server:~$ sudo smbstatus -b | awk 'NR==1 || NR==2 || $0 ~ /SMB3/'
Samba version 4.19.5-Debian
PID     Username     Group        Machine                                   Protocol Version  Encryption           Signing
23144   user1        domain users  10.10.20.55 (ipv4:10.10.20.55:53122)     SMB3_11           AES-128-GCM          mandatory

cr0x@server:~$ top -b -n 1 | sed -n '1,20p'
top - 12:12:41 up 34 days,  3:01,  2 users,  load average: 9.12, 8.40, 7.95
Tasks: 291 total,   2 running, 289 sleeping,   0 stopped,   0 zombie
%Cpu(s): 12.1 us,  2.0 sy,  0.0 ni, 78.0 id,  0.0 wa,  0.0 hi,  7.9 si,  0.0 st
MiB Mem :  256000.0 total,  21000.0 free,  95000.0 used, 140000.0 buff/cache

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

Рішення: Якщо encryption/signing обов’язкові і CPU гарячий — оновіть CPU, використовуйте системи з AES-NI, налаштуйте RSS і multiqueue, або звузьте шифрування до конкретних чутливих шарів.

Завдання 11: Перевірте лінк NIC, дуплекс та лічильники помилок (дешеві перевірки, дорогі наслідки)

cr0x@server:~$ ip -s link show dev bond0
2: bond0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000 qdisc noqueue state UP mode DEFAULT group default qlen 1000
    link/ether 9c:dc:71:aa:bb:cc brd ff:ff:ff:ff:ff:ff
    RX:  bytes packets errors dropped  missed   mcast
    1223344556677 1023344556      0       0       0  120034
    TX:  bytes packets errors dropped carrier collsns
    1334455667788 1124455667      0       0       0       0

cr0x@server:~$ ethtool bond0 | sed -n '1,25p'
Settings for bond0:
	Supported ports: [ ]
	Supported link modes:   Not reported
	Speed: 20000Mb/s
	Duplex: Full
	Auto-negotiation: off

Значення: Немає помилок, повний дуплекс, очікувана швидкість. Якщо ви бачите помилки або дропи — виправляйте мережу перш ніж чіпати ZFS.

Рішення: Якщо є помилки: перевірте кабелі, порти комутатора, узгодженість MTU та налаштування offload. Налаштування продуктивності поверх втрат пакетів — це театр.

Завдання 12: Перевірте повторні передачі TCP та тиск на сокети (SMB над хворою мережею — ілюзія)

cr0x@server:~$ ss -s
Total: 884
TCP:   211 (estab 104, closed 72, orphaned 0, timewait 72)

Transport Total     IP        IPv6
RAW	  0         0         0
UDP	  11        8         3
TCP	  139       113       26
INET	  150       121       29
FRAG	  0         0         0

cr0x@server:~$ netstat -s | sed -n '1,80p'
Tcp:
    154239 active connection openings
    149802 passive connection openings
    1124 failed connection attempts
    1821 connection resets received
    0 connections established
    224159 segments received
    231008 segments sent out
    214 segments retransmitted

Значення: Повторні передачі є, але не у величезній кількості. Якщо під час копій retransmits зростають, ви побачите паузи, що не пов’язані зі зберіганням. SMB чутливий до стрибків латентності.

Рішення: Високі retransmits: перевірте буфери комутатора, невідповідність MTU, драйвер/прошивку NIC або перевантажений шлях через фаєрвол.

Завдання 13: Визначте, чи навантаження sync-важке (серверний тест fsync)

cr0x@server:~$ sync; sudo bash -c 'time dd if=/dev/zero of=/tank/shares/engineering/.fsync-test bs=1M count=256 conv=fdatasync status=none'
real	0m1.92s
user	0m0.00s
sys	0m0.28s

cr0x@server:~$ sudo rm -f /tank/shares/engineering/.fsync-test

Значення: Це вимірює «запис, а потім примусове забезпечення надійності». Якщо це повільно (наприклад, 10–60s), ваш пул не може швидко комітити sync-записи для SMB-навантажень, які їх вимагають.

Рішення: Повільний fsync: додайте/перевірте SLOG, зменшіть кількість примусових sync у Samba, якщо це прийнятно, або переробіть зберігання для низьколатентних записів.

Завдання 14: Переконайтеся, що dataset випадково не змушує sync вимкненим (або увімкненим) там, де ви не планували

cr0x@server:~$ sudo zfs get -H -o name,property,value sync tank/shares/engineering tank/shares/finance
tank/shares/engineering	sync	standard
tank/shares/finance	sync	always

Значення: Finance share має примусово встановлене sync=always. Це може бути свідомо (додатки потребують надійності) або помилкова конфігурація, що робить його повільним.

Рішення: Якщо знайдено sync=always, уточніть у власників додатків причини. Якщо ніхто не може обґрунтувати — поверніть на standard і протестуйте.

Завдання 15: Перевірте стиснення ZFS і реальне співвідношення (бо «ми увімкнули стиснення» ≠ «воно працює»)

cr0x@server:~$ zfs get -H -o name,property,value compression,compressratio tank/shares/engineering
tank/shares/engineering	compression	lz4
tank/shares/engineering	compressratio	1.62x

Значення: 1.62x означає, що ви економите I/O і місце. Якщо ratio ~1.00x, стиснення мало допомагає, але звичайно LZ4 не шкодить.

Рішення: Тримайте LZ4 за замовчуванням. Відключайте лише якщо виміряли насичення CPU і дані майже не піддаються стисненню.

Завдання 16: Пошукайте патологічну фрагментацію (особливо якщо пул старий і майже повний)

cr0x@server:~$ sudo zdb -bbbs tank | sed -n '1,40p'
Block Size Histogram:
 512: 0
 1K : 0
 2K : 1048576
 4K : 2097152
 8K : 1048576
 16K: 524288
 32K: 262144
 64K: 131072
 128K: 65536
 256K: 32768
 512K: 16384
 1M : 8192

Значення: Це грубий огляд; на практиці ви звʼяжете фрагментацію з поведінкою розміщення і латентністю. Велике різноманіття дрібних блоків у dataset, призначеному для великих послідовних записів, може бути підказкою.

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

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

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

У них був новий ZFS-файловий сервер і два uplink по 10GbE. Розгортання виглядало добре перший тиждень, переважно тому, що тест був «скопіювати 20GB ISO один раз», і всі пішли додому задоволені.

Потім настав кінець кварталу. Фінанси завантажили тисячі дрібних PDF і таблиць у шар з Windows-додатку, який вимагав write-through. Користувачі повідомили, що копії «зависають кожні кілька секунд». Мережа не бачила насичення, тому її визнали вільною від вини. Команда зберігання бачила багато вільної RAM і гадала, що ARC все вирівняє. Але ні.

Хибне припущення було тонким: «Якщо пул може робити 1GB/s послідовних записів, він може робити офісні копії». Це різні види навантаження. Послідовна пропускна спроможність — це парадний заїзд; sync-важкі метадані — це смуга перешкод.

Коли хтось запустив простий тест dd ... conv=fdatasync на dataset, стало очевидно. Латентність коміту sync була вузьким місцем. Пул був RAIDZ на HDD. Чудово для ємності, жахливо для низьколатентних записів.

Виправлення теж було делікатним: вони не вимикали sync. Додали якісний SLOG з захистом від втрати живлення і прибрали strict sync з шарів, які цього не вимагали. Фінанси зберегли свої гарантії, інженери повернули швидкість. Тікети служби підтримки припинилися — це єдина KPI, що справді має значення, коли ти на чергуванні.

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

Інша компанія мала повільні копії домашніх директорій. Хтось прочитав форум і вирішив «більший recordsize — значить швидше». Тому вони виставили recordsize=1M для всіх SMB dataset, включно з домашніми та проектними деревами.

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

Чому? Часткові перезаписи великих блоків можуть створити write amplification. Невелика зміна в файлі може викликати read-modify-write великого блоку, особливо коли навантаження випадкове і додаток робить багато дрібних оновлень. ZFS — copy-on-write, тож і так веде детальний облік; додаткова ампліфікація — це як просити його жонглювати на біговій доріжці.

Невдала «оптимізація» також збільшила навантаження на метадані, бо профілі користувачів генерують купу дрібних файлів і атрибутних оновлень. Більший recordsize не допоміг у шляху метаданих; він лише зробив шлях даних менш дружнім.

Відкат був дисциплінований: вони розділили dataset за робочим навантаженням. Домашні директорії отримали 128K recordsize, atime off. Великі архіви залишилися на 1M. Продуктивність стабілізувалась. Урок закарбувався: налаштування — не шведський стіл, де можна все навантажити.

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

Команда, що керувала ZFS + Samba кластером, мала одну непримітну звичку: щотижневі звіти scrub і щомісячні базові знімки продуктивності. Не панелі для керівництва. Просто текстовий файл з zpool status, zpool iostat під навантаженням і базові лічильники помилок NIC.

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

Оскільки були історичні дані, вони не витратили півдня на суперечки про прапори Samba. Вони замінили диск у вікні технічного обслуговування, зробили resilver, і затримки копій зникли.

Нічого героїчного. Жодних магічних налаштувань. Просто помічати, що «регрес продуктивності» часто означає «апарат старіє повільно». Ось як виглядає нудна компетентність у продакшені.

Рішення з налаштування, які справді дають ефект

1) Визначте свою позицію щодо sync явно (не дозволяйте цьому статися випадково)

SMB-навантаження можуть бути sync-важкими, особливо з певними додатками і політиками. У вас є три варіанти:

• Шанувати sync і платити за це: тримайте sync=standard, уникайте налаштувань Samba, які примушують додаткові flush, і розгорніть реальний SLOG, якщо потрібен.
• Примусово sync завжди: sync=always для шарів з вимогами відповідності. Очікуйте нижчу пропускну спроможність; проектуйте зберігання відповідно.
• Вимкнути sync: sync=disabled — бізнес-рішення, щоб ризикувати втратою підтверджених записів при відключенні живлення або збої. Це може бути прийнятно для тимчасових шарів, але не видавайте це за «безкоштовну продуктивність». Це інша угода щодо надійності.

2) Розділіть dataset за навантаженням (один шар — одна поведінка)

Один dataset для всього — найшвидший спосіб переконатися, що нічого не буде добре. Розділіть:

• Домашні директорії (метадані-важкі, дрібні файли)
• Інженерні проектні дерева (багато дрібних файлів, переважно для читання)
• Медіа-архіви (великі послідовні файли)
• Зони доставки додатків (можуть вимагати суворої надійності)

Потім задайте властивості на dataset: recordsize, atime, sync, стиснення, поведінка ACL.

3) Підібрати recordsize «достатньо правильно»

• Загальні SMB-шари: почніть з recordsize=128K.
• Архіви великих файлів: розгляньте recordsize=1M, якщо більшість файлів великі і послідовні.
• Бази даних/образи ВМ поверх SMB: уникайте цього, якщо можете; якщо ні — використовуйте спеціальні налаштування і ретельно тестуйте. SMB-файлообслуговування і datastore для ВМ — не випадкове поєднання.

4) Вимкніть atime для SMB-шарів (якщо немає реальної потреби)

atime=on додає записи метаданих при читанні. Більшість організацій не використовують час доступу для чогось суттєвого, і Windows точно не потребує, щоб ваш ZFS-сервер писав додаткові метадані щоразу при відкритті файлу.

5) Тримайте LZ4 стиснення за замовчуванням

LZ4 — одне з небагатьох «дефолтних» налаштувань, яке я захищаю в продакшені. Воно часто підвищує ефективну пропускну здатність і зменшує I/O. Не ускладнюйте до доказу з насичення CPU.

6) Використовуйте реальний SLOG, коли він потрібен (і не економте)

SLOG-пристрій — це не «будь-який SSD». Він має мати низьку латентність під sync-навантаженням і захист від втрати живлення. Інакше ви побудували дорогий генератор латентності.

7) Samba: уникайте «strict sync», якщо не можете його обґрунтувати

strict sync може знищити пропускну спроможність для навантажень, що генерують багато fsync-пунктів (включно з певною поведінкою Windows при закритті файлів). Якщо вам потрібна сувора семантика — зробіть зберігання здатним її підтримувати. Якщо ні — не платіть за це.

8) SMB signing/encryption: сфокусуйте застосування

Команди безпеки люблять загальні політики. Продукційні системи люблять бюджети. Якщо підпис/шифрування обов’язкові, переконайтеся, що хост SMB має запас CPU і сучасне апаратне прискорення криптооперацій. Якщо тільки певні шари містять чутливі дані — обмежуйте політики на рівні шару або трафіку.

Жарт №2: Нічого не робить файловий сервер швидшим так, як політичне засідання, що закінчилося словами «ми нічого не змінювали».

Типові помилки: симптом → корінь проблеми → фікс

1) Симптом: Копія починається швидко, потім падає до 0 B/s повторно

Корінь проблеми: TXG commit stalls через sync-записи або повільну латентність flush (немає SLOG, повільні vdev, пул занадто заповнений).

Виправлення: Виміряйте fsync (dd ... conv=fdatasync), перевірте налаштування Samba щодо sync, додайте якісний SLOG або переробіть пул для низької латентності, звільніть місце.

2) Симптом: Великі файли копіюються нормально; багато дрібних файлів повзають

Корінь проблеми: Навантаження, що залежить від метаданих (ACL, xattr, timestamps) плюс обмеження дрібних випадкових I/O.

Виправлення: atime=off, переконайтеся у відповідних властивостях dataset, розгляньте зеркала для пулів з високими вимогами метаданих, перевірте, чи VFS-модулі Samba не додають накладних витрат; прийміть, що це IOPS, а не bandwidth.

3) Симптом: Швидкість обмежується приблизно ~110 MB/s на «10GbE»

Корінь проблеми: Клієнт/сервер погодили 1GbE, неправильне хешування LACP або один TCP-потік без multichannel.

Виправлення: Перевірте швидкість лінку через ethtool, перевірте конфіг switch, протестуйте SMB multichannel і переконайтеся, що клієнт не знаходиться в сегменті 1GbE.

4) Симптом: Продуктивність гірша після увімкнення SMB signing або encryption

Корінь проблеми: CPU-обмеження в крипто/підписі, одномодульні «гарячі» місця, недостатні RSS-черги.

Виправлення: Виміряйте завантаження CPU по ядрах під час передачі, увімкніть multiqueue/RSS, оновіть CPU, звужуйте зону застосування signing/encryption або використайте обладнання з прискоренням.

5) Симптом: Копії час від часу зависають «саме на кілька секунд»

Корінь проблеми: Повторні передачі в мережі, bufferbloat або конгестія комутатора; іноді часи TXG збігаються з паузами.

Виправлення: Перегляньте retransmits (netstat -s), дропи інтерфейсу і лічильники комутатора. Якщо чисто — поверніться до перевірки латентності зберігання та sync.

6) Симптом: Один шар повільний; інший на тому ж сервері ок

Корінь проблеми: Різниця властивостей dataset (sync=always, дивний recordsize, atime on), відмінності в конфігурації Samba (strict sync, VFS-модулі) або квоти/резервування, що впливають на розміщення.

Виправлення: Порівняйте виходи zfs get і блоки testparm -sv для обох шарів. Нормалізуйте усвідомлено.

7) Симптом: «Windows каже, що потрібно 2 години», але сервер виглядає простою

Корінь проблеми: Сканування на стороні клієнта (антивірус, індексація), накладні витрати на дрібні файли або клієнт чекає на кожну операцію метаданих.

Виправлення: Відтворіть на чистому клієнті, протестуйте robocopy з опціями і перевірте метрики сервера під час операції. Не налаштовуйте сервери, щоб компенсувати проблемні кінцеві точки.

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

Покроково: виправлення «швидко, потім нуль» SMB-копій на ZFS

1. Підтвердіть стан пулу: zpool status -v. Якщо degraded або помилки — зупиніться і виправте диски.
2. Перевірте заповненість пулу: zfs list. Якщо >85% використано — плануйте очищення/розширення.
3. Визначте dataset і властивості: zfs get recordsize,atime,sync,compression.
4. Перегляньте конфіг Samba: testparm -sv на предмет strict sync, aio та VFS-модулів.
5. Виміряйте sync-латентність: серверний dd ... conv=fdatasync. Якщо повільно — це головний підозрюваний.
6. Перевірте наявність/продуктивність SLOG: zpool status для логів і впевніться, що клас пристрою відповідний.
7. Спостерігайте латентність дисків під навантаженням: iostat -x і zpool iostat під час відтворення.
8. Перевірте здоровʼя мережі: ip -s link, retransmits (netstat -s) і швидкість лінку (ethtool).
9. Застосовуйте по одній зміні: наприклад, відключіть strict sync на тестовому шарі або додайте SLOG; потім повторіть ту саму передачу і порівняйте.
10. Запишіть результат: зніміть латентність, пропускну здатність і чи зникли паузи. Памʼять тьмяніє; тикети — ні.

Базовий контрольний список (нудні речі, за які ви подякуєте собі)

• Щотижневий scrub запланований; звіти scrub переглядаються.
• Щомісячний знімок: zpool status, ключові властивості zfs get, ip -s link і повторюваний тест throughput + fsync.
• Макет dataset документований за категорією навантаження.
• Ясна політика щодо sync: які шари вимагають гарантій надійності.
• Контроль змін для конфігурації Samba; без «однорядкових фіксів» у продакшені о 2-й ночі.

ЧаПи

1) Чому Windows Explorer показує швидку швидкість, а потім 0 B/s?

Explorer показує на основі буферизації та короткочасного прийому. ZFS і Samba можуть швидко прийняти дані, а потім призупинитися під час коміту sync-записів або TXG. Вимірюйте латентність на сервері.

2) Чи robocopy швидший за Explorer?

Іноді. Велика перевага в тому, що robocopy передбачуваніший і скриптуємий, та показує повторні спроби і поведінку по файлах. Він не вирішить синхронну латентність на сервері.

3) Чи варто ставити sync=disabled, щоб прискорити?

Тільки якщо ви готові ризикнути втратити підтверджені записи при відключенні живлення або збою. Для тимчасових шарів це може бути прийнятно. Для бізнес-даних — це зниження надійності, а не трюк налаштування.

4) Чи потрібен мені SLOG для SMB?

Якщо ваше навантаження генерує багато sync-записів (або налаштування Samba примушують суворе флешування), хороший SLOG може кардинально змінити ситуацію. Якщо навантаження переважно async — SLOG мало допоможе.

5) Який recordsize слід використовувати для SMB-шарів?

Починайте з 128K для загального призначення. Використовуйте 1M для великих послідовних архівів. Уникайте глобальних змін; розділяйте dataset за навантаженням.

6) Чи ввімкнення LZ4 сповільнить роботу?

Зазвичай ні, і часто воно пришвидшує роботу, зменшуючи I/O. Якщо CPU вже завантажений (шифрування/підпис, важке навантаження), виміряйте перед прийняттям рішення.

7) Чи RAIDZ поганий для SMB?

Не «поганий», але RAIDZ менш дружній до дрібних випадкових записів і метаданих-важких навантажень, ніж mirror. Якщо ваш SMB-випадок — багато дрібних файлів і sync-поведінка, mirrored vdev часто виграють по латентності.

8) Чому один SMB-шар повільний, а інші — ок?

Різні властивості dataset або опції Samba. Шукайте sync=always, atime=on, дивний recordsize або strict sync лише на одному шарі.

9) Чи SMB Multichannel вирішує все?

Ні. Воно може підвищити пропускну здатність і стійкість, але не виправить латентність зберігання або sync-паузи. Також вимагає коректних NIC, драйверів і підтримки на клієнті.

10) Як зрозуміти, що проблема в CPU?

Під час передачі одне або кілька ядер будуть постійно завантажені, часто в smbd або ядровому networking/crypto. Тим часом диски і NIC не будуть насичені. Це ваш знак.

Наступні кроки на цей тиждень

Виконайте ці кроки у порядку. Кожен крок робить рішення очевиднішим, і жоден не вимагає віри.

1. Виберіть один відтворюваний тест трансфер (один великий файл і одна папка «багато дрібних файлів») і тримайте його постійним.
2. Запустіть швидкий план діагностики і збережіть виводи: zpool iostat, iostat -x, ip -s link, netstat -s, smbstatus.
3. Доведіть або виключіть синхронну латентність за допомогою серверного тесту dd ... conv=fdatasync на dataset.
4. Розділіть dataset за навантаженням, якщо ще не зроблено. Встановіть atime=off і розумні recordsize для кожної категорії.
5. Виправте реальне вузьке місце: додайте якісний SLOG для sync-важких шарів, звільніть місце якщо пул занадто повний, або розвʼяжіть CPU/мережеві проблеми якщо саме вони — джерело.
6. Напишіть односторінковий ранбуk з базовими командами і «нормальними» виводами. Майбутнє ви купить каву минулому вам.

Мета не в ідеальному графіку. Мета — передбачувана продуктивність в межах контракту на надійність, який ви справді хочете надавати. Коли ви свідомо обираєте цей контракт, ZFS і SMB перестають бути містичними і стають… просто вимогливими.

Чому процесори змінилися: фізика, гроші і кінець «просто зменшіть техпроцес»

Десятиліттями прогрес CPU можна було сприймати як передбачувану підписку: кожне покоління ставало густішим, швидшим і (переважно) дешевшим за одиницю обчислень. Та ця ера не закінчилась драматичним пресрелізом. Вона завершилася тисячею малих компромісів — витік струму, вартість літографії, варіативність та незручний факт, що дроти не масштабуются так само, як транзистори.

Коли ви чуєте «чиплети» та «3D-стекінг», не перекладайте це як «хитра інженерія». Перекладайте як: старі економічні й фізичні припущення зламалися, тож пакування стало новою архітектурою. Інновації переміщуються зсередини кристалу у взаємодію між кристалами.

Факти й історичний контекст (те, що дійсно допомагає міркувати)

• Факт 1: Dennard scaling (стабільна густина потужності при зменшенні транзисторів) фактично зупинилася в середині 2000-х, що змусило частотний ріст заякоритись і підштовхнуло до мультикорних дизайнів.
• Факт 2: Затримка міжз’єднань уже кілька років є першорядним вузьким місцем; внутрішні дроти не стають пропорційно швидшими з кожним вузлом, тож «більшою пластинкою» означає більше часу на переміщення бітів.
• Факт 3: Ліміти ретиклу обмежують, наскільки великим може бути одне експонування літографії; дуже великі кристали стають кошмаром за виходом придатних виробів, якщо їх не розбивати або не зшивати.
• Факт 4: Індустрія давно використовує мульти-чіп модулі (згадайте: ранні пакети з двома кристалами, серверні модулі), але сьогоднішні чиплети значно стандартизованіші й критичніші за продуктивність.
• Факт 5: High Bandwidth Memory (HBM) стала практичною завдяки стекуванню DRAM-чіпів і з’єднанню їх TSV; це показало, що вертикальна інтеграція може перевершити традиційну пропускну здатність DIMM.
• Факт 6: 3D-стекування кешу в мейнстримних CPU показало дуже конкретний урок: додавання SRAM вертикально може підвищити продуктивність без збільшення найбільш гарячого логічного кристала.
• Факт 7: Гетерогенні ядра (концепти big/little) існували в мобільних пристроях роками; тепер вони поширені в серверах, бо пропускна здатність і теплові обмеження, а не пікова частота, визначають пропускну спроможність.
• Факт 8: Складні пакувальні технології (2.5D інтерпозери, силіконові мости, fan-out) тепер є конкурентною відмінністю, а не лише деталлю бекенду виробництва.

Операційний висновок: наступні 10–15% приросту продуктивності менш ймовірно прийдуть від нових інструкцій, і більш ймовірно — від кращої локальності, розумніших ієрархій пам’яті та більш щільних зв’язків між кристалами. Якщо ваше навантаження чутливе до варіації латентності, треба ставитися до пакування і топології так само, як до маршрутизації в мережі.

Чиплети, міжз’єднання і чому «сокет» більше не означає те, що ви думаєте

Чиплет CPU — це пакет, що містить кілька кристалів, кожен із яких спеціалізується на чомусь: ядра, кеш, контролери пам’яті, IO, акселератори, іноді навіть процесори безпеки. Сам пакет — це продукт. «CPU» більше не є одною плитою; це невелика розподілена система під тепловим розподільником.

Чиплети існують з трьох прямих причин:

1. Вихід придатних виробів (yield): менші кристали мають кращий вихід; дефекти не вбивають весь величезний кристал.
2. Комбінація технологічних вузлів: швидка логіка на передовому вузлі, IO на дешевшому, зрілому вузлі.
3. Продуктова гнучкість: повторно використовувати відпрацьований IO-кристал у кількох SKU; варіювати кількість ядер і кеш-тайлів без повної переробки.

Міжз’єднання — тепер архітектура

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

Сучасні пакети використовують власні fabric-рішення, і галузь рухається в бік інтероперабельних стандартів die-to-die, наприклад UCIe. Ключова думка не в абревіатурі. Важливо, що зв’язки між кристалами обслуговуються як високошвидкісний IO: серіалізовані, синхронізовані, керовані по живленню, треновані, іноді з повторними спробами. Отже, стан лінку, лічильники помилок і стани живлення можуть впливати на продуктивність у способи, що здаються «випадковими», якщо їх не вимірювати.

Жарт №1: Чиплети — як мікросервіси: усім подобається гнучкість, поки не треба дебажити затримки через межі, які ви спеціально створили.

NUMA не був новим. Ви просто перестали його поважати.

Чиплетні CPU перетворюють кожен сервер на більш нюансовану NUMA машину. Іноді «NUMA-вузли» відповідають контролерам пам’яті; іноді — комплексам ядер; іноді — обом. У будь-якому випадку локальність важлива: яке ядро звертається до якої пам’яті, який тайл останнього рівня кешу ближчий, і як часто ви перетинаєте міжз’єднання.

Якщо ваша стратегія продуктивності все ще починається і закінчується «додайте ядра» і «запиніть потоки», ви натрапите на нову стіну: переповнення міжз’єднання і конкуренція в ієрархії пам’яті. Пакет CPU тепер має внутрішні трафік-патерни, і ваше навантаження може створювати «гарячі точки».

3D-стекінг: вертикальна пропускна здатність, вертикальні проблеми

3D-стекінг — це використання кількох кристалів, складених вертикально з щільними з’єднаннями (часто TSV, мікро-бампси або гібридне бондування). Його застосовують для кешу, DRAM (HBM) і все частіше для логіки-на-логиці.

Навіщо стекувати?

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

Але нічого не дається просто так. 3D-стекінг вводить неприємний операційний трикутник: термальність, вихід придатних виробів (yield) і надійність.

Стекований кеш: чому це працює

Стекований SRAM над обчислювальним кристалом дає великий кеш останнього рівня, не роблячи обчислювальний кристал гігантом. Це може бути величезною перевагою для навантажень зі робочими наборами трохи більшими за традиційні розміри кешу: багато ігор, деякі EDA-потоки, певні in-memory БД, key-value сховища з “гарячими” ключами та аналітичні конвеєри з повторними сканами.

З операційної точки зору стекований кеш змінює дві речі:

1. Продуктивність стає більш бімодальною. Якщо ваше навантаження вміщується в кеш — ви герой. Якщо ні — ви повертаєтесь до DRAM і виграш зникає.
2. Тепловий резерв стає цінним. Додатковий кремній над обчислювальним кристалом впливає на тепловий потік; поведінка turbo і стійкі частоти може змінитися так, що це виявиться як варіація латентності.

HBM: чит-код пропускної здатності з цінником

HBM стекує DRAM-чіпи і розміщує їх близько до обчислювального кристала (часто через інтерпозер). Це дає величезну пропускну здатність у порівнянні з традиційними DIMM, але є обмеження по ємності на стек і висока вартість. Це також змінює режими відмов і спостережуваність: помилки пам’яті можуть проявлятися інакше, і планування ємності стає іншим видом спорту.

3D і 2.5D пакування також нав’язують нове правило проєктування: ваше програмне забезпечення має розуміти рівні. HBM проти DDR, близька пам’ять проти далекої, кеш-на-пакеті проти кеш-на-кристалі. «Просто аллоцювати пам’ять» стає рішенням щодо продуктивності.

Жарт №2: Стекувати кристали — чудово, поки ви не згадаєте, що тепло теж стекується, і на відміну від списку завдань його не можна відкласти.

Справжній ворог: байти, а не FLOPS

Більшість продакшн-систем не обмежені сирою арифметичною пропускною здатністю. Вони обмежені переміщенням даних: від пам’яті до кешу, від кешу до ядра, від ядра до NIC, від сховища до пам’яті і назад. Чиплети і 3D-стекінг — це визнання індустрією того, що пам’ять і міжз’єднання — це головна дія.

Тут інстинкти SRE допомагають. Коли пакет CPU стає фабрикою, вузькі місця виглядають як:

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

Що змінюється з чиплетами і стекуванням

Локальність пам’яті більше не опціональна. На великому монолітному кристалі «віддалений» доступ усе ще може бути досить швидким. У чиплетах віддалений доступ може проходити через hops fabric і конкурувати з іншим трафіком. На SKU зі стекованим кешом «локальний» кеш може бути більший, але штраф за промах може бути більш помітним через змінену частоту/теплову поведінку.

Пропускна здатність не була однорідною. Деякі кристали мають ближчий доступ до певних контролерів пам’яті. Деякі ядра тісніше діляться певними кеш-тайлами. Топологія може винагороджувати хороше планування і карати наївне розміщення.

Варіація латентності стає нормою. Стани управління живленням, відсікання годин fabric і алгоритми бусту можуть змінювати внутрішні латентності. Ваш p99 помітить це раніше, ніж середні величини.

Теплові режими і енергоспоживання: пакет — нове поле битви

На папері ви купуєте CPU з TDP і частотою boost і вважаєте, що це кінець історії. Насправді сучасні CPU — це системи з управлінням енергією, які постійно домовляються про частоти на основі температури, струму й характеристик навантаження. Чиплети й 3D-стеки ускладнюють ці домовленості.

Гарячі точки і теплові градієнти

З чиплетами у вас немає одного однорідного теплового профілю. Є гарячі точки, де ядра щільні, окремі IO-кристали, які працюють прохолодніше, і іноді стековані кристали, що перешкоджають відведенню тепла від обчислювального кристала знизу. У довготривалих продакшн-навантаженнях стійкі частоти важливіші за пікові бусти.

Дві операційні наслідки:

• Бенчмарки частіше брешуть. Короткі бенчмарки ловлять boost; продакшн ловить steady-state і ліміти потужності.
• Охолодження — це продуктивність. Маргінальне охолодження або проблеми з повітряним потоком не лише спричинять тротлінг; вони спричинять варіацію, яку важче діагностувати.

Надійність: більше з’єднань — більше місць для проблем

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

Корисний операційний афоризм, переказ ідеї відомого голосу в надійності: Складні системи виходять з ладу складними способами; зменшуйте невідомі і вимірюйте потрібні речі. (парафраз ідеї, натхненної підходами інженерії надійності)

Переклад: не припускайте однорідності між хостами і не припускайте, що два сокети поводяться однаково лише через те, що SKU співпадає.

Що це означає для SRE: продуктивність, надійність і шумні сусіди

Вам не потрібно ставати інженером пакування. Але потрібно припинити сприймати «CPU» як один скалярний ресурс. У світі чиплетів і стеків ви керуєте:

• Топологічними обчисленнями (ядра не однакової відстані від пам’яті і кешу)
• Пропускною здатністю міжз’єднання (внутрішній fabric може насичуватися)
• Тепловим резервом (стійкі частоти, тротлінг і p99)
• Політикою енергоспоживання (ліміти, turbo і взаємодія з планувальником)

Спостережуваність повинна розширитися

Традиційний моніторинг хостів — CPU%, load average, пам’ять у використанні — дедалі частіше не пояснюватиме вузькі місця. Вам потрібен мінімум базового розуміння:

• NUMA локальність (чи вирівняні потоки й пам’ять?)
• Поведіна кешу (LLC misses, тиск на пропускну здатність)
• Частота й тротлінг (чи обмежені ви потужністю?)
• Розміщення планувальника (чи Kubernetes або systemd не перемістили ваше навантаження по вузлах?)

І так, це дратує. Але це менше дратує, ніж квартал апгрейдів CPU з очікуванням прискорення і отримання уповільнення.

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

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

Перше: визначте, чи ви обмежені обчисленнями, пам’яттю чи «fabric»

1. Перевірте частоту CPU і тротлінг: якщо частоти низькі під навантаженням — ви обмежені потужністю/термально.
2. Перевірте пропускну здатність пам’яті і тиск промахів кешу: якщо LLC misses і пропускна здатність високі — ви обмежені пам’яттю.
3. Перевірте NUMA локальність: якщо віддалених звернень багато — ви, ймовірно, обмежені топологією/планувальником.

Друге: підтвердіть топологію і розміщення

1. Перевірте NUMA-вузли і відповідність CPU → вузлам.
2. Перевірте афінітет процесу до CPU і політику пам’яті.
3. Перевірте, чи навантаження не стрибає між вузлами (міграції планувальника).

Третє: ізолюйте одну змінну і повторіть

1. Зафіксуйте навантаження на одному NUMA-вузлі; порівняйте p95/p99.
2. Примусьте локальне виділення пам’яті; порівняйте пропускну здатність.
3. Застосуйте консервативну політику енергоспоживання; порівняйте варіацію.

Якщо ви не можете відтворити істотних змін, контролюючи розміщення і стани живлення, проблема ймовірно на вищому шарі (блокування, GC, IO), і не варто звинувачувати пакет CPU. Сучасні CPU складні, але не магічні.

Практичні завдання з командами: що запускати, що означає, що вирішувати

Ось реальні завдання, які можна виконати на Linux-хостах, щоб зрозуміти поведінку, пов’язану з чиплетами/3D-стекінгом. Команди навмисно нудні. Нудні інструменти тримають вас чесними.

Завдання 1: Швидко відобразіть NUMA-топологію

cr0x@server:~$ lscpu | egrep 'Model name|Socket|Thread|Core|NUMA|CPU\(s\)'
CPU(s):                               128
Model name:                           AMD EPYC 9xx4
Thread(s) per core:                   2
Core(s) per socket:                   64
Socket(s):                            1
NUMA node(s):                         8

Що означає вивід: У вас 8 NUMA-вузлів на одному сокеті. Це топологія, притаманна чиплетам: кілька доменів пам’яті і hops між ними в одному пакеті.

Рішення: Якщо латентність важлива, плануйте прив’язувати ключові сервіси в межах NUMA-вузла й тримати пам’ять локально. За замовчуванням планувальник може бути «достатній», але «достатній» — це те, як гине p99.

Завдання 2: Дивіться, які CPU належать яким NUMA-вузлам

cr0x@server:~$ numactl --hardware
available: 8 nodes (0-7)
node 0 cpus: 0-15
node 0 size: 64000 MB
node 0 free: 61234 MB
node 1 cpus: 16-31
node 1 size: 64000 MB
node 1 free: 60110 MB
node 2 cpus: 32-47
node 2 size: 64000 MB
node 2 free: 59872 MB
node 3 cpus: 48-63
node 3 size: 64000 MB
node 3 free: 62155 MB
node 4 cpus: 64-79
node 4 size: 64000 MB
node 4 free: 60990 MB
node 5 cpus: 80-95
node 5 size: 64000 MB
node 5 free: 61801 MB
node 6 cpus: 96-111
node 6 size: 64000 MB
node 6 free: 61644 MB
node 7 cpus: 112-127
node 7 size: 64000 MB
node 7 free: 62002 MB

Що означає вивід: Кожен NUMA-вузол володіє діапазоном CPU і частиною пам’яті. Якщо ваш процес працює на CPU вузла 0, але аллоцює пам’ять з вузла 6, він платитиме “фабричну” плату за кожен віддалений доступ.

Рішення: Для сервісів з чутливою латентністю вирівняйте CPU pinning і політику пам’яті. Для завдань на пропускну здатність можливо краще інтерлеювати пам’ять для більшої сумарної пропускної здатності.

Завдання 3: Перевірте, чи ядро записує проблеми NUMA-локальності

cr0x@server:~$ numastat -p 1 3
Per-node process memory usage (in MBs) for PID 1 (systemd)
Node 0 Node 1 Node 2 Node 3 Node 4 Node 5 Node 6 Node 7 Total
----- ----- ----- ----- ----- ----- ----- ----- -----
Numa_Hit      12     10      9      8      9     10      8      9    75
Numa_Miss      1      0      0      0      0      0      0      0     1
Numa_Foreign   0      0      0      0      0      0      0      0     0
Interleave_Hit 0      0      0      0      0      0      0      0     0
Local_Node    12     10      9      8      9     10      8      9    75
Other_Node     1      0      0      0      0      0      0      0     1

Що означає вивід: Для PID 1 усе в порядку. Для вашого реального сервісу, якщо Other_Node великий, ви платите за віддалені доступи.

Рішення: Якщо віддалених доступів багато і хвильова латентність висока — прив’язуйте й локалізуйте. Якщо мета — пропускна здатність і ви обмежені пам’яттю, розгляньте інтерливинг.

Завдання 4: Перевірте поведінку частоти CPU під навантаженням

cr0x@server:~$ sudo turbostat --Summary --quiet --show CPU,Avg_MHz,Busy%,Bzy_MHz,PkgTmp,PkgWatt --interval 5
CPU  Avg_MHz  Busy%  Bzy_MHz  PkgTmp  PkgWatt
-    2850     62.10  4588     86      310.12

Що означає вивід: Завантажені ядра працюють високо (Bzy_MHz), температура пакета висока, і потужність суттєва. Якщо Bzy_MHz падає з часом, а Busy% залишається високим — швидше за все ви обмежені потужністю/теплом.

Рішення: Для стійких навантажень підлаштуйте ліміти потужності, охолодження або зменшіть конкурентність. Не ганяйтеся за одноразовими boost-числами.

Завдання 5: Підтвердьте, що політика живлення (governor) не саботує вас

cr0x@server:~$ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
performance

Що означає вивід: Governor встановлено в performance. Якщо там powersave на хості, чутливому до латентності, ви фактично просите джиттер.

Рішення: Встановіть відповідну політику для ролі кластера. Пакет для пакетних задач може економити енергію; OLTP-кластер не повинен вдавати вигляд ноутбука.

Завдання 6: Виміряйте міграції планувальника (тихий NUMA-вбивця)

cr0x@server:~$ pidstat -w -p $(pgrep -n myservice) 1 5
Linux 6.5.0 (server)  01/12/2026  _x86_64_  (128 CPU)

01:10:01 PM   UID       PID   cswch/s nvcswch/s  Command
01:10:02 PM  1001     43210   120.00     15.00  myservice
01:10:03 PM  1001     43210   135.00     20.00  myservice
01:10:04 PM  1001     43210   128.00     18.00  myservice

Що означає вивід: Контекстні переключення помірні. Якщо ви також бачите часті міграції CPU (через perf або schedstat), ви втрачаєте локальність кешу між чиплетами.

Рішення: Розгляньте прив’язку CPU для найгарячіших потоків або налаштуйте час виконання (GC-потоки, кількість воркерів) щоб зменшити оборот.

Завдання 7: Перевірте тиск пропускної здатності пам’яті за допомогою pcm-memory (якщо встановлено)

cr0x@server:~$ sudo pcm-memory 1 -csv
Time,Ch0Read,Ch0Write,Ch1Read,Ch1Write,SystemRead,SystemWrite
1.00,12.3,5.1,11.8,4.9,198.4,82.1
2.00,12.5,5.0,12.1,4.8,201.0,80.9

Що означає вивід: Системна швидкість читання/запису висока. Якщо вона близька до меж платформи під час інциденту — ви обмежені пам’яттю, а не CPU.

Рішення: Зменште трафік пам’яті: виправте макет даних, зменшіть копіювання, підвищіть хит-рейти кешу або переходьте на платформу зі стекованим кешом/HBM, якщо ваш робочий набір підходить.

Завдання 8: Спостерігайте сигнали промахів кешу і стагнацій за допомогою perf

cr0x@server:~$ sudo perf stat -p $(pgrep -n myservice) -e cycles,instructions,cache-misses,branches,branch-misses -a -- sleep 10
 Performance counter stats for 'system wide':

    38,112,001,220      cycles
    52,880,441,900      instructions              #    1.39  insn per cycle
       902,110,332      cache-misses
     9,221,001,004      branches
       112,210,991      branch-misses

      10.002113349 seconds time elapsed

Що означає вивід: Багато промахів кешу. IPC непоганий, але промахи можуть домінувати над часом виконання залежно від навантаження. На чиплетних CPU промахи можуть транслюватися у трафік fabric і віддалені звернення пам’яті.

Рішення: Якщо промахи кешу корелюють зі спайками латентності, пріоритезуйте локальність: прив’яжіть потоки, зменшіть спільний стан і протестуйте SKU зі стекованим кешем, коли робочий набір трохи перевищує LLC.

Завдання 9: Перевірте помилки пам’яті та шторми скоректованих помилок

cr0x@server:~$ sudo ras-mc-ctl --summary
Memory controller events summary:
  Corrected errors: 24
  Uncorrected errors: 0
  No DIMM labels were found

Що означає вивід: Є скоректовані помилки. Зростаючий рівень може спричинити деградацію продуктивності та непередбачувану поведінку; на просунутих платформах пакування ви хочете помічати це рано.

Рішення: Якщо скоректовані помилки ростуть, заплануйте обслуговування: перепризначення, заміну DIMM, оновлення прошивки або виведення хоста з експлуатації. Не чекайте на некоректовані помилки, щоб навчити вас смиренності.

Завдання 10: Підтвердьте стан лінків/PCIe (IO-кристал теж частина історії)

cr0x@server:~$ sudo lspci -vv | sed -n '/Ethernet controller/,+25p' | egrep 'LnkSta:|LnkCap:'
LnkCap: Port #0, Speed 16GT/s, Width x16
LnkSta: Speed 16GT/s (ok), Width x16 (ok)

Що означає вивід: Лінк працює на очікуваній швидкості/ширині. Якщо ви бачите downtrained лінки — IO-продуктивність падає і CPU цикли витрачаються на обробку переривань/пакетів.

Рішення: Downtrained лінки вимагають перевірки: riser-и, BIOS-настройки, прошивка та фізичне встановлення. Не «оптимізуйте» ПО навколо зламаного обладнання.

Завдання 11: Підтвердіть розподіл переривань (щоб уникнути pileup на одному ядрі)

cr0x@server:~$ cat /proc/interrupts | egrep 'eth0|mlx|ens' | head
  55:   10223342          0          0          0   IR-PCI-MSI 524288-edge      ens3f0-TxRx-0
  56:          0    9981221          0          0   IR-PCI-MSI 524289-edge      ens3f0-TxRx-1
  57:          0          0    9875522          0   IR-PCI-MSI 524290-edge      ens3f0-TxRx-2

Що означає вивід: Переривання розподілені по CPU. Якщо всі переривання лягають на одне CPU в одному NUMA-вузлі, а ваше навантаження працює в іншому — ви отримаєте крос-вузловий трафік і джиттер.

Рішення: Прив’яжіть IRQ близько до NUMA-вузла NIC і до сервісних потоків, які обробляють пакети. Локальність стосується й IO.

Завдання 12: Перевірте політику пам’яті і явний локальний тест

cr0x@server:~$ numactl --cpunodebind=2 --membind=2 ./bench --duration 30
throughput=118223 ops/s
p99_latency_ms=3.4

Що означає вивід: Ви примусили і CPU, і пам’ять бути на вузлі 2. Порівняйте це з непінованими результатами. Великий дельта вказує на штрафи NUMA/fabric.

Рішення: Якщо пінінг суттєво покращує p99 — впровадьте політику розміщення (systemd CPUAffinity, Kubernetes topology manager або прив’язка на рівні сервісу), замість полювання на мікрооптимізації.

Завдання 13: Перевірте hugepages і індикатори тиску TLB

cr0x@server:~$ grep -E 'HugePages_Total|HugePages_Free|Hugepagesize' /proc/meminfo
HugePages_Total:    4096
HugePages_Free:     3900
Hugepagesize:       2048 kB

Що означає вивід: Hugepages доступні. У пам’яте-інтенсивних навантаженнях hugepages можуть зменшити промахи TLB, що важливіше, коли латентність пам’яті вже вища через віддалені звернення.

Рішення: Якщо профілювання показує тиск на TLB — увімкніть hugepages і валідуйте вплив. Не застосовуйте механіку наосліп — вимірюйте.

Завдання 14: Виявлення тротлінгу і причин лімітів потужності (приклад Intel через RAPL)

cr0x@server:~$ dmesg | egrep -i 'thrott|powercap|rapl' | tail -n 5
[ 8123.221901] intel_rapl: power limit changed to 210W
[ 8123.222110] CPU0: Package power limit exceeded, capping frequency

Що означає вивід: Система має power-capping. Ваш бенчмарк міг виконатись до втручання ліміту; продакшн виконується вже під цим лімітом.

Рішення: Узгодьте BIOS/прошивку і налаштування потужності з інтенцією навантаження. Якщо ви обмежуєтеся задля бюджету енергії датацентру — відкоригуйте SLO і налаштуйте конкурентність.

Три корпоративні міні-історії з ери чиплетів

Міні-історія 1: Інцидент через неправильне припущення

Середня SaaS-компанія мігрувала latency-чутливий API-тир на нові сервери. Така сама кількість ядер як раніше, вищі рекламовані boost-частоти і великий показник L3-кешу, який виглядав як безкоштовні гроші. Роллаут був консервативним: 5% canary, метрики спочатку виглядали нормально, потім 25%, потім 50%.

Приблизно на половині флоту p99 латентність почала стрибати. Не зростати плавно — стрибати. Графіки мали пилкоподібний шаблон, і люди сперечалися про патерни трафіку і GC. Завантаження CPU залишалося помірним. Мережа виглядала чистою. Сховище мовчало. Канал інцидентів наповнився найгіршим реченням в операціях: «Нічого не виглядає неправильно».

Неправильне припущення: вони поводилися з CPU як із однорідним ресурсом і думали, що якщо середній CPU% нормальний — CPU не є вузьким місцем. Насправді навантаження розподілялось по NUMA-вузлах і часто аллоцювало пам’ять віддалено через поведінку рантайму та свободу планувальника контейнерів. Віддалені звернення не були катастрофічними; вони були варіабельними, що руйнувало хвостову латентність.

Вони довели це, зафіксувавши сервіс в одному NUMA-вузлі і примусивши локальне виділення пам’яті в тесті. p99 стабілізувався миттєво, і пилкоподібний малюнок зник. Виправлення було не гламурним: топологічно-усвідомлене планування, CPU pinning для найгарячіших подів і свідома політика пам’яті. Вони також перестали перепаковувати latency-чутливі й пакетні поди на одному сокеті. «Більша завантаженість» не була ціллю; ціль була — передбачувана латентність.

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

Фінтех-команда запускала ризиковий движок, який багаторазово сканував великий in-memory набір. Вони купили SKU зі стекованим кешем, бо бенчмарк вендора показав великий приріст. Ранні тести були багатообіцяючими. Пропускна здатність зросла. Усі святкували. Потім вони зробили те, що роблять компанії: «оптимізували».

Команда агресивно підняла паралелізм, думаючи, що додатковий кеш дозволить масштабуватись. Вони також включили агресивніший turbo-профіль у BIOS, щоб ганяти короткочасні швидкісні підйоми. У стейджингу робота закінчувалась швидше — більшість часу.

У продакшні оптимізація відплатилася двома способами. По-перше, додаткові потоки збільшили трафік між чиплетами, бо робоча структура була спільною і не була коректно розділена. Міжз’єднання почало перевантажуватись. По-друге, turbo-політика швидко підвищила температуру, викликавши термальне тротлінгування посеред виконання. Система не просто сповільнилась; вона стала непередбачуваною. Деякі запуски закінчувалися швидко; деякі потрапляли на тротлінг і тягнулися.

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

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

Велика корпоративна платформа стандартизувала «чекліст при підключенні апаратури» для нових поколінь CPU. У нього входили базові налаштування BIOS/прошивки, версії мікрокоду, перевірка NUMA-топології і набір perf/latency smoke-тестів, зафіксованих на конкретних вузлах.

Коли прийшла партія нових серверів, smoke-тести показали тонку регресію: пропускна здатність пам’яті була нижчою, ніж очікувалась на одному NUMA-вузлі, і p99 латентність при синтетичному змішаному навантаженні була гіршою. Нічого явно не падало. Більшість команд оголосили б це «в межах варіації» і пішли далі.

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

Вони виправили базу, перевстановили хости, повторно запустили ті самі зафіксовані тести і отримали очікувані результати. Ніяких геройств. Жодних нічних інцидентів. Просто операційна дисципліна: вимірюйте, стандартизуйте і відмовляйтеся приймати мовчазну варіацію у світі, де пакети — це малі розподілені системи.

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

1) Симптом: спайки p99 після масштабування на більше ядер

Корінна причина: Контенція між чиплетами та віддалені звернення пам’яті зростають, коли потоки розповсюджуються по NUMA-вузлах; спільні структури даних підсилюють трафік.

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

2) Симптом: завантаження CPU помірне, але пропускна здатність низька

Корінна причина: Стави пам’яті (LLC misses, латентність DRAM), задирки fabric або часті міграції приховані за «не завантажений» CPU.

Виправлення: Використовуйте perf stat і інструменти пропускної здатності пам’яті; перевірте numastat; піньте й локалізуйте; зменшуйте аллокаторний шум і копіювання.

3) Симптом: нові сервери швидші в бенчмарках, але гірші в продакшні

Корінна причина: Бенчмарки ловлять boost-частоти і гарячі кеш-стани; продакшн працює в стійких лімітах потужності і змішаних навантаженнях.

Виправлення: Тестуйте стійкі прогони, включайте p99-метрики і валідуйте під реалістичною конкурентністю та тепловими умовами.

4) Симптом: один хост у пулі постійно дивний

Корінна причина: Downtrained PCIe-лінк, деградований канал пам’яті, шторм скоректованих помилок або дрейф BIOS, що впливає на енергію/топологію.

Виправлення: Перевірте lspci -vv, підсумки RAS, версії мікрокоду/BIOS; ізолюйте та виправте замість того, щоб налаштовувати під це ПО.

5) Симптом: джиттер латентності після увімкнення «енергозберігаючих» функцій

Корінна причина: Агресивні C-state, відсікання годин fabric, частотне масштабування або пакетні ліміти потужності викликають варіабельну поведінку пробудження/буста.

Виправлення: Використовуйте performance governor для латентнісних режимів, налаштуйте BIOS power states і перевірте turbostat під реальним навантаженням.

6) Симптом: падіння pps мережі після оновлення апаратури

Корінна причина: IRQ і потоки на різних NUMA-вузлах; IO-кристал і локальність NIC мають значення, і крос-вузловий трафік додає латентності.

Виправлення: Вирівняйте афінітет IRQ і потоки застосунку з NUMA-вузлом NIC; підтвердіть ширину/швидкість лінку; уникайте надмірної консолідації.

7) Симптом: «Ми додали стекований кеш, але не побачили виграш»

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

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

8) Симптом: після контейнеризації продуктивність погіршилася на чиплетних CPU

Корінна причина: Планувальник контейнерів перемістив потоки по CPU/NUMA-вузлах; cgroup CPU-квоти ввели сплески; локальність сторінки кешу погіршилась.

Виправлення: Використовуйте CPU manager/topology manager, встановіть явні requests/limits відповідно і пініть пам’ять-інтенсивні поди до NUMA-вузлів.

Чеклісти / покроковий план для нових платформ

Покроковий план: введення нової платформи з чиплетами/стеками в продакшн

1. Базова топологія: зафіксуйте lscpu і numactl --hardware для SKU; збережіть разом з артефактами збірки.
2. Стандартизувати прошивку: налаштування BIOS, мікрокод і політики енергії мають бути однаковими по пулу.
3. Виберіть стандартну енергетичну стратегію по тиру: латентні кластери отримують performance policy; пакетні кластери можуть навмисно бути power-capped.
4. Запустіть зафіксовані smoke-тести: виміряйте пропускну здатність і p99 із CPU+пам’яттю, прив’язаними до вузла; потім запустіть непіновані; порівняйте дельти.
5. Перевірте запас пропускної здатності пам’яті: якщо ваше навантаження обмежене пам’яттю — планування ємності означає планування пропускної здатності.
6. Перевірте локальність IO: перевірте стан PCIe лінків і розподіл IRQ; переконайтесь, що афінітет NIC відповідає розміщенню CPU.
7. Вирішіть політику розміщення: або прийміть NUMA (прив’язка і локалізація), або явно інтерлейвуйте для пропускної здатності. Не робіть «випадкового гібрида».
8. Розгорніть з детекцією варіації: слідкуйте не лише за медіанами, а й за розкидом по хостах; алертьте на «один хост дивний» рано.
9. Документуйте режими відмов: підписи тротлінгу, пороги скоректованих помилок і як ізолювати хост.
10. Повторно тестуйте після оновлень ядра: зміни планувальника можуть допомогти або зашкодити топологічній обробці; періодично валідуйте.

Чекліст: як вирішувати між стекованим кешем і більшою пропускною здатністю пам’яті

• Якщо ваш робочий набір трохи більший за LLC і ви бачите багато LLC misses: стекований кеш може дати великий виграш.
• Якщо пропускна здатність пам’яті близька до максимуму і превалюють стаги: стекований кеш може вас не врятувати; пріоритет — пропускна здатність (HBM платформи, більше каналів) або зменшення трафіку.
• Якщо хвостова латентність важлива: віддавайте перевагу рішенням, що зменшують варіацію (локальність, стабільна політика потужності), а не чисто піковим показникам.

Чекліст: чого уникати при впровадженні чиплет-орієнтованих CPU

• Не припускайте «один сокет = однорідність». Вимірюйте NUMA-поведінку.
• Не приймайте дрейф BIOS у автоскейлінг-групі.
• Не налаштовуйте додатки, не перевіривши спочатку поведінку потужності і тротлінг.
• Не змішуйте латентні і пакетні навантаження на одному сокеті без суворої ізоляції.

FAQ

1) Чи завжди чиплети швидші за монолітні кристали?

Ні. Чиплети насамперед — економічна і продуктова стратегія, з вигодами по продуктивності тоді, коли міжз’єднання і топологія управляються добре. Погана локальність може знищити виграш.

2) Чи зробить 3D-стекінг CPU гарячішими?

Часто так, на практиці. Стеки можуть ускладнювати відвід тепла і створювати гарячі точки. Вендори проектують навколо цього, але стійкі навантаження можуть відчувати ранні тротлінг або більшу варіацію.

3) Чи обов’язкове NUMA-тюнінг тепер?

Для latency-чутливих сервісів на чиплетних CPU це майже обов’язково. Для «емоційно паралельних» пакетних задач часто можна обійтися без нього — поки раптом не можна.

4) Які навантаження найбільше виграють від стекованого кешу?

Навантаження з робочим набором, який більший за звичайний кеш, але менший за DRAM-патріотичні стрімінги: hot key-value, деякі аналітичні задачі, певні симуляції і читин-важливі in-memory структури даних.

5) Який операційний ризик більш просунутого пакування?

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

6) Чи означає чиплети, що «більше ядер» перестануть допомагати?

Більше ядер і далі допомагатимуть для паралельних задач, але масштабування стає більш чутливим до пропускної здатності пам’яті, задирки fabric і конкуренції за спільний стан. Легкі виграші закінчилися.

7) Як HBM змінює планування ємності?

HBM підштовхує до багаторівневої моделі: дуже висока пропускна здатність, але обмежена ємність. Плануйте, що має залишитись в HBM, що може пролитися в DDR і як поводиться ваш аллокатор/рантайм.

8) Чи зробить UCIe пакети CPU модульними як збірка ПК?

З часом вони стануть більш модульними, ніж сьогодні — але не чекайте plug-and-play. Цілісність сигналу, доставка живлення, терміка і валідація усе ще складні, і «стандарт» не усуне фізику.

9) Яка найпростіша «достатня» зміна, щоб зменшити хвостову латентність на чиплетних CPU?

Прив’яжіть найгарячіші потоки до NUMA-вузла і тримайте їхньої пам’ять локально. Потім перевірте за допомогою зафіксованого A/B тесту. Якщо це допомагає — інвестуйте в топологічно-усвідомлене планування.

10) Чи купувати мені SKU зі стекованим кешем для всього?

Ні. Купуйте їх для навантажень, які демонструють чутливість до кешу під час профілювання. Інакше ви платите за кремній, який переважно прикрашає ваш procurement-список.

Практичні наступні кроки

3D-стекінг і чиплети — це не тренд; це форма дороги попереду. CPU стає пакетно-рівневою розподіленою системою з тепловими й топологічними обмеженнями. Ваш софт і операції мають поводитися відповідно.

Що зробити наступного тижня (не в наступному кварталі)

1. Виберіть один сервіс з SLO по латентності і запустіть pinned vs unpinned NUMA тест (numactl), щоб виміряти чутливість.
2. Додайте дві панелі на хості: частота CPU/тротлінг (на основі turbostat) і віддалені NUMA-доступи (numastat/PMU, якщо є).
3. Стандартизуйтe базові налаштування BIOS/мікрокоду для кожного пулу апаратури; алертьте на дрейф.
4. Напишіть односторінковий runbook, використовуючи Швидку діагностику вище, щоб on-call не звинувачував мережу за звичкою.
5. Визначте філософію розміщення: локальність-перш за все для латентних тирів; інтерлив/пропускна здатність для throughput-ти грів — і примусьте її виконуватися.

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

Швидкий план діагностики

Якщо ви на виклику і кластер кричить, вам не потрібна філософська лекція. Потрібен короткий цикл:
підтвердити режим відмови, визначити обмежувач, зробити одну безпечну зміну, повторити.

По-перше: це виснаження пам’яті хоста чи обмеження на ВМ?

• Якщо ВМ не вдається запустити з повідомленням «неможливо виділити пам’ять», підозрюйте
  ліміти коміту хоста, обмеження cgroup, hugepages або фрагментацію — це часто помітно одразу в dmesg / журналах.
• Якщо ВМ запускається, а потім її вбивають, зазвичай це OOM killer у гостьовій ОС (всередині ВМ) або
  OOM killer хоста (вбиває QEMU), залежно від того, в яких логах видно труп.

По-друге: перевірте реальний запас хоста, а не гарні графіки

• Вільна пам’ять хоста і swap: free -h
• Тиск пам’яті і затримки при звільненні: vmstat 1
• Докази OOM: journalctl -k та dmesg -T
• Розмір ZFS ARC (якщо використовуєте ZFS): arcstat / /proc/spl/kstat/zfs/arcstats

По-третє: перевірте політику та виділення зі сторони Proxmox

• Конфіг ВМ: ціль балона vs max, hugepages, NUMA тощо:
  qm config <vmid>
• Політика перевиділення на вузлі: pvesh get /nodes/<node>/status та
  /etc/pve/datacenter.cfg
• Якщо це контейнер (LXC), перевірте обмеження пам’яті cgroup і ліміт swap:
  pct config <ctid>

По-четверте: виберіть найменш шкідливе негайне пом’якшення

• Зупиніть одну некритичну ВМ, щоб звільнити RAM і знизити тиск прямо зараз.
• Якщо ZFS «їсть» сервер: обмежте ARC (постійно) або, в крайньому разі, перезавантажте.
• Якщо ви перевиділяєте: зменшіть max-пам’ять ВМ (не лише ціль балона).
• Якщо swap відсутній і ви напружені: додайте swap (на хості), щоб уникнути миттєвого OOM, поки ви виправляєте розміри.

Жарт №1: Перевиділення пам’яті — як корпоративний бюджет: все працює, поки всі не спробують одночасно відшкодувати обід.

Що насправді означає «неможливо виділити пам’ять» в Proxmox

Proxmox — це шар управління. Реальний аллокатор — Linux, а для ВМ зазвичай QEMU/KVM. Коли ви бачите
«неможливо виділити пам’ять», відбувається одне з наступного:

• QEMU не може зарезервувати запитану ВМ оперативну пам’ять під час старту. Це може завершитись невдачею,
  навіть якщо free виглядає нормально, бо Linux дбає про правила коміту і фрагментацію.
• Ядро відмовляє в алокації через логіку overcommit/CommitLimit. Linux відстежує, скільки пам’яті
  процеси пообіцяли потенційно використати (віртуальна пам’ять), і може відмовляти новим обіцянкам.
• Запитані hugepages відсутні. Hugepages вирізані заздалегідь. Якщо їх немає, алокація провалюється
  миттєво й голосно.
• Обмеження cgroup блокують алокацію. Частіше трапляється з контейнерами, але може впливати, якщо залучені systemd slices або кастомні cgroups.
• Пам’ять є, але не в формі, яку ви просите. Фрагментація може перешкодити великим суміжним виділенням, особливо для hugepages або певних DMA-вимог.

Тим часом «рішення», до якого звертаються люди — балонінг — не змінює того, що QEMU попросив, якщо ви все ще встановили великий
max пам’яті. Балонінг регулює те, що гість заохочують використовувати, а не те, що хост має бути готовий забезпечити в найгірший момент.

Два числа, що мають значення: target гостьової пам’яті і guest max

В опціях ВМ Proxmox балонінг дає вам:

• Memory (max): стеля ВМ. QEMU виконує облік для неї.
• Balloon (min/target): ціль під час виконання, яку можна зменшити під тиском.

Якщо ви встановлюєте max на 64 ГіБ «на всяк випадок» і ціль балона на 8 ГіБ «бо зазвичай простаєте», ви сказали хосту:
«Будь ласка, будь готовий фінансувати мій 64 ГіБ стиль життя». Хост, будучи дорослим, може сказати «ні».

Цікавинки та трохи історії (щоб більше не повторювати помилок)

1. Поведінка Linux щодо overcommit стара і свідома: вона існує, бо багато алокацій ніколи не використовуються повністю,
   і суворий облік витрачав би RAM на порожні обіцянки.
2. OOM killer з’явився задовго до сучасних віртуалізаційних стеків; це був прагматичний відповідь Linux на «хтось брешe про пам’ять» задовго до того, як маркетинг хмар перетворив брехню на фічу.
3. Балонінг став поширеним з ранніми гіпервізорами, бо прості гості скуповували кеш і робили консолідацію гіршою, ніж вона мала бути.
4. KSM (Kernel Samepage Merging) призначений для дедуплікації ідентичних сторінок пам’яті між ВМ — корисно, коли багато ВМ з однаковим образом ОС.
5. Transparent Huge Pages (THP) були введені для підвищення продуктивності через більші сторінки, але вони можуть створювати спади латентності під тиском пам’яті через роботу з компактування.
6. ZFS ARC — це не «просто кеш». Він конкурує з анонімною пам’яттю. Якщо ви не обмежите його, він із задоволенням візьме RAM,
   поки ядро не змусить віддати — іноді запізно.
7. cgroups змінили гру: замість того, щоб весь хост був однією дружною сім’єю, тепер обмеження пам’яті можуть зробити так, що одна ВМ або контейнер впаде, навіть коли хост виглядає нормально.
8. Swap колись був обов’язковою порадою; потім люди ним зловживали; потім його відкидали; потім сучасні SSD зробили «невеликий контрольований swap» знову розумним у багатьох випадках.

Операційна цитата, що лишається болісно актуальною (парафраз): Вернер Фогельс казав, що суть надійності — очікувати відмов і проектувати під них, а не прикидатися, що їх не буде.

Балонінг: що він робить, чого не робить і чому він вас вводить в оману

Що таке балонінг насправді

Балонінг використовує драйвер всередині гостя (зазвичай virtio-balloon). Хост просить гостя «надути» балон,
тобто: виділити пам’ять всередині гостя й зафіксувати її так, щоб гість не міг її використовувати. Ця пам’ять стає
придатною для звільнення з точки зору хоста, бо гість добровільно її віддав.

Це хитро. Але є обмеження фізики та поведінки гостя:

• Якщо гість під реальним тиском пам’яті, він не зможе багато віддати без swap або OOM всередині себе.
• Якщо в гості немає драйвера балона, балонінг — це по суті пантоміма.
• Балонінг реактивний. Якщо хост уже в біді, може бути запізно.

Важливий нюанс балонінгу в Proxmox

Конфігурація балонінгу в Proxmox часто дає хибне відчуття безпеки. Люди ставлять низькі цілі балона і високі max-пам’яті,
думаючи, що «використовують лише ціль». Але облік QEMU і логіка коміту ядра часто повинні враховувати максимум.

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

Коли балонінг вартий застосування

• Кластери для розробки/тестування, де гості простаивают, а стрибки рідкісні й терпимі.
• Флоти VDI-подібних ВМ з багатьма схожими образами, часто разом із KSM.
• Звичайні серверні флоти, де ви можете забезпечити реалістичні max-значення, а не фантазії.

Коли балонінг — пастка

• Бази даних з жорсткою затримкою та великими buffer pool — тиск в гості переводиться в IO-тиск.
• Системи з вимкненим swap всередині гостей (балонінг може викликати OOM у гості).
• Хости, що вже напружені по пам’яті, де час реакції балона занадто повільний.

Перевиділення: коли це розумно, а коли — ризиковано

Три різні «перевиділення», які плутають люди

На практиці ви балансуєте три шари:

1. Перевиділення у планувальнику/обліку Proxmox: чи вважає Proxmox, що можна запустити ще одну ВМ
   на основі налаштованої RAM, цілей балона і пам’яті вузла.
2. Поведінка перевиділення в Linux: vm.overcommit_memory і CommitLimit.
3. Фактичне фізичне перевиділення: чи перевищує сума активно використовуваної гостями пам’яті RAM хоста
   (і чи є у вас swap, компресія чи план дій).

Коротко про облік коміту в Linux в одній абзаці для операцій

Linux вирішує, чи дозволити алокацію, виходячи з того, скільки пам’яті може бути використано, якщо процеси її торкнуться.
Це число відстежується як Committed_AS. Дозволений поріг — CommitLimit,
приблизно RAM + swap мінус деякі резерви, змінений налаштуваннями overcommit. Якщо Committed_AS наближається
до CommitLimit, ядро починає відмовляти в алокаціях — привіт, «неможливо виділити пам’ять».

Думка щодо практики

• Продакшен: тримайте перевиділення помірним і забезпечуйте реалістичні max ВМ. Якщо ви не можете вказати
  співвідношення перевиділення і план евакуації, ви не перевиділяєте — ви граєте в азартні ігри.
• Лабораторія: перевиділяйте агресивно, якщо готові до випадкових OOM. Просто маркуйте це чесно і не прикидайтеся, що це продакшен.
• Змішані навантаження: або відокремте «шумних» користувачів пам’яті (БД, аналітика) на окремі вузли,
  або ж жорстко їх обмежуйте. «Співіснування» — так називають те, що люди говорять перед інцидентом.

ZFS ARC, page cache і пам’ять хоста, про яку ви забули

Proxmox часто працює на ZFS через зручність снапшотів і send/receive. Але ZFS не соромиться: він використовує RAM
для ARC (Adaptive Replacement Cache). Це добре, поки не стає проблемою.

ARC проти «вільної пам’яті»

ARC придатний для звільнення, але не миттєво і не завжди в тій формі, яку потребує запуск ВМ. При тиску ядро
намагається звільнити page cache і ARC, але якщо ви в циклі швидких алокацій (запуск ВМ, надування пам’яті,
форкінг процесів), ви можете отримати транзитні відмови.

Що робити

• На хостах з ZFS і багатьма ВМ встановіть розумний максимум ARC (zfs_arc_max). Не дозволяйте ARC «боротися» з вашими гостями.
• Розглядайте пам’ять хоста як спільну інфраструктуру. Хост потребує пам’яті для:
  ядра, slab, мережі, метаданих ZFS, оверхеду QEMU та ваших агентів моніторингу, які клянуться бути легкими.

Swap: не гріх, але й не план життя

Відсутність swap означає, що ви забрали амортизатори. У віртуалізації це може бути фатально, бо раптовий сплеск тиску
перетворюється на миттєві OOM-вбивства замість повільного, діагностованого погіршення.

Але swap також може стати перетягуванням продуктивності. Мета — контрольований swap: достатньо, щоб пережити сплески,
але не стільки, щоб приховати хронічне перевиділення.

Рекомендації щодо swap на хості (практично, не догма)

• Якщо ви працюєте на ZFS і маєте багато ВМ: додайте swap. Навіть помірна кількість може запобігти вбиванню QEMU під час коротких сплесків.
• Якщо ваше сховище повільне: тримайте swap меншим і віддавайте пріоритет правильному розміруванню RAM. Свап на повільних HDD — це не «стабільність», а «тривале страждання».
• Якщо ви використовуєте SSD/NVMe: swap значно більш терпимий, але все одно не безкоштовний. Моніторте швидкість swap-in/out, а не тільки використання swap.

Жарт №2: Swap — це як зустріч, яка могла бути листом — іноді рятує день, але якщо ви там живете, ваша кар’єра закінчена.

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

Ось перевірки, які я реально запускаю, коли вузол Proxmox починає кидати помилки алокації пам’яті. Кожне завдання містить:
команду, приклад виводу, що це означає і яке рішення воно визначає.

Завдання 1: Перевірити RAM і swap хоста на око

cr0x@server:~$ free -h
               total        used        free      shared  buff/cache   available
Mem:            62Gi        54Gi       1.2Gi       2.3Gi       6.9Gi       2.8Gi
Swap:            8Gi       1.6Gi       6.4Gi

Значення: «available» — ваш ближній запас перед тим, як звільнення стане некрасивим. 2.8 ГіБ на хості 62 ГіБ
з віртуалізацією — тісно, але не миттєво катастрофічно.

Рішення: Якщо available < 1–2 ГіБ і ВМ не стартують, зупиніть некритичні ВМ. Якщо swap = 0, додайте swap як стабілізатор, поки виправляєте розміри.

Завдання 2: Визначити, чи ядро відхиляє алокації через CommitLimit

cr0x@server:~$ grep -E 'CommitLimit|Committed_AS' /proc/meminfo
CommitLimit:    71303168 kB
Committed_AS:   70598240 kB

Значення: Ви близькі до стелі коміту. Ядро може відмовляти новим резервуванням пам’яті навіть якщо є кеш, який можна звільнити.

Рішення: Зменшити max-пам’ять ВМ, додати swap (збільшує CommitLimit) або перемістити навантаження.
Зміна цілей балона не допоможе, якщо проблема в max.

Завдання 3: Підтвердити політику overcommit

cr0x@server:~$ sysctl vm.overcommit_memory vm.overcommit_ratio
vm.overcommit_memory = 0
vm.overcommit_ratio = 50

Значення: Режим 0 — евристичне перевиділення. Ratio важливий здебільшого для режиму 2. Все одно, поведінка коміту в дії.

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

Завдання 4: Шукати докази роботи OOM killer на хості

cr0x@server:~$ journalctl -k -b | tail -n 30
Dec 26 10:14:03 pve1 kernel: Out of memory: Killed process 21433 (qemu-system-x86) total-vm:28751400kB, anon-rss:23110248kB, file-rss:0kB, shmem-rss:0kB
Dec 26 10:14:03 pve1 kernel: oom_reaper: reaped process 21433 (qemu-system-x86), now anon-rss:0kB, file-rss:0kB, shmem-rss:0kB

Значення: Хост вбив QEMU. Та ВМ не «поїхала», її виконали.

Рішення: Розглядайте як виснаження пам’яті хоста/перевиділення. Зменшіть консолідацію, обмежте ARC, додайте swap
і не покладайтеся на балонінг як ремінь безпеки.

Завдання 5: Перевірити тиск пам’яті та поведінку звільнення в реальному часі

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
 6  1 1677720 312000  8200 5120000  40  120   180   260  900 1800 18 12 55 15  0
 5  2 1677800 280000  8100 5010000  10  200   140   320  920 1700 15 10 50 25  0
 7  3 1677850 260000  8000 4920000  80  500   220   600 1100 2200 20 15 35 30  0

Значення: Ненульові si/so вказують на свапінг. Високий wa — IO wait.
Якщо b росте, а id падає, хост трясеться (thrashing).

Рішення: Якщо свапінг тривалий і IO wait підіймається, зупиніть ВМ або перемістіть навантаження.
Ви не зможете «відтюнити» себе з бурі thrash у реальному часі.

Завдання 6: Знайти найбільших споживачів пам’яті на хості (RSS, не VIRT-мрії)

cr0x@server:~$ ps -eo pid,comm,rss,vsz --sort=-rss | head -n 10
 21433 qemu-system-x86 23110248 28751400
 19877 qemu-system-x86 16188012 21045740
  1652 pveproxy          312400  824000
  1321 pvedaemon         210880  693000
  1799 zfs               180200  0
  1544 pvestatd          122000  610000

Значення: RSS — це реальна резидентна пам’ять. QEMU-процеси домінують, як і очікувалось.

Рішення: Якщо одна ВМ розженена, обмежте її max-пам’ять або розслідуйте всередині гостя.
Якщо «багато середніх» ВМ навантажують — це математика консолідації, а не один негідник.

Завдання 7: Подивитись конфіг ВМ (балон vs max)

cr0x@server:~$ qm config 104 | egrep 'memory|balloon|numa|hugepages'
memory: 32768
balloon: 8192
numa: 1
hugepages: 2

Значення: Max — 32 ГіБ, ціль балона 8 ГіБ. Hugepages увімкнено (2 = 2MB hugepages).

Рішення: Якщо вузол не вдається виділити пам’ять, max цієї ВМ у 32 ГіБ може бути надто щедрим.
Якщо hugepages увімкнено, підтвердіть їх наявність (Завдання 8) або вимкніть для гнучкості.

Завдання 8: Перевірити наявність hugepages (класична причина помилок старту)

cr0x@server:~$ grep -i huge /proc/meminfo
AnonHugePages:   1048576 kB
HugePages_Total:    8192
HugePages_Free:      120
HugePages_Rsvd:       50
Hugepagesize:       2048 kB

Значення: Вільних лише 120 hugepages (~240 МіБ). Якщо ви спробуєте стартувати ВМ, що потребує багато hugepages, вона впаде.

Рішення: Або забезпечте достатньо hugepages при завантаженні, або припиніть використовувати hugepages для цього класу ВМ.
Hugepages — інструмент продуктивності, а не налаштування за замовчуванням.

Завдання 9: Перевірити поведінку THP (може викликати латентність при тиску)

cr0x@server:~$ cat /sys/kernel/mm/transparent_hugepage/enabled
[always] madvise never

Значення: THP увімкнено завжди.

Рішення: Для вузлів, чутливих до латентності, розгляньте madvise або never.
Не змінюйте це під час інциденту, якщо ви не впевнені; плануйте в maintenance-вікні і вимірюйте.

Завдання 10: Якщо використовуєте ZFS — швидко перевірити розмір ARC

cr0x@server:~$ awk '/^size/ {print}' /proc/spl/kstat/zfs/arcstats
size                            4    34359738368

Значення: ARC ≈ 32 ГіБ. На хості 64 ГіБ з багатьма ВМ це може бути забагато.

Рішення: Якщо вам не вистачає пам’яті і ARC великий, обмежте ARC постійно (див. розділ контрольного списку)
і заплануйте перезавантаження для негайного полегшення.

Завдання 11: Підтвердити статус KSM (допомагає при багатьох схожих ВМ, але коштує CPU)

cr0x@server:~$ systemctl is-active ksmtuned
inactive

Значення: Сервіс налаштування KSM не працює. На деяких Proxmox-настройках KSM налаштовано інакше;
це швидкий індикатор.

Рішення: Якщо ви запускаєте десятки схожих Linux-ВМ, увімкнення KSM може зменшити використання пам’яті.
Якщо CPU вже гарячий, KSM може зашкодити. Тестуйте на одному вузлі спочатку.

Завдання 12: Перевірити інформацію про пам’ять вузла в Proxmox (що Proxmox думає)

cr0x@server:~$ pvesh get /nodes/pve1/status | egrep '"memory"|"swap"|"loadavg"'
"loadavg": [
  "2.61",
  "2.45",
  "2.31"
],
"memory": {
  "free": 1288490188,
  "total": 66571993088,
  "used": 651834
},
"swap": {
  "free": 6871947673,
  "total": 8589934592,
  "used": 1717986919
}

Значення: API Proxmox дає вигляд, який може відрізнятися від ваших очікувань (одиниці, кешування, час).
Не вважайте його абсолютною істинною; перевіряйте free і meminfo.

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

Завдання 13: Проаналізувати помилку старту ВМ у логах завдань

cr0x@server:~$ journalctl -u pvedaemon -b | tail -n 20
Dec 26 10:18:11 pve1 pvedaemon[1321]: start VM 104: UPID:pve1:0000A3F9:00B2B6D1:676D5A13:qmstart:104:root@pam:
Dec 26 10:18:12 pve1 pvedaemon[1321]: VM 104 qmp command failed - unable to execute QMP command 'cont': Cannot allocate memory
Dec 26 10:18:12 pve1 pvedaemon[1321]: start failed: command '/usr/bin/kvm -id 104 ...' failed: exit code 1

Значення: Помилка відбувається на стадії старту/cont QEMU, не всередині гостя.

Рішення: Сфокусуйтеся на лімітах коміту хоста, hugepages і фрагментації — не на тонкому тюнінгу гостя.

Завдання 14: Перевірити конфіг контейнера (LXC) та ліміт swap

cr0x@server:~$ pct config 210 | egrep 'memory|swap|features'
memory: 4096
swap: 512
features: nesting=1,keyctl=1

Значення: Контейнер має 4 ГіБ RAM і 512 МіБ swap. Якщо він стрибне вище, алокації всередині контейнера проваляться.

Рішення: Для контейнерів «неможливо виділити пам’ять» часто означає досягнення ліміту cgroup.
Збільшуйте memory/swap або виправляйте поведінку додатка. Вільна RAM хоста не врятує LXC з жорсткою межею.

Завдання 15: Перевірити сигнали ризику фрагментації (швидко і грубо)

cr0x@server:~$ cat /proc/buddyinfo | head
Node 0, zone      DMA      1      1      1      1      0      0      0      0      0      0      0
Node 0, zone    DMA32   1024    512    220     12      0      0      0      0      0      0      0
Node 0, zone   Normal   2048   1880    940    110      2      0      0      0      0      0      0

Значення: Buddy allocator показує, скільки вільних блоків є в різних порядках. Якщо вищі порядки майже нуль,
великі суміжні виділення (включно з потребами hugepage) можуть провалюватись навіть при «достатній загальній вільній пам’яті».

Рішення: Якщо hugepages/THP і компактування важливі для вашої конфігурації, розгляньте зменшення залежності від суміжних виділень
або плануйте періодичні обслуговування/перезавантаження для вузлів, які мають задовольняти такі виділення.

Три корпоративні короткі історії з поля бою

Інцидент: хибне припущення («балонінг означає, що max не резервується»)

Середня компанія тримала внутрішній Proxmox-кластер для бізнесових додатків і кількох важких пакетних задач.
Команда мала звичку: ставити високу max-пам’ять ВМ «щоб ніхто не писав тикет», а ціль балона — низьку,
щоб «підтримувати ефективність».

Це працювало — поки вони не оновили декілька ВМ і не запустили квартальний звіт. Нові процеси породилися, карти пам’яті
розширилися, і кілька ВМ перезапустилися для патчів. Раптом: «неможливо виділити пам’ять» при старті ВМ.
Дашборд усе ще показував «вільно», бо кеш здався відновлюваним.

Корінь проблеми — не витік. Це був облік. Committed_AS хоста повільно підбирався до CommitLimit.
Кожна ВМ з щедрим max додавала до суми «пообіцяної» пам’яті, навіть якщо «зазвичай» сиділа на низькому рівні. Коли декілька
рестартів відбулися одночасно, QEMU спробував зарезервувати те, що йому казали, що може знадобитись. Ядро відмовило.
Помилка була правдивою; їхня ментальна модель — ні.

Виправлення було нудним: вони зменшили max-пам’ять ВМ до обґрунтованих значень, зберегли балонінг для еластичності
і додали swap на хости, де його не було. Найголовніше — вони перестали ставитись до «max» як до бажання.
Наступний квартальний прогін ще підскакував, але перестав ламати рестарти.

Оптимізація, що відпалила (hugepages усюди)

Інша організація гналася за затримкою. Інженер з продуктивності увімкнув hugepages для цілого класу ВМ, бо блог казав,
що це покращить TLB-поведінку. І справді може. Вони також залишили Transparent Huge Pages у положенні «always»,
бо більше hugepages звучало як більше продуктивності. Так оптимізм перетворився на конфігурацію.

Тижнями все виглядало нормально. Потім один вузол почав падати при старті ВМ після рутинних міграцій. Та сама ВМ на інших вузлах стартувала.
На цьому вузлі: «неможливо виділити пам’ять». Вільної пам’яті не було катастрофічно мало, але free hugepages майже не було.
Buddyinfo показав фрагментацію: пам’ять була, але не в потрібних шматках.

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

План відновлення: вимкнути hugepages для загальних ВМ, резервувати hugepages лише для невеликого набору критичних випадків із передбачуваним розміром,
і встановити THP в madvise. Загальна продуктивність покращилася, бо система припинила битися сама з собою.

Скучно, але вірно: резерв хоста і ліміти врятували ситуацію

Третя команда тримала Proxmox для змішаних навантажень: веб-додатки, кілька Windows-ВМ і пара сховищних appliance.
У них була нудна правило: кожен вузол тримає фіксований «резерв хоста» RAM, який ніколи не виділяється гостям офіційно.
Вони також обмежили ZFS ARC з першого дня.

Це не було красиво. Це означало, що вони могли запускати менше ВМ на вузол, ніж хотіли фанатики таблиць.
Але під час інциденту, коли шумна ВМ раптово почала споживати пам’ять (невірно налаштований Java-сервіс), хост мав достатньо запасу,
щоб тримати процеси QEMU живими і уникнути OOM хоста.

Гість все одно постраждав (як і має бути), але зона ураження залишилася всередині тієї ВМ. Кластер не почав вбивати сторонні навантаження.
Вони злили вузол, виправили конфіг гістьової, і відновили роботу. Ніяких північних перезавантажень, ніяких каскадних відмов, ніяких «чому впала наш фаєрвол-ВМ?»

Практика, що врятувала їх, не була секретним тюнінгом ядра. Це було бюджетування і відмова витрачати аварійний фонд.

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

ВМ не стартує: «Неможливо виділити пам’ять» відразу

• Симптом: Старт падає миттєво; QEMU виходить з помилкою алокації.
• Причина: Досягнутий CommitLimit хоста, відсутні hugepages або фрагментація пам’яті для запитаного виділення.
• Виправлення: Зменшити max-пам’ять ВМ; додати swap на хості; вимкнути hugepages для цієї ВМ; забезпечити hugepages при завантаженні, якщо вони потрібні.

ВМ стартує, а потім раптово вимикається або скидається

• Симптом: ВМ ніби «крушиться», в логах немає чистого завершення.
• Причина: OOM killer хоста вбив QEMU, часто після стрибка пам’яті або важкого reclaim.
• Виправлення: Знайти OOM-логи; зменшити перевиділення хоста; резервувати пам’ять хоста; обмежити ZFS ARC; переконатися, що swap існує і моніторити його активність.

Гості спочатку повільні, потім хост повільнішає, потім всі починають філософствувати

• Симптом: IO wait піднімається; швидкості swap-in/out зростають; латентність ВМ підскакує.
• Причина: Thrashing: недостатньо RAM для робочих наборів, і свап/reclaim домінує.
• Виправлення: Зупинити або мігрувати ВМ; зменшити ліміти пам’яті; додати RAM; переглянути план консолідації. Жоден sysctl вас тут не врятує.

Балонінг увімкнено, але пам’ять ніколи не «повертається»

• Симптом: Хост залишається заповненим; гості не звільняють пам’ять, як очікувалось.
• Причина: Драйвер балона не встановлено/не працює, гість не може звільнити пам’ять, або «max» все ще зобов’язує хост.
• Виправлення: Встановити драйвер virtio-balloon; перевірити всередині гостя; встановити реалістичний max; використовувати балонінг для еластичності, а не як заміну розміру.

Все було гаразд, поки не збільшилися ZFS snapshots і реплікація

• Симптом: Тиск пам’яті хоста зростає під час інтенсивної роботи зі сховищем; старти ВМ падають.
• Причина: Зростання ARC, тиск метаданих, нарощування slab і IO-керована пам’ять.
• Виправлення: Обмежити ARC; моніторити slab; тримати запас; уникати роботи вузла на 95% «використано» і називати це ефективністю.

Контейнери показують «неможливо виділити пам’ять», хоча хост має запас

• Симптом: Додатки в LXC не можуть виділити пам’ять; хост виглядає нормально.
• Причина: Досягнутий ліміт пам’яті cgroup (memory/swap контейнера).
• Виправлення: Підвищити ліміти контейнера; налаштувати додаток; дозволити swap контейнера, якщо ви очікуєте сплесків.

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

Покроково: виправити вузол, який кидає помилки алокації

1. Підтвердити OOM хоста проти помилки при старті.
   Перевірте journalctl -k на OOM-вбивства і логи pvedaemon для контексту помилки старту.
2. Виміряти тиск коміту.
   Якщо Committed_AS близький до CommitLimit, ви в території «обіцянки перевищують реальність».
3. Перелічити ВМ з великим max-пам’яттю.
   Зменшіть max-пам’ять для винних. Не обмежуйтеся зміною лише цілей балона.
4. Перевірити hugepages і налаштування THP.
   Якщо hugepages увімкнено для ВМ, переконайтеся в достатній препризначеності або вимкніть для загальних навантажень.
5. Перевірити ZFS ARC, якщо це стосується.
   Якщо ARC великий і ви хост для ВМ перш за все, обмежте його.
6. Переконатися, що swap існує і він адекватний.
   Додайте swap, якщо його нема; моніторте si/so. Swap — для сплесків, а не для щоденної оренди.
7. Резервувати пам’ять хоста.
   Тримайте фіксований буфер для ядра + ZFS + оверхед QEMU. Ваше майбутнє «я» дякуватиме мовчки.
8. Повторно тестуйте запуск ВМ у контрольованій послідовності.
   Не запускайте все одразу після налаштувань. Стартуйте критичні служби першими.

Постійне налаштування: обмеження ZFS ARC (приклад)

Якщо вузол — це хост ВМ і ZFS — лише засіб, встановіть максимум ARC. Один поширений метод:
створити конфіг modprobe і оновити initramfs, щоб застосувати при завантаженні.

cr0x@server:~$ echo "options zfs zfs_arc_max=17179869184" | sudo tee /etc/modprobe.d/zfs.conf
options zfs zfs_arc_max=17179869184
cr0x@server:~$ sudo update-initramfs -u
update-initramfs: Generating /boot/initrd.img-6.8.12-4-pve

Значення: ARC обмежено до 16 ГіБ (значення в байтах). Ви сказали ZFS не їсти всю машину.

Рішення: Виберіть обмеження, що залишає достатньо RAM для гостей плюс резерв хоста. Підтвердіть після перезавантаження, читаючи arcstats.

Постійне налаштування: додати swap на хості (приклад файлу)

cr0x@server:~$ sudo fallocate -l 8G /swapfile
cr0x@server:~$ sudo chmod 600 /swapfile
cr0x@server:~$ sudo mkswap /swapfile
Setting up swapspace version 1, size = 8 GiB (8589930496 bytes)
no label, UUID=0a3b1e4c-2f1e-4f65-a3da-b8c6e3f3a8d7
cr0x@server:~$ sudo swapon /swapfile
cr0x@server:~$ swapon --show
NAME      TYPE SIZE USED PRIO
/swapfile file   8G   0B   -2

Значення: Swap активний. CommitLimit зростає, і у вас є буфер проти раптових сплесків алокацій.

Рішення: Якщо використання swap стає постійним разом з високими si/so, це не «працює як задумано».
Це сигнал зменшити консолідацію або додати RAM.

Політика: резервувати RAM для хоста (проста і дієва практика)

• Резервуйте принаймні 10–20% RAM хоста для хоста на змішаних вузлах.
  Більше — якщо ви запускаєте ZFS, Ceph, потужні мережі або багато малих ВМ.
• Тримайте «цільову суму max ВМ», яку можете відстояти. Якщо сума max ВМ перевищує заданий коефіцієнт від RAM хоста,
  робіть це свідомо й лише там, де поведінка навантаження це підтримує.

Контрольний список для балонінгу (використовуйте його правильно)

Поширені питання

1) Чому Proxmox каже «неможливо виділити пам’ять», коли free показує ГБ вільних?

Тому що free показує знімок фізичної пам’яті, тоді як облік коміту ядра і правила фрагментації можуть відмовити новій алокації.
Також «free» ігнорує, чи доступна пам’ять у потрібній формі (наприклад, hugepages).

2) Чи зменшує балонінг те, що хост повинен резервувати?

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

3) Чи варто ставити vm.overcommit_memory=1, щоб зупинити відмови алокацій?

Це грубий інструмент. Він може зменшити відмови при старті, але підвищує ризик катастрофічного OOM пізніше.
У продакшені краще виправити розмір ВМ і додати swap, ніж послаблювати захисні механізми ядра.

4) Скільки swap має бути на хості Proxmox?

Достатньо, щоб пережити сплески і підвищити CommitLimit, але не настільки, щоб приховати хронічне перевиділення.
Зазвичай: кілька ГБ до низьких десятків ГБ залежно від RAM хоста і волатильності навантаження. Міряйте активність swap; якщо вона постійна, ви недорозміровані.

5) Чи є ZFS ARC причиною, чому мій вузол «залипає без пам’яті»?

Іноді. ARC може рости і конкурувати з ВМ. Якщо старти ВМ провалюються або хост OOM, коли ARC великий,
обмежте ARC. Якщо ARC невеликий, дивіться інші причини (комітліміт, hugepages, розгінні ВМ).

6) Чи варто увімкнути KSM на Proxmox?

Якщо ви запускаєте багато схожих ВМ (той самий ОС, схожі сторінки пам’яті), KSM може зекономити RAM.
Це коштує CPU і може додати латентності. Увімкніть свідомо, вимірюйте вплив на CPU і не вважайте це безкоштовною пам’яттю.

7) Чому контейнери б’ються «неможливо виділити пам’ять», якщо хост в порядку?

LXC керується cgroups. Контейнер може досягти ліміту всередині свого простору, навіть якщо хост має запас.
Підніміть ліміти pct memory/swap або виправте навантаження контейнера.

8) Чи варті hugepages того?

Для певних високопродуктивних, чутливих до латентності навантажень — так. Для загальної консолідації — часто ні.
Hugepages підвищують передбачуваність TLB, але знижують гнучкість і можуть створювати проблеми запуску, якщо їх не забезпечити.

9) У чому різниця між гостевим OOM і OOM хоста?

Гостевий OOM відбувається всередині ВМ: гостьове ядро вбиває процеси, але ВМ залишається запущеною. OOM хоста вбиває процеси
на гіпервізорі, включно з QEMU — ваша ВМ зникає. OOM хоста псує вам день.

10) Чи можна «постійно вирішити» це без додавання RAM?

Часто так: встановіть реалістичні max-пам’яті ВМ, резервуйте RAM для хоста, обмежте ARC за потреби і уникайте фантастичних співвідношень перевиділення.
Якщо робочі набори реально перевищують фізичну RAM, постійне рішення — більше RAM або менше навантажень на вузол.

Наступні кроки (розумні)

«Неможливо виділити пам’ять» в Proxmox — не прокляття. Це ядро, яке відстоює межу, яку ви вже перейшли в політиці, конфігурації або очікуваннях.

1. Припиніть ставитись до max-пам’яті ВМ як до пропозиції. Зробіть її контрактом.
2. Використовуйте балонінг для еластичності, а не як заперечення. Ціль — низька, стеля — реалістична.
3. Дайте хосту аварійний фонд. Резервуйте RAM; додайте swap; тримайте ZFS ARC у своїй смузі.
4. Віддавайте перевагу передбачуваним вузлам над героїчним тюнінгом. Розділяйте навантаження, коли їх режими відмов різняться.
5. Опрацюйте це як процес. Додайте алерти на близькість до CommitLimit, швидкість swap-in/out, OOM-логи і розмір ARC.

Зробіть це — і наступного разу, коли Proxmox пожалкує про пам’ять, це буде тому, що ви дійсно використали все, а не тому що ваша
конфігурація розповіла чарівну історію, якій ядро відмовилось вірити.

Теза: ГГц були проксі, а не продуктом

NetBurst створювали під частоту. Не під «якісну частоту», не під «ефективну частоту», а під «поставте число на коробку
і нехай світ сперечається пізніше». Intel роками привчав покупців інтерпретувати тактову частоту як продуктивність.
Ринок винагороджував таке спрощення. А потім прийшли рахунки: надто глибокі конвеєри інструкцій, через які помилки передбачення
обходилися дорого, підсистема пам’яті, що не поспішала за ядром, і щільність потужності, яка перетворила дизайн шафи в хобі для
фанатів ОВК.

Це не була одна банальна помилка проєкту. Це був набір компромісів, які всі спиралися на одне припущення:
частота буде рости, а програмне забезпечення йтиме в ногу. Коли хоча б одне припущення провалилося — розгалужений код,
пам’яттєво важкі навантаження, реальні обмеження дата-центру — підхід провалився.

Якщо перекласти це на SRE-мову: NetBurst оптимізували під пік у ідеальних мікробенчмарках і карали хвостову латентність
під реальним сумішевим навантаженням. Так ви можете доставити багато розчарування.

Один раз я бачив, як слайд закупівель виставляв «3.0 GHz» ніби це SLA пропускної здатності.
Це як оцінювати мережу, рахуючи літери в «Ethernet».

Внутрішня будова NetBurst: конвеєр, який з’їв ваш IPC

Глибокі конвеєри: добре для частоти, погано для помилок

Класична історія NetBurst — «дуже глибокий конвеєр». Практична історія — «велика штрафна санкція за невірне передбачення».
Глибший конвеєр допомагає досягти вищих тактів, бо кожна стадія робить менше роботи. Мінус у тому, що ви збільшили відстань
між «ми здогадалися про гілку» і «з’ясували, що помилилися». Коли помилка трапляється, ви скидаєте багато роботи, що була в дорозі,
і починаєте заново.

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

Trace cache: хитро, складно і чутливо до навантаження

Trace cache у NetBurst зберігав декодовані мікрооперації (uops), а не сирі x86-інструкції. Це було розумно: декодування x86 —
нетривіальна справа, і кеш uop може зменшити навантаження на фронт-енд. Але це також зробило продуктивність залежною від потоку коду
і вирівнювання. Якщо ваш стрім інструкцій не «грає ввічливо» — багато гілок, дивне вирівнювання, погана локальність — trace cache
переставав бути благом і ставав ще одним місцем для промаху.

Ідея не була хибною; вона була ранньою й крихкою. Сьогодні uop-кеші успішні тому, що решта системи стала краще їх підгодовувати,
а компроміси потужність/продуктивність менеджаться з більшим тактом.

FSB і спільний northbridge: пункт пропуску пропускної здатності

Системи Pentium 4 залежали від front-side bus (FSB) до окремого контролера пам’яті (northbridge). Це означає, що ваше CPU-ядро швидке,
а пам’ять — «деінде», і кожен запит — подорож через спільну шину. Під навантаженням ця шина перетворюється на задачу планування.
Додайте кілька CPU — і це стає груповим проєктом.

Порівняйте це з пізнішими дизайнами з інтегрованими контролерами пам’яті (AMD зробив це раніше на x86; Intel пізніше).
Коли пам’ять ближче й має більше виділених шляхів, ви зменшуєте конкуренцію й знижуєте латентність. В продакшні латентність — валюта.
NetBurst витрачав її як турист.

SSE2/SSE3 ера: сильний у потоковій математиці, нерівний в інших задачах

NetBurst непогано справлявся з деякими векторизованими, потоковими навантаженнями — кодом, що міг передбачувано обробляти масиви
і уникати розгалуженої логіки. Ось чому бенчмарки могли виглядати нормально, якщо їх будували під тип навантаження, який машина любила.
Але реальні сервіси не ввічливі. Вони парсять, розгалужуються, виділяють пам’ять, блокуються й чекають на I/O.

NetBurst був еквівалентом двигуна, налаштованого під певний трек. Посадіть його в міський рух — і ви дізнаєтеся, що таке «крива крутного моменту».

Чому реальні навантаження болять: кеші, гілки, пам’ять і очікування

IPC — те, що ви відчуваєте; ГГц — те, чим хвалитеся

Інструкцій за такт (IPC) — грубий, але корисний проксі для «скільки роботи виконується за тик». NetBurst часто мав нижчий IPC,
ніж contemporaries у багатьох загальноцільових навантаженнях. Тому чіп працював на вищій частоті, щоб компенсувати.
Це може працювати — поки не перестає, тому що:

• Розгалужений код викликає помилки передбачення, які дорожчі в глибоких конвеєрах.
• Промахи кешу зупиняють виконання, а швидке ядро просто раніше доходить до паузи.
• FSB/латентність пам’яті стає жорсткою стіною, яку частотою не переломиш.
• Енергетика/терміки примушують троттлити, тож обіцяні ГГц — скоріше бажання.

Помилки передбачення гілок: податок латентності, який ви платите постійно

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

Стіна пам’яті: коли ядро випереджає систему

NetBurst міг швидко виконувати, якщо його підгодовували, але багато навантажень обмежені пам’яттю. Промах кешу — сотні тактів очікування.
Це число — не моральний провал; це фізика плюс топологія. Практичний ефект — CPU з вищими ГГц може виглядати гірше,
якщо він частіше натрапляє на затори пам’яті або не вміє їх приховувати.

З точки зору оператора це проявляється так: високе завантаження CPU, посередня пропускна здатність і система, яка здається «застряглою»
без очевидної насиченості I/O. Вона не застрягла. Вона чекає на пам’ять і б’ється сама з собою.

Спекулятивне виконання: корисне, але підсилює вартість помилок

Спекуляція — це спосіб, яким сучасні CPU отримують продуктивність: вгадати шлях, виконати його, викинути якщо помилилися.
У глибокому конвеєрі неправильний шлях дорогий. Ставка NetBurst була в тому, що кращі такти компенсують це. Іноді так і було.
Часто — ні.

Одна з найпростіших операційних інструкцій із епохи NetBurst: не приймайте «CPU завантажено на 95%» за «CPU виконує 95% корисної роботи».
Потрібні лічильники, а не відчуття.

Терміки та енергоспоживання: коли процесор торгується з фізикою

Щільність потужності стала функцією продукту (випадково)

NetBurst грівся. Особливо пізні моделі на базі Prescott, які стали легендарними через споживання і нагрівання. Тепло — це не лише рахунок за електрику;
це ризик надійності, шум вентиляторів і змінність продуктивності.

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

Троттлінг за температурою: невидимий гальмо

Коли CPU тротлиться, частота змінюється, виконання змінюється, і хвостова латентність вашого сервісу змінюється так, як ваші тести ніколи не моделювали.
У системах епохи NetBurst не рідкість було бачити «бенчмарк каже X», але «прод каже Y», бо умови у навколишньому середовищі не лабораторні.

Жарт №1: Prescott не був обігрівачем, але сидіти поруч зі стійкою в холодну пору стало трохи приємніше.

Надійність і експлуатація: гарячі системи старіють швидше

Конденсатори, VRM, вентилятори і материнські плати не люблять тепло. Навіть якщо вони виживають, вони «дрейфують». Цей дрейф породжує
випадкові помилки, спонтанні перезавантаження і фольклор «працює після пересідання». Це не містика; це термічне розширення, маргінальна подача живлення
і компоненти поза комфортною зоною.

Парафраз відомої ідеї, часто приписуваної В. Едвардсу Демінгу, чітко підходить для опсів: «Ви не можете керувати тим, чого не вимірюєте».
З NetBurst вам доводилося вимірювати терміки, бо CPU це робив точно.

Hyper-Threading: хороший трюк, що виявив погані припущення

Hyper-Threading (SMT) з’явився на деяких моделях Pentium 4 і був реально корисний за відповідних умов:
він міг заповнювати «прогалини» в конвеєрі, запускаючи інший потік, коли один застряг. Це звучить як безкоштовна продуктивність,
і іноді так воно й було.

Коли допомагало

• Змішані навантаження, де один потік чекає на промахи кешу, а інший може використати виконавчі блоки.
• Сервіси з інтенсивним I/O, де потік часто блокується, і накладні витрати планувальника керовані.
• Деякі ролі серверів, орієнтовані на пропускну здатність, з незалежними запитами і обмеженою конкуренцією за блокування.

Коли шкодило

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

Hyper-Threading на NetBurst — це мікрокосм правила: SMT робить добрі дизайни кращими, а крихкі — дивнішими.
Воно може підвищити пропускну здатність і водночас зробити латентність потворною. Якщо ваше SLO — p99, не «увімкніть і моліться».
Тестуйте з production-подібною конкуренцією і контролюйте хвіст.

Історичні факти, які мають значення (і кілька, що ще болять)

1. NetBurst дебютував з Willamette (Pentium 4, 2000), віддаючи пріоритет частоті над IPC.
2. Northwood покращив ефективність і такти, і став «менш болючим» Pentium 4 для багатьох покупців.
3. Prescott (2004) перейшов на тонший техпроцес, додав функції й став відомим через нагрів і енергоспоживання.
4. «Гонка ГГц» настільки вплинула на рішення про покупку, що «вища частота» часто перемагає кращу архітектуру в комерційних бесідах.
5. Доступ до пам’яті через FSB означав, що CPU конкурував за пропускну здатність по спільній шині до northbridge.
6. Trace cache зберігав декодовані мікрооперації, намагаючись зменшити накладні витрати декоду і постачати довгий конвеєр ефективно.
7. Hyper-Threading з’явився на вибраних моделях і міг підвищити пропускну здатність, використовуючи проста клітинка виконання.
8. Pentium M (з родоводу P6) часто перевершував Pentium 4 при значно нижчих тактах, особливо в реальних задачах.
9. Intel зрештою змінив курс від NetBurst; лінійка Core (на іншому фундаменті) замінила стратегію замість нескінченного її розвитку.

Три корпоративні міні-історії з передової

Міні-історія 1: інцидент через хибне припущення («ГГц = ємність»)

Середня компанія успадкувала парк застарілих веб-серверів і планувала швидке оновлення. Критерії вибору були надто прості: беріть
найбільш високочастотні Pentium 4 в межах бюджету. Нотатка закупівель буквально прирівнювала «+20% частоти» до «+20% запитів в секунду».
Ніхто не був злий умисно; вони були зайняті.

Розгортання пройшло гладко, поки трафік не досяг звичного піка. Завантаження CPU виглядало нормально — високо, але стабільно.
Мережа була під контролем. Диски не кричали. Але p95 латентність піднялася, потім p99 пішов вертикально. Команда on-call зробила те, що й роблять команди:
перезапустили сервіси, переклали трафік, звинуватили балансувальник і дивилися на графіки, поки графіки не стали дивитися назад.

Справжня проблема була в поведінці пам’яті. Навантаження змінилося з роками: більше персоналізації, більше логіки шаблонів, більше динамічної маршрутизації.
Це означало більше «pointer-chasing» і розгалужень. Нові сервери мали вищі частоти, але схожу латентність пам’яті і спільну топологію FSB, що ставала гіршою під конкуренцією.
Вони швидше доходили до тих самих пам’яттєвих пауз, а Hyper-Threading додав конкуренцію в найгірший момент.

Виправлення було не в «тонкій настройці Linux». Потрібно було перевизначити базову ємність, використовуючи тести, схожі на продакшн:
реальна конкуренція, фази з теплим/холодним кешем і хвостова латентність як ключова метрика. Компанія змінила склад парку:
менше «швидко-частотних» коробок, більше збалансованих вузлів з кращими підсистемами пам’яті. Вони також перестали використовувати ГГц
як основне число ємності. Дива трапляються, коли перестаєш собі брехати.

Міні-історія 2: оптимізація, що відкотилася («увімкнемо HT і отримаємо безкоштовну продуктивність»)

Інша команда запускала Java-сервіс з багатьма короткоживучими запитами. Вони увімкнули Hyper-Threading на всьому парку
і подвоїли потоки робітників, очікуючи лінійного зростання пропускної здатності. На синтетичних тестах це виглядало чудово. Потім прийшли інциденти:
спорадичні стрибки латентності, GC-паузи, що синхронізувалися із сплесками трафіку, і новий тип «повільно, але нічого не на межі».

Система не була голодною за CPU; вона була голодною за кешем і блокуваннями. Два логічні CPU ділили виконувальні ресурси і, що важливіше,
кеш і шляхи пропускної здатності пам’яті. Патерни алокацій і синхронізації JVM створювали «скакання» кеш-ліній, а додаткова конкуренція
підсилювала контенцію в гарячих точках, які раніше виглядали нешкідливо.

Вони намагалися виправити це, збільшуючи heap, потім прив’язуючи потоки, потім крутячи різні системні ручки. Деякі речі допомогли, більшість — ні.
Справжній виграш прийшов від кроку назад: ставитися до Hyper-Threading як до інструмента пропускної здатності з витратами на латентність.
Виміряйте витрати.

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

Міні-історія 3: нудна, але правильна практика, що врятувала день («термальний запас — це ємність»)

Команда фінансових сервісів запускала обчислювально-важкі нічні завдання на кластері, який включав вузли епохи Prescott Pentium 4.
Ніхто не любив ті коробки, але завдання були стабільні, і кластер «був достатнім». Тиха суперсила команди — вони розглядали середовище як частину ємності:
моніторинг температури впускного повітря, перевірки стану вентиляторів і оповіщення про індикатори троттлінгу.

Одного літа охолоджувальний блок деградував на вихідних. Не повний аут — просто поганий режим. В понеділок тривалість завдань повільно піднялася.
Більшість команд звинуватили би планувальник або базу даних. Ця команда помітила тонку кореляцію: вузли в одному ряду показували трохи вищі
температури і трохи нижчу ефективну частоту CPU.

Вони відвели ті вузли, перемістили завдання на прохолодніші стійки і відкрили запит у службі експлуатації з конкретними доказами.
Також тимчасово знизили конкуренцію на вузлах, щоб зменшити теплове навантаження і стабілізувати час виконання. Без драм, без героїзму,
без північних кімнат.

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

Практичні завдання: 12+ команд для діагностики «швидкий CPU, повільна система»

Це виконувано на типовому сервері Linux. Мета не «довести, що NetBurst поганий» у 2026 році.
Ви вчитеся розпізнавати ті самі режими відмов: зупинки в конвеєрі, стіна пам’яті, артефакти планування, термальне троттлінг
і оманлива завантаженість.

Завдання 1: Визначте CPU і чи є HT

cr0x@server:~$ lscpu
Architecture:            x86_64
CPU op-mode(s):          32-bit, 64-bit
CPU(s):                  2
Thread(s) per core:      2
Core(s) per socket:      1
Socket(s):               1
Model name:              Intel(R) Pentium(R) 4 CPU 3.00GHz
Flags:                   fpu vme de pse tsc ... ht ... sse2

Що це значить: «Thread(s) per core: 2» вказує на Hyper-Threading. Model name дає родину CPU.

Рішення: Якщо HT є, тестуйте з HT увімкненим/вимкненим для latency-чутливих сервісів; не вважайте, що це виграш.

Завдання 2: Перевірте поточну частоту і драйвер масштабування

cr0x@server:~$ grep -E 'model name|cpu MHz' /proc/cpuinfo | head
model name	: Intel(R) Pentium(R) 4 CPU 3.00GHz
cpu MHz		: 2793.000

Що це значить: CPU не на номінальній частоті. Може бути енергозбереження або троттлінг.

Рішення: Якщо частота несподівано низька під навантаженням, дослідіть governor і термічний троттлінг далі.

Завдання 3: Підтвердіть governor частоти CPU

cr0x@server:~$ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
ondemand

Що це значить: «ondemand» може знижувати частоту до росту навантаження; на старіших платформах він може повільно реагувати.

Рішення: Для вузлів з низькою латентністю розгляньте «performance» і повторіть тест; для батчів «ondemand» може бути прийнятним.

Завдання 4: Пошук термальних зон і температур

cr0x@server:~$ for z in /sys/class/thermal/thermal_zone*/temp; do echo "$z: $(cat $z)"; done
/sys/class/thermal/thermal_zone0/temp: 78000
/sys/class/thermal/thermal_zone1/temp: 65000

Що це значить: Температури в міліградусах Цельсія. 78000 = 78°C.

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

Завдання 5: Виявлення індикаторів троттлінгу в kernel логах

cr0x@server:~$ dmesg | grep -i -E 'throttl|thermal|critical|overheat' | tail
CPU0: Thermal monitoring enabled (TM1)
CPU0: Temperature above threshold, cpu clock throttled
CPU0: Temperature/speed normal

Що це значить: CPU знизив швидкість через нагрів. Ваша «загадкова» пропускна здатність може бути простою фізикою.

Рішення: Усуньте проблеми з повітряним потоком/охолодженням, зменшіть навантаження або зменшіть конкуренцію. Не підганяйте ПО під термічний дефект.

Завдання 6: Швидко перевірте чергу запуску і насиченість CPU

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
 2  0      0 120000  15000 210000    0    0     2     5  900 1400 85 10  5  0  0
 4  0      0 118000  15000 209000    0    0     0     8 1100 1800 92  7  1  0  0

Що це значить: «r» (черга запуску) постійно вище за кількість CPU вказує на конкуренцію за CPU. Низький «id» означає зайнятість.

Рішення: Якщо черга запуску висока, ви CPU-навантажені або застопорені. Далі: визначте, чи це обчислювальна, пам’яттєва чи блокувальна проблема.

Завдання 7: Знайдіть головних споживачів CPU і чи вони «крутяться» в циклі

cr0x@server:~$ top -b -n 1 | head -n 15
top - 12:14:01 up 21 days,  3:11,  1 user,  load average: 3.90, 3.60, 3.20
Tasks: 184 total,   2 running, 182 sleeping,   0 stopped,   0 zombie
%Cpu(s): 92.0 us,  7.0 sy,  0.0 ni,  1.0 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND
2174 app      20   0  1856m  612m  122m R  98.7  7.6  12:11.02 java

Що це значить: Високий user CPU все ще може бути «в очікуванні» (промахи пам’яті, промахи прогнозів гілок).
Низький «wa» не означає, що CPU не стоїть.

Рішення: Якщо один процес домінує, профілюйте його; якщо багато процесів рівномірно навантажують, підозрюйте системну контенцію або ефекти планувальника.

Завдання 8: Перевірте контекстні переключення і тиск переривань

cr0x@server:~$ pidstat -w 1 5
Linux 6.1.0 (server) 	01/09/2026 	_x86_64_	(2 CPU)

12:14:20      UID       PID   cswch/s nvcswch/s  Command
12:14:21     1001      2174   1200.00    350.00  java

Що це значить: Дуже високі контекстні переключення можуть означати забагато потоків, контенцію за блокування або інтенсивний таймер/IO churn.

Рішення: Якщо cswch/s високий і латентність погана, зменшіть кількість потоків або усуньте гарячі блокування перед купівлею заліза.

Завдання 9: Сигнали перевантаження пропускної здатності пам’яті через perf (cycles vs stalled frontend/backend)

cr0x@server:~$ sudo perf stat -p 2174 -e cycles,instructions,branches,branch-misses,cache-misses -a -- sleep 10
 Performance counter stats for 'system wide':

     32,100,000,000      cycles
     12,400,000,000      instructions              #    0.39  insn per cycle
      2,900,000,000      branches
        145,000,000      branch-misses             #    5.00% of all branches
        610,000,000      cache-misses

Що це значить: Низький IPC (0.39) плюс багато кеш/гілкових промахів вказують, що CPU зайнятий, але непродуктивний.

Рішення: Оптимізуйте шляхи коду для локальності/передбачуваності гілок або обирайте CPU з кращим IPC і обробкою пам’яті.

Завдання 10: Підтвердіть, чи ви дійсно обмежені I/O

cr0x@server:~$ iostat -xz 1 3
avg-cpu:  %user   %nice %system %iowait  %steal   %idle
          90.50    0.00    7.20    0.10    0.00    2.20

Device            r/s     w/s   rkB/s   wkB/s  rrqm/s  wrqm/s  %util  await
sda              2.10    1.00   45.0    28.0     0.0     0.2    3.0    1.2

Що це значить: Диск ледь завантажений; await низький. Це не вузьке місце зберігання.

Рішення: Перестаньте звинувачувати диски. Зосередьтесь на CPU/пам’яті/блокуваннях і профілюванні на рівні запиту.

Завдання 11: Перевірте тиск пам’яті і сторінкування (тихий вбивця продуктивності)

cr0x@server:~$ free -m
               total        used        free      shared  buff/cache   available
Mem:            2048        1720         120          12         207         210
Swap:           2048         900        1148

Що це значить: Використання swap може бути нормальним, але якщо при навантаженні відбувається активне сторінкування, будуть паузи і сплески.

Рішення: Якщо активність swap корелює з латентністю — зменшіть пам’ятний відбиток, додайте RAM або перерозподіліть навантаження.

Завдання 12: Підтвердьте активне сторінкування, а не просто використання swap

cr0x@server:~$ sar -B 1 5
Linux 6.1.0 (server) 	01/09/2026 	_x86_64_	(2 CPU)

12:15:10  pgpgin/s pgpgout/s   fault/s  majflt/s  pgfree/s pgscank/s pgsteal/s
12:15:11      0.00      0.00    820.00      0.00   1200.00      0.00      0.00
12:15:12     10.00     45.00   2100.00     15.00    400.00    800.00    300.00

Що це значить: Major faults (majflt/s) і сканування вказують на реальний тиск пам’яті.

Рішення: Сторінкування під навантаженням — це проблема ємності. Усуньте проблему з пам’яттю, а не з налаштуваннями CPU.

Завдання 13: Огляньте тиск планувальника одним поглядом

cr0x@server:~$ cat /proc/pressure/cpu
some avg10=12.34 avg60=10.01 avg300=8.55 total=987654321

Що це значить: CPU PSI «some» вказує час, який задачі проводять в очікуванні CPU-ресурсів.

Рішення: Якщо PSI росте разом з латентністю, вам потрібен більш ефективний CPU (IPC), менше runnable-потоків або політика зниження навантаження.

Завдання 14: Виявлення контенції за блокуваннями (часто діагностують як «повільний CPU»)

cr0x@server:~$ sudo perf top -p 2174
Samples: 31K of event 'cpu-clock', 4000 Hz, Event count (approx.): 7750000000
Overhead  Shared Object        Symbol
  12.40%  libc.so.6            [.] pthread_mutex_lock
   9.10%  libjvm.so            [.] SpinPause

Що це значить: Час витрачається на блокування і спінінг, а не на корисну роботу.

Рішення: Зменшіть контенцію (шардінг локів, зменшення потоків, виправлення гарячих критичних секцій). Більше ГГц вас не врятують.

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

cr0x@server:~$ taskset -c 0 sysbench cpu --cpu-max-prime=20000 run
CPU speed:
    events per second:  580.21

General statistics:
    total time:                          10.0004s
    total number of events:              5804

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

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

Жарт №2: Якщо ваш план — «додайте потоків, поки не стане швидше», ви не оптимізуєте — ви закликаєте демони контенції.

Швидка діагностика: що перевірити першим/другим/третім

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

Перше: переконайтеся, що CPU, який ви думаєте, — це той, що у вас є

1. Частота під навантаженням: перевірте /proc/cpuinfo MHz, governor та dmesg на предмет троттлінгу.
2. Терміки: перегляньте термальні зони та стан вентиляторів/повітряного потоку через наявну телеметрію.
3. Віртуалізація: підтвердіть, що вас не обмежують квоти CPU або «шумні сусіди» (PSI, cgroups).

Мета: виключити «CPU буквально не працює на очікуваній швидкості» за 5 хвилин.

Друге: визначте, чи ви обчислювально-зв’язні, пам’яттєво-зв’язні чи контенційно-зв’язані

1. Черга запуску і PSI: vmstat та /proc/pressure/cpu для очікування CPU.
2. perf IPC: cycles vs instructions; низький IPC вказує на зупинки/промахи.
3. Сигнали контенції за локами: perf top, pidstat контекстні переключення, дампи потоків додатка.

Мета: класифікувати проблему. Ви не зможете виправити те, що не назвали.

Третє: підтвердіть, що це не I/O і не сторінкування

1. Диск: iostat -xz для завантаження і await.
2. Сторінкування: sar -B для major faults і сканування.
3. Мережа: перевірте втрати/помилки і черги (не показано вище, але обов’язково).

Мета: припинити марнувати час на невірну підсистему.

Четверте: вирішіть, чи це проблема підходу апаратного забезпечення або ПО

• Якщо IPC низький через промахи кешу і помилки гілок — потрібна краща локальність або CPU з вищим IPC, а не більше ГГц.
• Якщо домінує контенція, зменшіть конкурентність або переробіть гарячі шляхи — апаратне оновлення не вирішить серіалізований код.
• Якщо є троттлінг, спочатку ліквідуйте проблеми охолодження і подачі живлення; інакше всі інші зміни стануть шумом.

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

1) Симптом: «CPU завантажено, але пропускна здатність посередня»

Корінна причина: Низький IPC через промахи кешу, помилки передбачення гілок або латентність пам’яті; CPU виглядає зайнятим, але застопореним.

Виправлення: Використайте perf stat, щоб підтвердити низький IPC і високі промахи; оптимізуйте локальність, зменшіть pointer-chasing і профілюйте гарячі шляхи коду. Якщо купуєте залізо, віддавайте пріоритет IPC і підсистемі пам’яті, а не тактовій частоті.

2) Симптом: «Сплески латентності з’являються лише в теплі після обіду / після заміни вентилятора»

Корінна причина: Троттлінг за температурою або поганий повітряний потік, що спричиняє падіння частоти і джиттер.

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

3) Симптом: «Ми увімкнули Hyper-Threading і p99 стало гірше»

Корінна причина: Конкуренція за спільні ресурси виконання/кеша, збільшена конкуренція за блокування або насичення пропускної здатності пам’яті.

Виправлення: A/B тест HT увімкн./вимкн. з production-подібною конкуренцією; зменшіть кількість потоків; виправте гарячі блокування; розглядайте HT лише для задач орієнтованих на пропускну здатність або I/O-стримируваних навантажень.

4) Симптом: «Мікробенчмарки покращилися, але продакшн став повільнішим»

Корінна причина: Мікробенчмарки — обчислювальні і передбачувані; продакшн — розгалужений і пам’яттєво важкий. Дизайн NetBurst винагороджує перше і карає друге.

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

5) Симптом: «Load average зріс після того, як ми «оптимізували», додавши потоки»

Корінна причина: Перепідписка і контенція; більше runnable-потоків збільшує накладні витрати планування і блокувань.

Виправлення: Використайте pidstat для вимірювання контекстних переключень, perf top для символів, пов’язаних з блокуваннями, і зменшіть конкуренцію. Додавайте паралелізм тільки там, де робота є паралельною і вузьке місце зміщується.

6) Симптом: «Оновлення CPU не допомогло базі даних»

Корінна причина: Навантаження обмежене латентністю пам’яті або пропускною здатністю пам’яті (промахи буферного пулу, pointer-chasing у B-деревах, кеш-промахи).

Виправлення: Збільшіть ефективний показник попадань в кеш (індекси, форма запитів), додайте RAM, зменшіть робочий набір і виміряйте кеш-промахи/IPC. Не кидайте ГГц на стіну пам’яті.

7) Симптом: «Все виглядає нормально, окрім випадкових пауз і таймаутів»

Корінна причина: Сторінкування, паузи GC або сплески контенції, які не показуються як сталий рівень завантаження.

Виправлення: Перевірте major faults, PSI і метрики пауз додатка. Усуньте тиск пам’яті і зменшіть підсилення хвоста (таймаути, повторні спроби, «thundering herd»).

Чеклисти / покроковий план

Чеклист A: Купівля обладнання без повторення помилки NetBurst

1. Визначайте успіх за латентністю і пропускною здатністю (p50/p95/p99 + стабільні RPS), а не за тактовою частотою.
2. Вимірюйте IPC-проксі: використовуйте perf на репрезентативних навантаженнях; порівнюйте cycles/instructions і рівні промахів.
3. Моделюйте поведінку пам’яті: розмір робочого набору, показник попадань у кеш, очікувана конкуренція і потреби в пропускній здатності.
4. Перевіряйте терміки: тестуйте в стійці, з реалістичною температурою навколишнього середовища і профілем вентиляторів.
5. Тестуйте вплив SMT/HT: увімкн./вимкн. з реальними кількостями потоків і відстеженням хвостової латентності.
6. Віддавайте перевагу збалансованим системам: кількість каналів пам’яті, розміри кешу і міжз’єднання важливі так само, як і частоти ядер.

Чеклист B: Коли розгортання «швидшого CPU» робить продакшн повільнішим

1. Підтвердіть частоту і троттлінг (governor, температури, dmesg).
2. Порівняйте perf IPC і рівні промахів до/після.
3. Перевірте кількість потоків і контекстні переключення; першим відкотіть зміни з «подвійними потоками».
4. Перевірте тиск пам’яті і сторінкування; негайно виправте major faults.
5. Шукайте регресії контенції за локами, введені новою конкуренцією.
6. Якщо неясно, захопіть flame graph або профіль і розгляньте його як хроніку інциденту.

Чеклист C: Стабілізувати хвостову латентність на старих, гарячих, частотозалежних системах

1. Зменшіть конкуренцію так, щоб відповідала кількості ядер (особливо з HT) і спостерігайте вплив на p99.
2. Прив’язуйте критичні потоки тільки якщо ви розумієте топологію; інакше прив’язка може закутати вас у кут.
3. Тримайте governor CPU послідовним (часто «performance» для вузлів з критичною латентністю).
4. Забезпечте термальний запас: надсилайте оповіщення про температуру і події троттлінгу, а не лише про завантаження CPU.
5. Оптимізуйте гарячі шляхи для локальності; по можливості усуньте непередбачувані гілки.
6. Введіть зворотний тиск і розумні таймаути, щоб уникнути лавини повторних спроб.

Питання та відповіді

1) Чи був Pentium 4 справді «поганим», чи просто його неправильно розуміли?

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

2) Чому вищі ГГц не перетворювалися на вищу продуктивність?

Бо продуктивність залежить від корисної роботи за такт (IPC) і від того, як часто ви зупиняєтеся через пам’ять, гілки і контенцію.
NetBurst збільшував кількість тактів, але часто зменшував корисну роботу за такт у реальних навантаженнях.

3) Який операційний урок для сучасних систем?

Не приймайте заголовкову метрику як істину. Для CPU це ГГц; для зберігання — «IOPS»; для мережі — «Gbps».
Завжди запитуйте: при якій латентності, з якою конкуренцією і як поводиться хвіст?

4) Чи «виправив» Hyper-Threading NetBurst?

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

5) Чому Pentium M іноді обганяв Pentium 4 при значно нижчих частотах?

Pentium M (з роду P6) наголошував на IPC і ефективності. У розгалужених, чутливих до кешу навантаженнях вищий IPC і краща ефективність
часто перемагають сирі такти, особливо коли висока частота спричиняє енергетичні і термічні троттлінги.

6) Як визначити, чи моє навантаження обмежене пам’яттю, а не CPU?

Шукайте низький IPC з високими промахами кешу в perf, а також обмежений ефект від додавання ядер або підвищення частоти.
Ви також побачите плато пропускної здатності при «завантаженому» CPU. Це зазвичай стіна пам’яті або стіна контенції.

7) Чи реально важливий троттлінг за температурою?

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

8) Що потрібно бенчмаркувати, щоб уникнути помилок ери ГГц?

Бенчмаркуйте фактичний сервіс: реальна суміш запитів, реальний розмір даних, реальна конкуренція і віддавайте звіт по p95/p99 та пропускній здатності.
Додайте фазу «холодного кешу» і тривалий прогін, достатній, щоб система «пропіділася» по теплу.

9) Чи є сучасні аналоги пастки NetBurst?

Є. Будь-коли, коли ви оптимізуєте під один піковий показник ціною системної поведінки: турбо-частоти без термічного бюджету,
бенчмарки зберігання, що ігнорують fsync-латентність, або тестування мережі, що ігнорує втрати пакетів під навантаженням.
Патерн однаковий: пік виграє на слайді, хвіст втрачає клієнта.

Висновок: що робити, коли вам знову продають ГГц

NetBurst — це не лише ретро-трівіал про CPU. Це чітка історія про інцентиви, вимірювання і ціну ставки на одне число.
Intel оптимізував під частоту, бо ринок платив за частоту. Навантаження, що мали значення —
розгалужений серверний код, пам’яттєво важкі системи, стійки з термічними обмеженнями — виставили рахунок.

Практичні кроки далі — нудні, і саме тому вони працюють:

1. Визначайте продуктивність через хвостову латентність, а не пікову пропускну здатність і тим паче не через частоту.
2. Інструментуйте вузькі місця: perf-лічильники, PSI, метрики сторінкування і термічні/троттлінгові сигнали.
3. Бенчмаркуйте як продакшн: конкуренція, розмір даних, поведінка кешу, прогон з нагрівом і реалістичні суміші запитів.
4. Розглядайте терміки як ємність: якщо CPU тротлиться, ваша архітектура «обмежена охолодженням». Визнайте це.
5. Сумнівайтеся в «безкоштовній продуктивності»: HT/SMT, агресивна конкуренція і мікро-оптимізації, що ігнорують контенцію.

Якщо запам’ятати лише одне: такти — це компонент, а не гарантія. Система — це продукт. Експлуатуйте її відповідно.