386: момент, коли ПК почали поводитися як сервер

Що змінилося з 386 (і чому це має значення для операцій)

Поширена версія — «з’явився 32-біт». Це правда, але поверхнево. З точки зору операцій, 386 мав значення тому, що змусив архітектуру ПК перестати вам брехати.
До цього ПК часто були однозадачними, однокористувацькими середовищами, які вдавали із себе загального призначення комп’ютери. 386 зробив практичним запуск ОС,
яка забезпечує межі: між процесами, між користувачем і ядром, і між «ця програма глючить» та «вся машина перетворилась на макулатуру».

Епоха 8086/286 могла підтримувати захищений режим, але це було незручно й несумісно настільки, що багато систем залишалися в реальному режимі заради сумісності.
386 зробив захищений режим придатним для життя. Він також зробив пейджинг практичним і масштабованим для робочих навантажень ПК. Пейджинг — це не просто функція пам’яті;
це операційна угода: машина може перевитрачати пам’ять і вижити, але за рахунок вводу/виводу та затримок. Це серверний прийом.

Операційний поворот: від «додаток володіє машиною» до «ОС володіє машиною»

На ранніх ПК додаток часто керував усім. Він безпосередньо звертався до апаратури. Він припускав, що може писати куди завгодно у пам’ять.
Він ставив ОС у роль чемного бібліотекаря, який приносить файли за запитом. Така модель руйнується, коли потрібна ізоляція багатьох користувачів, фонова служба
чи будь-що, що нагадує надійність.

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

Одна цитата, яку варто тримати над консоллю, приписується James Hamilton: «Everything fails, all the time.» Це не цинізм; це бюджет на операції.
Якщо ви це приймаєте, ви проєктуєте системи, які зазнають відмов у контрольований спосіб. Захисти 386 допомогли обмежувати радіус ураження.

Серверні властивості 386: ізоляція, пейджинг, мультизадачність та реалії вводу/виводу

1) Захищений режим, яким люди дійсно почали користуватися

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

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

2) Пейджинг: перший раз, коли ПК міг вдавати, що має більше ОЗП (і іноді таке проходило)

Пейджинг — це не магічна пам’ять; це відкладений біль. Але це контрольований вид болю, а на контролі тримається операції.
З пейджингом ви можете запускати навантаження, яке трохи не вміщується в ОЗП. Без пейджингу ви просто не можете.

Апаратура пейджингу 386 (реальна історія MMU, не програмний хак) дозволила ОС реалізувати demand paging і свопінг так, як це робили мінікомп’ютери й Unix-сервери.
Це момент, коли «диск повільний» стає вимірним твердженням, а не відчуттям.

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

3) Кільця та привілеї: user-space проти kernel-space перестає бути філософією

Модель привілеїв x86 (кільця 0–3) стала операційно значущою, коли мейнстримні ОС почали послідовно її використовувати. Перехід між кільцями, syscalls,
драйвери ядра та користувацькі процеси отримали чіткіші обов’язки. Це зменшило патерн «один поганий покажчик підірве систему», що домінував у DOS-ера.

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

4) Virtual 8086 mode: сумісність без життя в минулому

386 ввів virtual 8086 mode (v86), що дозволив ОС у захищеному режимі запускати програми для real-mode DOS у ізольованих віртуальних машинах.
Це важливо, бо це архітектурний компроміс, який дав бізнесу можливість прийняти «сервероподібну» поведінку ОС, не відмовляючись від свого програмного інвентарю миттєво.

Операційно v86 — це пращур підходу «утримання спадщини»: ізолюйте те, що ви не можете переписати, зменшіть радіус ураження і рухайтеся далі.
Знайомо? Контейнери не винайшли ідею; вони зробили її дружнішою.

5) Плоска модель пам’яті стає правдоподібною: розробники перестають думати в сегментах (переважно)

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

Це також полегшило появу Unix та Unix-подібних ОС на масовому ПК-обладнанні так, щоб це не виглядало як науковий експеримент.

6) Введення/виведення: все ще лиходій, але з кращими виправданнями

