Ubuntu 24.04: Продуктивність упала після оновлення — перші 6 перевірок, що виявляють винуватця

November 8, 2025 • February 3, 2026 • Читання: 6 хв • Views: 12

Було корисно?

Класика: ви патчуєте нормально працюючий Ubuntu, перезавантажуєтеся — і раптом ваша «швидка» система ніби тягне по вологому цементу. Дашборди підвисають. Деплої тягнуться. Графіки I/O нагадують кардіограму. Перший інстинкт — звинуватити «оновлення» як єдину велику причину. Це емоційно задовольняє. Але операційно марно.

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

Швидкий план діагностики (що перевірити насамперед)

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

1) Підтвердьте, що змінилося (ядро, microcode, драйвери, служби)

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

2) Класифікуйте уповільнення: CPU-bound vs I/O-bound vs memory-bound

Якщо load високий і iowait високий — зазвичай це поведінка стореджу або файлової системи.
Якщо CPU завантажений в user/system при низькому iowait — то це безконтрольний процес, syscall-шторм або «корисний» новий демон.
Якщо бачите інтенсивний swap — це тиск пам’яті або регресія робочого набору.

3) Визначте процес-винуватець та підтвердіть його кореляцію зі сповільненням

Не зупиняйтеся на «top каже X використовує CPU». Перевірте, чи заблокований він на диску або чекає на блокування.

4) Заміряйте латентність диску (не пропускну здатність) та черги

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

5) Перевірте масштабування частоти CPU та енергопрофілі

Після оновлень значення за замовчуванням та поведінка драйверів, що стосуються живлення, можуть змінитися. Якщо CPU застряг у powersave, усе відчувається «таємничо повільним».

6) І лише потім: порийтеся в kernel logs, регресіях драйверів, AppArmor відмовах і зростанні journald/log

Це часті проблеми на Ubuntu 24.04, бо платформа сучасна й активна: нові ядра, нові драйвери й нові політики.

Одна перефразована ідея від Gene Kim (автора по DevOps), яку командам операцій варто начепити в рунебуках: оптимізуйте для швидкого виявлення і швидкого відновлення, а не для ідеального запобігання. Саме такий підхід допомагає зберегти спокій у сезоні «все стало повільним».

Перші 6 перевірок, що зазвичай виявляють винуватця

Перевірка 1: Чи дійсно ви запущені під тим ядром, яке вважаєте?

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

Перевірка 2: Чи система I/O-bound (iowait, латентність диску, глибина черги)?

I/O регресії — найпоширеніше джерело скарг «вся машина повільна», бо вони вражають усе: завантаження, встановлення пакетів, коміти баз даних, рестарти сервісів, запис логів. Після оновлення типовими тригерами є:

Опції монтування файлової системи змінилися або «покращилися».
Обсяг журналів journald зріс і тепер синхронізація стала інтенсивнішою.
Snap refresh почався в невдалий час.
Зміни драйвера стореджу (NVMe/APST, scheduler, multipath).

Перевірка 3: Чи тиск пам’яті змушує до reclaim або swap?

Ubuntu 24.04 комфортно працює на сучасному залізі, але навантаження може бути іншим. Оновлення пакету може змінити значення кешів за замовчуванням, додати нову службу або оновити рантайм, що збільшує пам’ять. Коли починається тривалий reclaim, ви помітите «випадкову» повільність: усе чекає на управління пам’яттю.

Перевірка 4: Чи змінилося масштабування частоти CPU / режим енергоспоживання?

На ноутбуках це очевидно. На серверах — підступніше. Зміни у профілях живлення, налаштуваннях BIOS, microcode або поведінці драйвера можуть тримати ядра на низькій частоті під навантаженням або змушувати їх коливатися. Виглядає як «CPU на 40%, але запити повільні».

Перевірка 5: Чи служба була увімкнена, переконфігурована або почала трешитись?

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

Перевірка 6: Чи kernel логи показують помилки, скидання або відмови політик?

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

Анекдот #1: Єдина річ більш стабільна, ніж «все стало повільним після оновлення», — це «вона вже була повільною, оновлення просто привернуло увагу».

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

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

Задача 1: Підтвердити ядро, час завантаження та базову платформу