386 не магічно виправив PC I/O. Ранні диски та контролери для ПК все ще були повільні, а шина не була побудована для сталого багатокористувацького пропуску.
Змінилося те, що ви могли виміряти вузьке місце. З мультизадачністю і пейджингом ви могли побачити конкуренцію:
CPU wait, черги на диск, контекстні перемикання та тиск пам’яті.

Коли машина може виконувати кілька задач, вона також може одночасно виконувати кілька розчарувань. Це теж серверна властивість.

Історичні факти, які важливі в продакшені

• 386 був першим широко прийнятим 32-бітним x86 CPU від Intel, що приніс 32-бітні регістри та 4 GiB лінійного адресного простору — величезно в порівнянні зі стандартами ПК.
• Він ввів пейджинг в x86 таким чином, щоб мейнстримні ОС могли використовувати його для віртуальної пам’яті та ізоляції процесів.
• Virtual 8086 режим з’явився з 386, дозволивши DOS-програмам працювати під наглядом захищеного режиму з ізоляцією.
• 386DX мав 32-бітну шину даних; дешевший 386SX використовував 16-бітну зовнішню шину, що часто означало помітно гіршу пропускну здатність пам’яті та вводу/виводу.
• OS/2 2.0 орієнтувалася на апаратне забезпечення класу 386 для надання 32-бітних можливостей і кращої мультизадачності, ніж DOS/Windows того часу.
• Системи на 386 допомогли нормалізувати Unix на масовому обладнанні через ранні порти і загальну здійсненність багатокористувацьких ОС на ПК.
• Ера 386 прискорила попит на кращі файлові системи та управління дисками, бо пейджинг і багатокористувацькі навантаження жорстко оголили фрагментацію й латентність пошуку.
• Вона зробила «uptime» культурно значущим на ПК: як тільки ПК почали працювати як служби постійно, перезавантаження перестало бути рутинною операцією і стало ризиком.

Режими відмов, які зробив видимими 386

Тиск пам’яті стає проблемою продуктивності, а не лише збоєм

У однозадачному світі «закінчилась пам’ять» — це крутий стоп. У світі з пейджингом та мультизадачністю «мало пам’яті» — це спектр.
Машина сповільнюється, латентність стрибає, і врешті ви потрапляєте в swap thrash: система робить більше дискового вводу/виводу, переміщаючи сторінки, ніж корисної роботи.
Вітаю — ви відкрили перший по-справжньому нудний інцидент сервера: коли нічого не впало, але всі незадоволені.

Інверсія пріоритетів і сюрпризи в плануванні

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

Якість драйверів стає залежністю надійності

Коли ви переміщуєте доступ до апаратури за ОС, драйвери стають привратниками. Це здорово, але центрує ризик.
Нестабільний драйвер NIC на десктопі — це неприємність. На ПК, який поводиться як сервер — це просто даунтайм.

Диски стають тихою одноточковою відмовою

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

Жарт №2: RAID — це не резервне копіювання, але це чудовий спосіб втратити дані двічі з більшою впевненістю.

Три корпоративні міні-історії з ери «ПК-сервера»

Міні-історія 1: Інцидент через хибне припущення (пейджинг — «безкоштовний»)

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

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

Оператор на виклику перевірив CPU і виявив, що він дивно низький. Мережа була в порядку. Черги на диск були величезними. Сервер увійшов у swap thrash:
робочий набір перевищив ОЗП настільки, що система постійно викидала й завантажувала ті самі сторінки.
Команда відносилася до swap як до страховки. Насправді swap — це обрив з гарним перилами.

Виправлення було простим. Вони зменшили паралельність під час пакетних вікон, додали ОЗП і — найважливіше — перенесли базу даних на машину з
швидшими дисками та відокремили спул друку від навантаження БД. Вони також почали вимірювати тиск пам’яті як першокласний показник ємності.
Урок: віртуальна пам’ять — це механізм, а не план.

Міні-історія 2: Оптимізація, що обернулася проти (налаштування диска як самосаботаж)

Інша команда тримала спільний сервер розробки на 386 з Unix-подібною ОС. Розробники скаржилися на повільну компіляцію.
Хтось вирішив, що причина в «занадто великому логуванні» і «занадто частих sync». Вони підправили опції монтовання файлової системи для швидкості,
зменшили write barriers (по тих часах еквівалент ручок) і відключили деяку періодичну поведінку flush.

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

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

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

Міні-історія 3: Справна, але правильна практика, яка врятувала ситуацію (базові показники ємності)

Фінансовий відділ запускав невеликий додаток по бізнес-процесу плюс файлові шари на ПК 386, пізніше модернізованому, але все ще обмеженому.
Оператор — непоказно методичний — вів щотижня нотатки: вільне місце на диску, використання swap, середнє навантаження і короткий опис того, що означає «норма» в кінці місяця.

Одного тижня користувачі почали скаржитися на періодичне уповільнення близько обіду. Ніяких збоїв. Ніяких явних помилок.
Нотатки з базових показників показали поступове зростання використання диску і слабке, але послідовне зростання активності swap-in. Це було ново.
Це ще не було драматичним, щоб вмикати тривоги, бо їх не було.

Оскільки у них були базові показники, вони не гадали. Вони перевірили, які директорії ростуть, і знайшли пакетну задачу експорту, яка була змінена так,
що тепер зберігала додаткові проміжні файли. Місця на диску ще вистачало, але фрагментація й тиск пошуку зростали, і swap почав конкурувати з I/O експорту.

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

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

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

Завдання 1: Визначити машину й ядро (не відлагоджуйте не ту платформу)

cr0x@server:~$ uname -a
Linux server 6.5.0-21-generic #21-Ubuntu SMP PREEMPT_DYNAMIC x86_64 GNU/Linux

Що це означає: Версія ядра й архітектура. Якщо ви думали, що на x86_64, але це не так, усі припущення про продуктивність змінюються.

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

Завдання 2: Перевірити топологію CPU та підказки віртуалізації

cr0x@server:~$ lscpu | egrep 'Model name|CPU\(s\)|Thread|Core|Socket|Virtualization'
CPU(s):                               8
Model name:                           Intel(R) Xeon(R) CPU
Thread(s) per core:                   2
Core(s) per socket:                   4
Socket(s):                            1
Virtualization:                       VT-x

Що це означає: Скільки паралелізму ви можете очікувати і чи може SMT спотворювати симптоми насичення CPU.

Рішення: Якщо навантаження погано масштабується, обмежте потоки або прив’яжіть CPU; якщо це VM-хост, перевірте шумних сусідів.

Завдання 3: Швидкий перегляд навантаження і «чи він завантажений»

cr0x@server:~$ uptime
 12:41:07 up 37 days,  3:12,  2 users,  load average: 7.92, 7.85, 7.10

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

Рішення: Якщо load високий, негайно перевірте, чи це CPU або I/O wait (наступні завдання).

Завдання 4: Побачити насичення CPU проти I/O wait

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

12:41:12 AM  CPU    %usr   %nice    %sys %iowait    %irq   %soft  %steal  %guest  %gnice   %idle
12:41:13 AM  all   22.10    0.00    4.55   38.60    0.00    0.40    0.00    0.00    0.00   34.35
12:41:14 AM  all   19.80    0.00    4.20   41.10    0.00    0.45    0.00    0.00    0.00   34.45
12:41:15 AM  all   20.30    0.00    4.10   39.90    0.00    0.50    0.00    0.00    0.00   35.20

Що це означає: Високе %iowait означає, що CPU переважно чекають на зберігання. Це «ПК, що поводиться як сервер»: CPU просто простає, але система зайнята.

Рішення: Якщо %iowait високий, припиніть тюнінг CPU і йдіть прямо до перевірки диску та тиску пам’яті.