cr0x@server:~$ uname -a
Linux server 6.8.0-41-generic #41-Ubuntu SMP PREEMPT_DYNAMIC x86_64 GNU/Linux
cr0x@server:~$ uptime -s
2025-12-29 02:14:03

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

Рішення: Якщо регресія почалась лише після перезавантаження — підозрюйте ядро/драйвери/служби. Якщо раніше — дивіться на userspace оновлення або фонві задачі (snap refresh, індексатори, зростання логів).

Задача 2: Перелік нещодавніх оновлень, щоб скорелювати початок уповільнення

cr0x@server:~$ grep -E " upgrade | install " /var/log/dpkg.log | tail -n 15
2025-12-28 21:05:12 upgrade linux-image-6.8.0-41-generic:amd64 6.8.0-40.40 6.8.0-41.41
2025-12-28 21:05:20 upgrade linux-modules-6.8.0-41-generic:amd64 6.8.0-40.40 6.8.0-41.41
2025-12-28 21:06:01 upgrade systemd:amd64 255.4-1ubuntu8 255.4-1ubuntu9
2025-12-28 21:06:29 upgrade openssh-server:amd64 1:9.6p1-3ubuntu13 1:9.6p1-3ubuntu14

Значення: Показує, що змінилося нещодавно. Оновлення ядра та systemd — високоефективні підозрювані, бо торкаються завантаження, управління пристроями, cgroups і логування.

Рішення: Виберіть 1–3 «найпідозріліші» оновлення і перегляньте їхні changelog щодо впливу на ваше середовище (особливо ядро та стек сторедж/мережі).

Задача 3: Перевірити systemd на наявність помилок і повільних сервісів при завантаженні

cr0x@server:~$ systemctl --failed
  UNIT                 LOAD   ACTIVE SUB    DESCRIPTION
● fwupd.service         loaded failed failed Firmware update daemon
cr0x@server:~$ systemd-analyze blame | head
35.114s snapd.seeded.service
12.892s dev-nvme0n1p2.device
 8.310s systemd-journald.service
 6.942s NetworkManager-wait-online.service

Значення: Помилкові юніти можуть викликати цикли повторних спроб. Вивід blame показує, що «їсть» час під час старту; це також підказка щодо runtime-повільності (наприклад, коли journald займає багато часу, або пристрої повільно з’являються).

Рішення: Якщо юніт падає або рестартує — виправте його в першу чергу. Якщо snapd seeding домінує й співпадає з уповільненням — ймовірно фонова I/O активність.

Задача 4: Визначити поточних найбільших споживачів (CPU, пам’ять) без гадань

cr0x@server:~$ ps -eo pid,comm,%cpu,%mem,etimes,state --sort=-%cpu | head -n 12
  PID COMMAND         %CPU %MEM ELAPSED S
 2143 node            280.5  6.1   15421 R
  982 systemd-journal   32.1  0.3   86322 R
 1777 snapd            24.8  0.6   74210 S
 1460 postgres         18.2 12.4   99111 S

Значення: Отримуєте ранжований список з часом і станом. «R» означає running; «D» (uninterruptible sleep) часто означає, що процес застряг на I/O.

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

Задача 5: Перевірити load, iowait і переключення контекстів

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  10240 812344  92160 6123456   0    0   112   205 3210 5400 18  6 70  6  0
 6  3  10304  92344  90240 5943120  40   88  9800  6100 5400 8800 22  9 40 29  0
 4  2  10496  74320  90112 5901220  52  140 10400  7200 5900 9400 18 10 41 31  0
 7  4  10560  70212  90224 5899900  60  160 12000  8400 6100 9900 16 11 38 35  0
 3  1  10560  69300  90240 5898000   0    0  2100  1900 4100 7200 14  8 70  8  0

Значення: Слідкуйте за wa (I/O wait) і swap in/out (si/so). Тривалий swap означає тиск пам’яті. Тривалий високий wa — латентність/черги стореджу.

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

Задача 6: Заміряти латентність диску та завантаження по пристроях (щоб дізнатись правду)

cr0x@server:~$ iostat -xz 1 3
Linux 6.8.0-41-generic (server)  12/29/2025  _x86_64_  (16 CPU)

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
          19.20    0.00    7.10   28.40    0.00   45.30

Device            r/s     w/s   rKB/s   wKB/s  await  aqu-sz  %util
nvme0n1         120.0   310.0  6400.0 41000.0  18.40    6.20  98.00
sda               0.0     2.0     0.0    48.0   1.10    0.01   0.20

Значення: await — середня латентність I/O. aqu-sz і %util показують черги й насичення. Пристрій на ~98% util з ростом await — пляшкова шийка.

Рішення: Якщо основний диск насичений — знайдіть, хто читає/пише, і чи це очікуване (навантаження БД) чи нове (шторм логів, snap refresh, індексація, backup agent).

Задача 7: Атрибутувати диск I/O процесам (хто б’є по диску)

cr0x@server:~$ sudo iotop -oPa
Total DISK READ: 28.40 M/s | Total DISK WRITE: 41.10 M/s
  PID  PRIO  USER     DISK READ  DISK WRITE  SWAPIN  IO>    COMMAND
  982 be/4  syslog      0.00 B/s   9.50 M/s  0.00 % 95.00% systemd-journald
 1777 be/4  root        0.00 B/s   7.20 M/s  0.00 % 80.00% snapd
 2143 be/4  app         6.10 M/s   2.40 M/s  0.00 % 35.00% node /srv/app/server.js

Значення: Ви бачите, які процеси зараз роблять реальний I/O. Високий IO> вказує, що процес чекає на I/O більше, ніж виконується.

Рішення: Якщо journald багато пише — перевірте швидкість логів і налаштування збереження. Якщо snapd інтенсивно пише під час refresh/seeding — заплануйте або контролюйте вікна оновлень.

Задача 8: Перевірити розмір і швидкість journald (шторм логів — шторм продуктивності)

cr0x@server:~$ journalctl --disk-usage
Archived and active journals take up 6.2G in the file system.
cr0x@server:~$ sudo journalctl -p warning -S "1 hour ago" | tail -n 8
Dec 29 09:12:41 server kernel: nvme nvme0: I/O 123 QID 7 timeout, aborting
Dec 29 09:12:43 server kernel: nvme nvme0: Controller reset, clearing queue
Dec 29 09:12:44 server systemd-journald[982]: Missed 312 log messages due to rate-limiting

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

Рішення: Якщо бачите таймаути/скидання стореджу — це зона firmware/driver. Якщо journald великий і швидко росте — обмежуйте шумні сервіси і встановіть розумну ретенцію.

Задача 9: Переглянути kernel ring buffer на помилки стореджу та мережі

cr0x@server:~$ dmesg -T | egrep -i "nvme|reset|timeout|error|ext4|xfs|zfs|link is down|iommu" | tail -n 25
[Mon Dec 29 09:12:41 2025] nvme nvme0: I/O 123 QID 7 timeout, aborting
[Mon Dec 29 09:12:43 2025] nvme nvme0: Controller reset, clearing queue
[Mon Dec 29 09:12:44 2025] EXT4-fs (nvme0n1p2): warning: mounting fs with errors, running e2fsck is recommended
[Mon Dec 29 09:13:02 2025] igb 0000:03:00.0 eno1: Link is Down

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

Рішення: Помилки стореджу: припиніть налаштування і почніть стабілізувати (firmware, кабелі, BIOS, регресія ядра). Флапи лінку: перевірте драйвер/firmware NIC і порт комутатора.

Задача 10: Перевірити частоту CPU та governor (мовчазне уповільнення)

cr0x@server:~$ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
powersave
cr0x@server:~$ grep -E "model name|cpu MHz" /proc/cpuinfo | head -n 6
model name	: Intel(R) Xeon(R) Silver 4314 CPU @ 2.40GHz
cpu MHz		: 800.028
model name	: Intel(R) Xeon(R) Silver 4314 CPU @ 2.40GHz
cpu MHz		: 800.031

Значення: Якщо ви зафіксовані на ~800 MHz під навантаженням — це не «поганий день», це обмеження по енергоспоживанню. Оновлення можуть змінити поведінку енергопрофілів або виявити обмеження BIOS.