Завдання 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
 3  2  81264  48216  61240 418920   12   48   980  2100  820 1430 18  4 34 40  0
 2  3  81312  47540  61240 417800   20   56  1100  2500  790 1510 20  4 33 43  0
 1  3  81356  47020  61244 417500   18   60  1050  2400  800 1490 19  4 34 43  0
 2  2  81400  46900  61248 417200   16   52   990  2250  780 1470 18  4 35 43  0

Що це означає: Ненульові si/so вказують на активність свопу; b — заблоковані процеси; wa — очікування вводу/виводу.

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

Завдання 6: Хто використовує пам’ять (файловий кеш чи anonymous RSS)

cr0x@server:~$ free -h
               total        used        free      shared  buff/cache   available
Mem:           15Gi       12Gi       110Mi       1.2Gi       2.9Gi       1.1Gi
Swap:         4.0Gi       1.2Gi       2.8Gi

Що це означає: «Available» — ключове число. Низьке available з використанням swap свідчить про реальний тиск, а не лише кеш.

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

Завдання 7: Процеси-утримувачі пам’яті та CPU

cr0x@server:~$ ps -eo pid,comm,%cpu,%mem,rss,vsz --sort=-rss | head
 2143 java        180.2  42.1 6702100 8123400
 1880 postgres     35.0   6.3 1002400 1402100
 3012 node         22.4   4.9  780120 1023000
 1122 rsyslogd      2.1   0.6   92000  180000

Що це означає: RSS показує фактичну резидентну пам’ять; VSZ — віртуальний розмір. Великий RSS + swap = ризик продуктивності.

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

Завдання 8: Стан дисків і черги

cr0x@server:~$ iostat -xz 1 3
Linux 6.5.0-21-generic (server) 	01/09/2026 	_x86_64_	(8 CPU)

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
          20.04    0.00    4.22   40.11    0.00   35.63

Device            r/s     w/s   rkB/s   wkB/s  rrqm/s  wrqm/s  %rrqm  %wrqm r_await w_await aqu-sz  rareq-sz wareq-sz  svctm  %util
nvme0n1         85.0   120.0  6800.0  9200.0     2.0     8.0   2.30   6.25   8.10  14.30   2.90     80.0     76.7   0.25  98.50

Що це означає: %util близько 100% разом з високим await вказують, що диск — вузьке місце.

Рішення: Якщо диск насичений, зменшіть паралельність I/O, перенесіть навантаження або оновіть дисковий підсистем. Не «тюньте CPU».

Завдання 9: Знайти процеси, що генерують I/O

cr0x@server:~$ sudo iotop -o -b -n 3
Total DISK READ: 45.23 M/s | Total DISK WRITE: 62.10 M/s
PID  PRIO  USER     DISK READ  DISK WRITE  SWAPIN     IO>    COMMAND
2143 be/4  app      12.00 M/s  35.00 M/s   12.50 %  85.00%  java -jar service.jar
1880 be/4  postgres 18.00 M/s  10.00 M/s    0.00 %  40.00%  postgres: writer process
3012 be/4  app       9.00 M/s   8.00 M/s    0.00 %  22.00%  node server.js

Що це означає: IO> показує завдання, що чекають на I/O; SWAPIN показує, що тиск пам’яті сприяє I/O.

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

Завдання 10: Підтвердити вільне місце файлової системи та тиск інодів

cr0x@server:~$ df -h
Filesystem      Size  Used Avail Use% Mounted on
/dev/nvme0n1p2  220G  201G   8.5G  97% /
tmpfs           7.8G  1.2G   6.6G  16% /run

cr0x@server:~$ df -i
Filesystem       Inodes   IUsed    IFree IUse% Mounted on
/dev/nvme0n1p2  14576640 14210000  366640   98% /

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

Рішення: Якщо байти або іноди перевищують ~85–90% на навантаженому сервері, негайно плануйте очищення і розширення ємності.

Завдання 11: Знайти топ-директорії, що споживають місце

cr0x@server:~$ sudo du -xhd1 / | sort -h
0	/bin
1.3G	/boot
4.2G	/etc
12G	/home
28G	/var
155G	/usr
201G	/

Що це означає: Швидка атрибуція: яке дерево росте.

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