Рішення: На серверах зазвичай хочуть передбачуваної продуктивності: встановіть відповідний governor (часто performance) або використайте tuned-профіль, який відповідає вашим SLO.

Задача 11: Перевірити, чи тиск пам’яті реальний (reclaim, swap, ризики OOM)

cr0x@server:~$ free -h
               total        used        free      shared  buff/cache   available
Mem:            62Gi        49Gi       1.2Gi       1.1Gi        12Gi       6.8Gi
Swap:          8.0Gi       2.4Gi       5.6Gi
cr0x@server:~$ cat /proc/pressure/memory
some avg10=0.25 avg60=0.18 avg300=0.12 total=92841712
full avg10=0.03 avg60=0.01 avg300=0.01 total=3812233

Значення: Низький «available» плюс використаний swap може бути нормальним для деяких навантажень, але PSI (/proc/pressure) каже, чи задачі чекають на пам’ять. full pressure > 0 свідчить про серйозну конкуренцію.

Рішення: Якщо PSI пам’яті зростає під час інцидентів — оптимізуйте пам’ять, обмежте розгул служб або додайте RAM. Якщо swap треше — зменшіть swappiness або виправте навантаження.

Задача 12: Перевірити cgroup-обмеження або зміни в контейнерах після оновлення

cr0x@server:~$ systemctl status docker --no-pager | sed -n '1,12p'
● docker.service - Docker Application Container Engine
     Loaded: loaded (/usr/lib/systemd/system/docker.service; enabled; vendor preset: enabled)
     Active: active (running) since Mon 2025-12-29 02:16:12 UTC; 7h ago
cr0x@server:~$ cat /sys/fs/cgroup/cgroup.controllers
cpuset cpu io memory hugetlb pids rdma misc

Значення: Ubuntu 24.04 у типових налаштуваннях використовує cgroup v2 за замовчуванням. Оновлення інколи змінюють припущення рантаймів контейнерів. Додаток може опинитися CPU-throttled або I/O-limited політикою cgroup, що виглядає як «хост у порядку, але додаток повільний».

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

Задача 13: Перевірити опції монтування і стан файлової системи (особливо після змін ядра)

cr0x@server:~$ findmnt -no SOURCE,TARGET,FSTYPE,OPTIONS /
/dev/nvme0n1p2 / ext4 rw,relatime,errors=remount-ro
cr0x@server:~$ sudo tune2fs -l /dev/nvme0n1p2 | egrep -i "Filesystem state|Errors behavior|Default mount options"
Filesystem state:         clean
Errors behavior:          Remount read-only
Default mount options:    user_xattr acl

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

Рішення: Якщо ФС повідомляє про помилки або ядро записало warnings — заплануйте вікно техобслуговування для fsck і розслідуйте стабільність стореджу. Не «оптимізуйте» зламаний диск.

Задача 14: Швидка перевірка мережевого шляху (бо латентність може маскуватися під CPU-проблеми)

cr0x@server:~$ ip -s link show eno1 | sed -n '1,12p'
2: eno1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DEFAULT group default qlen 1000
    link/ether 3c:fd:fe:aa:bb:cc brd ff:ff:ff:ff:ff:ff
    RX:  bytes packets errors dropped  missed   mcast
    918273645  821933     12      98       0    1203
    TX:  bytes packets errors dropped carrier collsns
    827364554  801102      0       0       7       0
cr0x@server:~$ ss -s
Total: 1048 (kernel 0)
TCP:   812 (estab 621, closed 134, orphaned 0, synrecv 0, timewait 134/0), ports 0
Transport Total     IP        IPv6
RAW       0         0         0
UDP       18        12        6

Значення: RX/TX помилки та carrier issues можуть гальмувати продуктивність або створювати шторм повторних спроб. ss -s дає швидкий огляд стану сокетів.

Рішення: Якщо помилки зросли після оновлення — підозрюйте регресію драйвера/firmware або зміни offload. Перевірте лічильники на комутаторі і розгляньте фіксацію/відкат драйвера NIC за наявності доказів.

Цікаві факти та контекст (чому це повторюється)

Оновлення ядра змінюють більше, ніж «ядро». Вони приносять нові драйвери пристроїв, правки планувальника, поведінку блочного шару й інколи нові значення за замовчуванням. Шляхи стореджу й NIC особливо чутливі.
Планувальники I/O в Linux еволюціонували радикально. Сучасні ядра часто дефолтять на mq-deadline або none для NVMe; старі гайди щодо CFQ — артефакти іншої епохи.
Управління живленням NVMe має історію сюрпризів. Функції на кшталт APST корисні для енергоощадження, але прошивки можуть спричиняти латентні спайки або скидання на конкретному обладнанні.
systemd поступово поглинув обов’язки, що раніше робили окремі демони. Це добре для цілісності, але означає, що зміни в systemd/journald можуть виявитися як поведінка продуктивності після оновлення.
«iowait» — не міра швидкості диску. Це час CPU, витрачений на очікування завершення I/O. Це симптом, а не корінна причина сам по собі.
cgroup v2 тепер дефолт у багатьох дистрибутивах. Він покращує контроль ресурсів, але оновлення можуть виявити раніше приховане обмеження або невірно налаштовані ліміти, особливо в контейнерних середовищах.
Транзакційна модель Snap жертвує трохи I/O заради надійності. Більше метаданих і більше записів під час оновлень — усвідомлений вибір дизайну; помітно на зайнятих або малих дисках.
Журнальні файлові системи віддають пріоритет консистентності. ext4 і XFS створені, щоб пережити краші, але деякі робочі навантаження разом із сильним логуванням роблять поведінку комітів помітною як латентність.
Microcode оновлення можуть змінити поведінку продуктивності. Вони фіксують реальні проблеми безпеки й стабільності, але також можуть змінити boost-поведінку або полегшити мітобігові помилки CPU, що впливає на хвостову латентність.

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

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

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

Графіки показали, що хости не були CPU-наповненими. Пам’ять була комфортною. Але tail latency була зруйнована. Логи були повні попереджень, які ніхто не встиг прочитати. Під тиском вони зробили те, що команди роблять у стресі: додали більше реплік. Стало гірше — система стала більш паралельною по I/O і загнала сторедж у глибші черги.

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

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

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

Інша команда помітила спайк записів диску після оновлення флоту. Вони помітили, що journald виріс і вирішили «оптимізувати»: перемістити журнал на найшвидший пристрій і збільшити ретенцію «щоб краще дебажити». Здавалося розумним і навіть отримало підтримку в чаті.

Через тиждень найшвидший пристрій став найзавантаженішим. Їхня база даних ділила той самий NVMe. У пікові години латентність росла, p99 запитів погіршувалися. База не втрачала пропускну здатність, вона програвала у «лотереї латентності», бо логування стало постійним фоновим писачем з синхронними точками.

Провал полягав не в journald як такому — а в поєднанні підвищеного обсягу логів від нового говірливого сервісу, подовженої ретенції та колокації із latency-sensitive стореджем. Вони «оптимізували для I/O локальності» і отримали «I/O contention».

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

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

Одна організація мала правило: кожне вікно патчів породжує «запис змін» з трьома артефактами — версія ядра, топ-20 змінених пакетів і 10-хвилинний снапшот базових метрик продуктивності (CPU, memory PSI, iostat latency, мережеві помилки). Це не було гламуру. Ніхто не отримував підвищення за це. Але інциденти коротшали.

Після оновлення набір API-серверів уповільнився. On-call витягнув попередній базовий снапшот з останнього вікна і одразу побачив новий патерн: частота CPU була нижчою під навантаженням і підвищилась кількість переключень контекстів. Диск не змінювався, мережа чиста. Клас пляшкової шийки — поведінка CPU, а не сторедж.

Корінь був у зміні енергопрофілю після не пов’язаного з тим пакету оновлення. Вони не витрачали години на звинувачення ядра або переслідування фантомного I/O. Відновили профіль продуктивності, перевірили масштабування частоти під навантаженням і закрили інцидент до того, як бізнес підняв шум.

Це той практичний підхід, що звучить як паперова робота, поки не врятує день: фіксуйте baseline, поки система здорова. Інакше ви сперечатиметесь зі своєю пам’яттю, а вона ненадійна як моніторинг.

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