Завдання 12: Перевірити ріст логів і стан ротації

cr0x@server:~$ sudo journalctl --disk-usage
Archived and active journals take up 8.0G in the file system.

Що це означає: Журнали, що їдять диск — типова ситуація для «ПК, що став сервером» — логування було після думки, поки не стало важливим.

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

Завдання 13: Помітити насичення мережі або ретрансляції (класичне «все повільне»)

cr0x@server:~$ sar -n DEV 1 3
Linux 6.5.0-21-generic (server) 	01/09/2026 	_x86_64_	(8 CPU)

12:42:10 AM     IFACE   rxpck/s   txpck/s    rxkB/s    txkB/s   rxcmp/s   txcmp/s  rxmcst/s   %ifutil
12:42:11 AM      eth0    8200.00   7900.00  92000.00  88000.00      0.00      0.00     10.00     92.00

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

Рішення: Якщо %ifutil постійно високий, підвищіть швидкість лінку, додайте NIC або зменшіть шум (сжаття, пакетування).

Завдання 14: Підтвердити TCP-проблеми (ретрансляції та тиск беклогу)

cr0x@server:~$ netstat -s | egrep -i 'retransmit|listen|overflow' | head
      1832 segments retransmitted
      0 times the listen queue of a socket overflowed
      0 SYNs to LISTEN sockets ignored

Що це означає: Ретрансляції вказують на якість мережі або затори; переповнення черги listen вказує на проблеми в циклі accept.

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

Завдання 15: Перевірити індикатори тиску ядра (сучасна «серверність»)

cr0x@server:~$ cat /proc/pressure/memory
some avg10=28.50 avg60=25.10 avg300=22.05 total=987654321
full avg10=3.10 avg60=2.80 avg300=2.20 total=45678901

Що це означає: PSI показує час, витрачений у стані затримки через тиск пам’яті. «full» означає, що всі задачі затримані.

Рішення: Якщо PSI memory «full» нетривіальний, ставте це як аварію ємності: зменшіть навантаження, додайте пам’ять або перемістіть навантаження.

Завдання 16: Перевірити помилки диска (не «тюньте» навколо апаратної відмови)

cr0x@server:~$ dmesg -T | egrep -i 'error|timeout|reset|I/O' | tail
[Thu Jan  9 00:12:14 2026] nvme nvme0: I/O 512 QID 7 timeout, aborting
[Thu Jan  9 00:12:14 2026] nvme nvme0: Abort status: 0x371
[Thu Jan  9 00:12:15 2026] nvme nvme0: resetting controller

Що це означає: Таймаути та ресети — це не можливості для тюнінгу продуктивності; це апаратні інциденти.

Рішення: Зупиніться. Зменште навантаження, мігруйте дані, замініть апарат або перевірте прошивку. Продуктивність не переможе фізику.

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

Коли ПК поводиться як сервер, він відмовляє як сервер: конкуренція, черги й повільне деградування. Ваше завдання — знайти чергу.
Робіть це в порядку. Не імпровізуйте.

По-перше: вирішіть, чи це CPU або очікування

• Перевірте load: uptime. Високий load не доводить насичення CPU.
• Перевірте розподіл CPU: mpstat 1 3. Якщо %iowait високий — це не проблема CPU.

Інтерпретація: Високе %usr/%sys з малою idle вказує на CPU. Високе %iowait — на зберігання або swap.

По-друге: вирішіть, чи це тиск пам’яті, що створює I/O

• Перевірте свопінг: vmstat 1 5 для si/so.
• Перевірте «available» пам’ять: free -h.
• Перевірте PSI (якщо є): cat /proc/pressure/memory.

Інтерпретація: Постійна активність свопу або «full» в PSI означає, що потрібно зменшити робочий набір або додати ОЗП. Тюнінг сховища цього не вирішить.

По-третє: доведіть, чи диск насичений або просто повільний

• Перевірте використання пристрою й await: iostat -xz 1 3.
• Прив’яжіть I/O до процесів: iotop -o.
• Перевірте стан диска: dmesg -T на предмет ресетів/таймаутів.