Це патерни, які я регулярно бачу після оновлень Ubuntu, включно з 24.04. Симптоми — те, що люди повідомляють. Корінна причина — що насправді відбувається. Виправлення — конкретне й тестоване.

1) «Load високий, але CPU використання низьке»

Симптом: Середнє навантаження стрибає; top показує CPU переважно вільні; застосунки зависають.
Корінь: Потоки заблоковані у uninterruptible I/O sleep (латентність стореджу або скидання драйвера).
Виправлення: Запустіть iostat -xz і dmesg -T. Якщо бачите NVMe таймаути/скидання — стабілізуйте firmware/параметри ядра; якщо латентність реальна — знайдіть писача через iotop.

2) «Все повільніше після перезавантаження, але з часом покращується»

Симптом: Перша година після перезавантаження жахлива; потім прийнятно.
Корінь: Пост-оновлювальні задачі: snap seeding/refresh, rebuild кешів, updatedb, генерація мовних пакетів, скан контейнерних образів.
Виправлення: Використайте systemd-analyze blame, journalctl і iotop щоб виявити churn. Перенесіть ці задачі або обмежте їх. Не робіть бенчмарків під час «першого завантаження після оновлення».

3) «Пропускна здатність диску виглядає нормально, але застосунок таймаутить»

Симптом: MB/s високі; дашборди показують здорову пропускну здатність; p99 латентність вибухає.
Корінь: Латентність і черги, а не пропускна здатність. Мішані читання/записи плюс синк-важке логування створюють довгі хвости.
Виправлення: Сфокусуйтеся на await, aqu-sz і per-process I/O. Зменшіть частоту sync, розділіть голосні писачі і перевірте опції монтування ФС.

4) «CPU лише 30%, але запити повільні»

Симптом: Достатньо ресурсів; все одно повільно.
Корінь: CPU застряг на низькій частоті (governor/енергопрофіль) або тротлінг через обмеження cgroup.
Виправлення: Перевірте scaling_governor і CPU MHz; перевірте ліміти контейнерів; виправте профіль енергоспоживання або політику cgroup.

5) «Після оновлення диск постійно зайнятий, але нічого «не робить»»

Симптом: Високе завантаження диску в ідлі; вентилятори ревуть; інтерактивна оболонка лагає.
Корінь: Зростання journald, шторм логів, snap refresh або новий індексатор/сканер.
Виправлення: Виявіть писача через iotop. Обмежте шумне джерело, капніть розмір журналу і керуйте вікнами snap refresh.

6) «Мережа стала нестабільною, і тепер продуктивність жахлива»

Симптом: Повторні спроби, повільні API, періодичні таймаути.
Корінь: Регресія драйвера, зміна offload, флап лінку або невідповідність MTU після оновлення.
Виправлення: Перевірте ip -s link помилки і dmesg повідомлення про лінк; координуйтеся з лічильниками на мережевому обладнанні; налаштовуйте offloads лише за наявності доказів.

Анекдот #2: Регресії ядра як офісні кавомашини: щойно ви на них покладаєтесь, вони набувають «характеру».

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

Контрольний список A: 10-хвилинний триаж на одному хості

Зафіксуйте ядро та uptime (uname -a, uptime -s).
Перевірте нещодавні оновлення (/var/log/dpkg.log tail).
Перевірте впавші сервіси і blame старту (systemctl --failed, systemd-analyze blame).
Класифікуйте за vmstat 1 (стежте за wa, si, so).
Заміряйте латентність диску з iostat -xz.
Атрибутуйте I/O з iotop -oPa, якщо диск гарячий.
Перегляньте kernel logs на скидання/таймаути (dmesg -T з фільтром).
Перевірте governor і частоту CPU (scaling_governor, /proc/cpuinfo).
Перевірте PSI пам’яті (/proc/pressure/memory) і використання swap (free -h).
Прийміть рішення: пом’якшити (зупинити винуватця), відкотити ядро або відкрити розслідування hardware/driver.

Контрольний список B: Коли це проблема флоту (не один хост)

Візьміть три хости: один швидкий, один повільний, один середній.
Порівняйте версії ядра і пакети microcode.
Порівняйте апаратні ідентифікатори (модель NVMe, модель NIC), щоб не ганятися за «софтом», який насправді апаратний.
Порівняйте латентність iostat і помилки dmesg між когорти.
Якщо корелює з певною збіркою ядра — розгляньте фіксацію або відкат ядра на ураженому обладнанні.
Підтвердіть, чи нові служби увімкнені на повільних хостах (systemctl list-unit-files --state=enabled diff).

Контрольний список C: Контрольовані дії пом’якшення (робіть це, а не рандомний тонінг)

Якщо диск насичений логами: зменшіть verbosity, обмежте розмір журналу, перемістіть високовиробні логи асинхронно поза хост.
Якщо snap refresh порушує SLO: заплануйте вікна оновлень і уникайте seeding під час піку.
Якщо з’являються NVMe скидання: у пріоритеті — перевірка прошивки і параметрів ядра, а не «тонінг ФС».
Якщо частота CPU застрягла: виправте governor/профіль і перевірте під навантаженням з повторюваними тестами.
Якщо PSI пам’яті високий: зменшіть робочий набір, виправте витоки, встановіть ліміти або додайте RAM — потім переміряйте.

FAQ

1) Як зрозуміти, чи уповільнення через CPU, диск чи пам’ять?

Використайте vmstat 1 і iostat -xz. Високий wa + високий await вказує на латентність диску. Активність swap і PSI пам’яті — на тиск пам’яті. Високий user/system CPU при низькому iowait — на CPU або системні виклики.

2) Оновлення завершилось, але я не перезавантажувався. Чи може продуктивність змінитися?

Так. Userspace служби можуть перезапуститися, конфігурації зміняться, і фонові задачі (snap refresh, rebuild кешів) можуть запуститись негайно. Поведінка ядра/драйверів зазвичай змінюється після перезавантаження, але не всі регресії вимагають reboot.

3) Чому iowait так важливий, якщо CPU виглядає вільним?

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

4) Чи варто негайно відкотити ядро?

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

5) Snapd зайнятий після оновлення — чи видаляти snaps?

Не як перша реакція. Спочатку підтвердьте, що snapd — реальний винуватець за допомогою iotop і systemd-analyze blame. Потім керуйте вікнами оновлень і мінімізуйте конфлікт із latency-sensitive навантаженнями. Видалення snaps може додати більше операційної площі, ніж зекономить.

6) Який найшвидший спосіб виявити NVMe проблеми?

dmesg -T з фільтром за nvme, timeout і reset, плюс iostat -xz для спайків латентності. Якщо бачите controller resets — припиніть тонінг файлових систем і почніть валідацію firmware і поведінки ядра.

7) Як AppArmor відмови проявляються як «проблеми продуктивності»?

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

8) Чи безпечно ставити governor=performance на серверах Ubuntu 24.04?

Часто — так, для latency-sensitive продакшну, якщо потужність і тепло враховані. Але ставте це як зміну: застосуйте на підмножині, заміряйте і переконайтесь, що не запускаєте thermal throttling або не порушуєте енергетичні бюджети.

9) Чому journald інколи стає пляшковою шийкою?

Високий обсяг логів — це стійкі дрібні записи плюс оновлення метаданих. Якщо сервіс став гучнішим після оновлення, journald може створити постійний записовий тиск і точки синхронізації. Обмежуйте розмір, зменшуйте verbosity і не колокуйте лог-хайв із найчутливішим storage, якщо можна уникнути.

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

Зробіть це сьогодні, поки інцидент ще свіжий і докази не зникли з логів:

Пройдіть швидкий план діагностики на одному ураженому та одному неураженому хості. Зафіксуйте: ядро, iostat latency, топ I/O процес, і будь-які dmesg помилки.
Якщо бачите таймаути/скидання пристроїв: обмежте зону впливу (закріпіть/відкотіть ядро на ураженому обладнанні) і відкрийте розслідування firmware/driver.
Якщо бачите I/O churn від логів або snap: обмежте, заплануйте або перемістіть їх. Не дозволяйте фоновому обслуговуванню конкурувати з foreground SLO.
Якщо частота CPU неправильна: виправте governor/профіль і перевірте під навантаженням з повторюваними вимірюваннями, а не за відчуттями.
Захопіть baseline-артефакт після стабілізації. Наступного вікна патчів ви будете вдячні.