Інтерпретація: Високий %util і високий await означають черги; високий await з помірним util може вказувати на проблеми прошивки, тротлінг або спільний бекенд.

По-четверте: перевіряйте мережу лише після того, як CPU/пам’ять/диск не винні

• Використання інтерфейсу: sar -n DEV 1 3.
• Ретрансляції: netstat -s.

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

По-п’яте: підтвердьте черги на рівні застосунку

• Топ процесів: ps, top для runaway CPU або RSS.
• Метрики/логи сервісу: латентність запитів, глибина черг, повільні запити в БД.

Інтерпретація: Коли системні ресурси в порядку, вузьке місце зазвичай всередині власних блокувань, пулів і механізмів зворотного тиску застосунку.

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

1) «CPU низький, але все повільно» → I/O wait або swap thrash → виміряйте й зменшіть I/O

Симптом: Користувачі скаржаться на повільність; CPU простає; load average високий.

Корінна причина: Високе %iowait через насичення сховища або тиск пам’яті, що спричиняє своп.

Виправлення: Використайте mpstat, vmstat, iostat, iotop. Зменшіть I/O-важкі задачі в пікові години, додайте ОЗП, перемістіть бази даних/логи на швидші диски, обмежте паралельність.

2) «Перезавантаження вирішує на деякий час» → витік пам’яті або вибух кешу → ізолюйте й обмежте

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

Корінна причина: Зростаючий RSS (витік), необмежені кеші або витік дескрипторів файлів, що веде до вторинних відмов.

Виправлення: Відстежуйте RSS через ps і метрики сервісів; встановіть ліміти (systemd, cgroups), виправте витік, перезапускайте сервіс за розкладом як тимчасовий контроль.

3) «Диск 97% заповнений і відбуваються дивні речі» → тиск алокатора і фрагментація → звільнити місце і розділити навантаження

Симптом: Випадкові помилки застосунків, повільні записи, невдала ротація логів.

Корінна причина: Мало вільного місця або вичерпання інодів; операції з метаданими стають дорогими; записи відмовляють.

Виправлення: Почистити, збільшити ємність і тримати завантажені файлові системи нижче ~80–85%. Перемістіть змінні дані (spool, tmp, build artifacts) на окремі томи.

4) «Ми тюнінгували для швидкості і втратили дані» → змінені налаштування довговічності без обліку ризику → відновити безпечні параметри

Симптом: Після краху/втрати живлення файлові системи пошкоджені або відсутні нещодавні записи.

Корінна причина: Відключені write barriers, небезпечні опції монтування, кеші без захисту від втрати живлення.

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

5) «Мережа нестабільна лише на цьому хості» → NIC/драйвер або MTU/duplex mismatch → перевірте лічильники і логи

Симптом: Ретрансляції, переривчасті затримки, падіння пропускної здатності під навантаженням.

Корінна причина: Погане лінк-з’єднання, невідповідний MTU, баги драйвера або переповнення черг.

Виправлення: Перевірте netstat -s, статистику інтерфейсу, лічильники на комутаторі; уніфікуйте MTU/duplex; оновіть драйвер/прошивку.

6) «Бекапи запускаються, але вдень продуктивність помирає» → погано запланований пакетний I/O → розклад і обмеження

Симптом: У стабільний час латентність зростає; I/O wait підскакує.

Корінна причина: Резервне копіювання/індексування/антивірус насичують диск.

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

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

Покроково: перетворити «ПК-сервер» на щось кероване

1. Інвентар навантаження. Перелічіть сервіси, пікові години і що означає «повільно» (латентність, пропускна здатність, помилки).
2. Встановіть базу. Зафіксуйте uptime, free -h, iostat -xz, використання диску та топ-процеси в «нормальний» і у піковий час.
3. Розділіть класи даних. Розмістіть ОС, логи, бази даних і тимчасові дані на окремих файлових системах або томах, якщо можливо.
4. Впровадьте ліміти. Обмежте пам’ять і CPU для некритичних сервісів, щоб один агресивний процес не з’їв всю машину.
5. Контролюйте пакетну роботу. Плануйте бекапи, індексування і компактування поза піком; обмежуйте через nice/ionice.
6. Визначте політику перезавантажень. Перезавантаження повинні бути заплановані, протестовані й задокументовані. «Ми ніколи не перезавантажуємо» — це не стратегія стійкості.
7. Перевірте налаштування довговічності. Переконайтеся, що тюнінг продуктивності не вимкнув безпеку. Якщо не можете пояснити компроміс — поверніть.
8. Моніторьте правильні сигнали. Тиск пам’яті, використання диску/await, рівні помилок, ретрансляції — а не лише CPU.
9. Тестуйте відновлення. Бекапи, які не відновлювалися — це дороге оптимізм.
10. Запишіть «швидку діагностику». Ваше майбутнє «я» буде втомленим і не враженим вашими імпровізаційними навичками.

Контрольний список: перед тим як назвати «залізо занадто повільне»

• Чи є свопінг (vmstat si/so)?
• Чи диск насичений (iostat %util близько 100%)?
• Чи є помилки диска (dmesg таймаути/ресети)?
• Чи майже заповнена файловa система (df -h і df -i)?
• Чи є запланована пакетна задача, що викликає періодичний біль?
• Чи ростуть ретрансляції (netstat -s)?
• Чи маєте базу для порівняння?

Контрольний список: якщо треба вичавити продуктивність з обмеженого заліза

• Зменшіть паралельність перед тим, як зменшувати безпеку.
• Надавайте перевагу перенесенню записів з критичної ФС замість зробити ФС небезпечною.
• Додайте ОЗП, якщо активний swap; часто це найвищий ROI.
• Тримайте диски в комфортному використанні; повні диски — повільні диски.
• Вимірюйте після кожної зміни. Якщо не можете виміряти — ви не покращили, ви просто змінили.

Питання та відповіді

Чи справді 386 «перетворив ПК на сервери»?

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

Який найбільший операційний урок з ери 386?

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

Чи завжди пейджинг поганий?

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

Чому іноді високий load average при низькому CPU?

Бо load average включає завдання, застряглі в неперервному сні (uninterruptible sleep), зазвичай чекаючи на дискові операції.
Саме тому mpstat і iostat важливіші за здогадки.

Який сучасний еквівалент «DOS-програми в v86»?

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

Як зрозуміти, що повільність через сховище чи пам’ять?

Перевірте vmstat на si/so. Якщо активність свопу постійна — тиск пам’яті, ймовірно, спричиняє I/O.
Потім підтвердіть через free -h і /proc/pressure/memory. Якщо своп тихий, але iostat показує високий await і util — це сховище.

Що оновлювати насамперед: CPU, ОЗП чи диск?

Починайте з доказів. Якщо своп активний і «available» пам’ять низька — оновлюйте ОЗП. Якщо %util диска зафіксований з високим await — оновлюйте сховище або розділіть навантаження.
Оновлення CPU допоможе лише коли %usr/%sys постійно високі при низькому %iowait.

Чому майже повні файлові системи створюють проблеми ще до повного заповнення?

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

Чи «ніколи не перезавантажувати» — хороша стратегія надійності?

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

Який найкращий спосіб утримати невеликий сервер стабільним при змішаних навантаженнях?

Відокремте I/O-важкі задачі (логи, бекапи, тимчасові файли) від сервісів, чутливих до латентності, встановіть обмеження ресурсів і плануйте пакетні роботи.
Більшість «катастроф на малих серверах» — це просто неконтрольована конкуренція.

Висновок: практичні кроки далі

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

Якщо сьогодні у вас є щось, що пахне «машина, яка тихо стала сервером», зробіть три речі цього тижня:
(1) встановіть базові показники для CPU, тиску пам’яті та disk await; (2) відокремте або заглуште пакетний I/O; (3) запровадьте ліміти, щоб один сервіс не зміг
з’їсти хост. Ви запобіжите класичному простою, коли нічого «не ламалося», але все перестало працювати.