WSL2: обмеження пам’яті та CPU — як не дати йому з’їдати вашу оперативну пам’ять

Як WSL2 фактично використовує пам’ять і CPU

WSL2 — це не «Linux, що працює у шарі сумісності». Це було більше про WSL1. WSL2 запускає справжнє ядро Linux всередині легкого віртуального середовища, яким керує Hyper-V. Саме тому WSL2 має кращу сумісність викликів системи та чому він також може з’їдати ваші ресурси у вигляді тиску на оперативну пам’ять.

Ментальна модель, яка вас не підведе

• Windows володіє апаратним забезпеченням. WSL2 — це гостьова VM. Гість може запитувати пам’ять і CPU; хост планує й забезпечує їх.
• Пам’ять WSL2 «еластична», поки не стає такою. VM може зростати, коли Linux кешує дані файлів, виділяє пам’ять для збірок або запускає контейнери.
• Linux використовує «вільну» RAM для кешу. Це нормально. Критична ситуація настає, коли цей кеш не повертається Windows достатньо швидко або коли VM досягає ліміту й починає підкачувати.
• vmmem — це рахунок. Диспетчер задач не показує «пам’ять процесу WSL2» так, як ви цього хочете; він показує процес контейнера VM. Це включає ядро Linux, page cache і все, що ви запускали всередині WSL2.

CPU простіший: без обмежень WSL2 може використовувати стільки ядер, скільки Windows дозволить. Якщо ви коли-небудь бачили, як збірка Rust або паралельний make -j руйнують інтерактивність, ви спостерігали стандартну політику: «Вітаємо, ви купили ядра; ми використаємо їх усі.»

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

Короткий жарт №1: WSL2 не «тече пам’яттю». Він просто назавжди її усиновлює й називає ім’ям вашого каталогу збірки.

Цікаві факти та історичний контекст (те, про що не говорять на стендапі)

1. WSL1 vs WSL2 — це філософський поворот. WSL1 транслював виклики Linux у Windows. WSL2 постачає справжнє ядро Linux, що виправило сумісність, але відновило поведінку, властиву VM, щодо ресурсів.
2. Процес vmmem — це контейнер Hyper-V. Це представлення WSL2 VM на стороні хоста. Ось чому він виглядає «таємничим» у Диспетчері задач і чому вбивання випадкових процесів Linux не обов’язково швидко зменшує його використання.
3. Page cache Linux — це не «марна RAM». Це продуктивність. Коли це стає проблемою, проблема в поверненні пам’яті через межу VM-хост, а не в «жадібності» Linux.
4. Балонне звільнення пам’яті — відомий VM-підхід. Гіпервізори можуть звільняти пам’ять гостя через balloon-драйвери. Поведінка WSL2 покращувалася з часом, але це не магія і не миттєве.
5. WSL2 мав історію «пам’ять не повертається». Ранні збірки були відомі цим. Новіші Windows 11 + оновлення WSL покращили повернення пам’яті, особливо з функціями як page reporting.
6. Docker з бекендом WSL2 змінив правила гри. Замість важкої LinuxKit VM Docker Desktop може працювати всередині WSL2, і тоді політика ресурсів WSL2 стає проблемою всіх, а не лише «Linux-розробників».
7. Swap всередині WSL2 — це не Windows pagefile. WSL2 може мати власний файл підкачки. Ви можете його налаштувати, і варто це робити, бо «підкачка несподівано» — це те, як ноутбуки починають звучати, ніби перетирають щебінь.
8. Підтримка systemd у WSL2 була великим зрушенням. Більше фонового сервісу може запускатися, що добре для реалістичності і водночас добре для тих, хто мовчки споживає RAM і CPU, якщо ви ставитеся до WSL як до тимчасової оболонки.
9. Обмеження CPU — грубий, але ефективний інструмент. VM за замовчуванням не є cgroup-пісочницею. Якщо ви хочете, щоб «робочі навантаження Linux не вбивали інтерактивність Windows», обмеження на рівні VM — це дивовижно простий і дієвий молоток.

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

Коли машина гальмує, не починайте з редагування конфігів. Спочатку з’ясуйте, з яким видом «повільності» ви маєте справу. Є три поширені вузькі місця: тиск на пам’ять хоста, тиск на пам’ять гостя і конкуренція за CPU. Диск — хитріший четвертий.

По-перше: чи Windows задихається через RAM чи CPU?

• Перевірте Диспетчер задач: графік пам’яті, графік CPU і які процеси найгучніші (vmmem проти всього іншого).
• Рішення: Якщо Windows сильно підкачують або пам’ять >90% використана, вважайте це аварією пам’яті хоста. Якщо CPU завантажений, вважайте це проблемою планування/конкуренції.

По-друге: чи WSL2 винен чи просто поруч?

• Перевірте дистрибутиви WSL: дізнайтеся, що запущено і чи задіяний стек контейнерів (Docker Desktop, Kubernetes, збірки).
• Рішення: Якщо vmmem великий і зростає, з’ясуйте, що всередині Linux використовує пам’ять (RSS) проти кешу. Якщо CPU високий, визначте, чи це компіляції, контейнери чи фонові служби.

По-третє: чи «застрягла» пам’ять або вона реально використовується?

• Всередині WSL: подивіться free -h, ps і /proc/meminfo, щоб відокремити анонімну пам’ять (додатки) від page cache.
• Рішення: Якщо це переважно кеш і Windows страждає, вам потрібні обмеження або примусове звільнення/вимкнення. Якщо це реальна пам’ять процесів, виправляйте навантаження (або приймайте його і обмежуйте).

По-четверте: перевірка дискового трешу (бо swap та I/O брешуть)

• Всередині WSL: якщо swap активний і I/O wait високий, ваша «проблема пам’яті» перетворилася на дискову проблему.
• Рішення: зменшіть використання пам’яті, збільшіть виділення RAM (парадоксально, але інколи правильно) або налаштуйте swap, щоб уникнути катастрофічного thrash.

Задайте жорсткі обмеження через .wslconfig (і що насправді робить кожна опція)

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

Де лежить конфіг і як він застосовується

.wslconfig читається WSL на стороні Windows. Він знаходиться у вашому профілі користувача Windows (зазвичай C:\Users\\.wslconfig). Він застосовується глобально до WSL2 VM, а не до окремого дистрибутива.

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

Опінійовані базові налаштування

На типовому ноутбуку для розробника з 16 ГБ, мені подобається давати WSL2 достатньо місця, щоб бути швидким, не дозволяючи йому стати операційною системою. Розумний початок:

cr0x@server:~$ cat /mnt/c/Users/$USER/.wslconfig
[wsl2]
memory=8GB
processors=4
swap=4GB
swapFile=C:\\Users\\%USERNAME%\\AppData\\Local\\Temp\\wsl-swap.vhdx
localhostForwarding=true

Що означає кожен рядок на практиці:

• memory=8GB: жорсткий ліміт пам’яті VM. Якщо гість захоче більше, він буде звільняти кеш, потім підкачувати, потім страждати. Це захищає Windows.
• processors=4: максимальна кількість vCPU. Це не «прив’язує» ядра; це обмежує паралелізм. Захищає від втрати інтерактивності під час збірок і контейнерних бур.
• swap=4GB: розмір swap у WSL2. Це не функція продуктивності; це буфер на випадок відмови. Занадто мало — OOM. Занадто багато — тихий thrash.
• swapFile=...: де розташований swap. Кладіть його на швидке сховище. Не ставте його в профілі мережевого диска, зашифровані папки з дивними політиками або куди-небудь, що викличе проблеми з корпоративним DLP.
• localhostForwarding=true: зберігає мережу адекватною. Це не ресурсний перемикач, але люди ламають його й потім неправильно діагностують «повільність», яка насправді DNS або проброс портів.

Вибір лімітів, що не зрадять вас

Універсального «найкращого» числа не існує. Є, однак, універсальний режим відмови: ставити ліміти так низько, що гість постійно підкачує, а ви звинувачуєте WSL2 у повільності. Це як поставити обмежувач швидкості на 20 миль/год і нарікати на стрес на автостраді.

Користуйтеся такими правилами:

• Пам’ять: Якщо хост має 16 ГБ, виставляйте WSL2 у межах 6–10 ГБ залежно від того, скільки ви запускаєте у Windows. Якщо ви тримаєте важкі IDE на Windows, йдіть нижче.
• CPU: Обмежуйте до половини ваших ядер для машин розробника. Якщо у вас 12–16 ядер, дайте WSL2 6–8. Якщо 4 ядра — дайте 2 і прийміть реальність.
• Swap: 2–8 ГБ є звичним. Якщо ви компілюєте великі проекти або запускаєте Kubernetes, схиляйтеся до більшого. Якщо важлива інтерактивність — менше і виправляйте використання пам’яті.

Короткий жарт №2: Swap — це як кофеїн: трішки тримає вас в живих, забагато робить вас нервовим і неприємним у спілкуванні.

Повернення пам’яті: чому «воно повинно звільнити RAM» — не план

Найпоширеніша скарга: «Я закрив усе в Linux, але Windows все ще показує vmmem з використанням 10 ГБ.» Іноді це баг. Частіше — фізика: гість використав пам’ять під кеш, і хост не відбирає її миттєво.

Що зазвичай відбувається

• Linux кешував дані файлів. Збірки, інсталяції пакетів і завантаження образів контейнерів наповнюють page cache.
• Гість бездіяльний, але все ще тримає сторінки. Ці сторінки всередині Linux «можуть бути звільнені», але хост не обов’язково змушує це робитися, поки не виникне тиск.
• Windows бачить виділення VM, а не «вільність» Linux. Отже ви бачите велике число й робите висновок, що це активне використання.

Що з цим робити

Є три рівні реагування від найменш до найбільш руйнівного:

1. Нічого не робіть, поки хост не потребує. Якщо у Windows достатньо вільної пам’яті й немає підкачки, не оптимізуйте за відчуттями.
2. Застосуйте розумні обмеження. Це довгострокове виправлення: WSL2 не зможе роздутися понад бюджет.
3. Перезапустіть WSL, коли закінчили важку роботу. Це прагматична кнопка «звільнити все зараз». Це не елегантно. Це ефективно.

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

Swap, зберігання та повільна смерть вашого SSD

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

Чому swap особливо підступний у WSL2

• Ви можете мати swap всередині гостя (файл swap WSL2), одночасно Windows має свій pagefile. Під тиском можна підкачувати двічі: Windows підкачує бекап VM, а Linux підкачує всередині нього. Весело, чи не так?
• I/O wait стає реальним вузьким місцем. Графіки CPU можуть виглядати «добре», але все стоїть, бо ви чекаєте на диск.
• Розмір swap взаємодіє з лімітами. Тісний ліміт пам’яті плюс великий swap може тримати навантаження на ногах замість швидкого провалу. Це або «продуктивно», або «тривале страждання», залежно від строків.

Розташування зберігання має значення

WSL2 використовує віртуальний диск (VHDX) для кожного дистрибутива. Цей диск зазвичай лежить у вашому профілі Windows. Якщо у вас повільний системний диск, усе у WSL2 спадкує цей біль — особливо шари контейнерів, кеші пакетів і артефакти збірок.

Якщо ви хочете продуктивність WSL2, тримайте високочастотні робочі навантаження всередині файлової системи Linux (ext4 у VHDX), а не працюйте з /mnt/c. Інтероперабельність з Windows хороша, але вона не така, як рідна Linux-фс.

Docker Desktop і Kubernetes у WSL2: хто насправді керує?

Як тільки Docker залучається, багато команд втрачають слід того, де живе контроль ресурсів. Вони налаштовують ліміти Docker, а потім дивуються, чому vmmem все ще росте. Або налаштовують ліміти WSL2 і не розуміють, чому Kubernetes падає.

Зрозумійте ієрархію

• Ліміт VM WSL2 обмежує всю Linux VM. Docker всередині нього підпорядковується цьому ліміту.
• Налаштування ресурсів Docker (якщо ви використовуєте UI Docker Desktop) можуть або не можуть застосовуватися так, як ви думаєте, залежно від бекенду й версії. Коли бекенд — WSL2, ліміти WSL2 — це жорстка стеля.
• Kubernetes додає фоновий хаос. Навіть «простий» кластер запускає компоненти control plane, контролери і watcher-і. Це постійні прокидання CPU і слід пам’яті.

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

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

Ось перевірки, які я реально використовую. Кожне завдання містить команду, типовий вивід і що з цього вирішувати. Виконуйте команди на стороні Windows у PowerShell; команди Linux — всередині WSL.

Завдання 1: Підтвердити версію WSL і що запущено

cr0x@server:~$ wsl.exe --list --verbose
  NAME            STATE           VERSION
* Ubuntu-22.04    Running         2
  Debian          Stopped         2

Значення: Ubuntu працює на WSL2. Debian зупинено. Якщо ви думали «нічого не запущено», ви помилялися.

Рішення: Якщо vmmem великий, сфокусуйтеся на запущених дистрибутивах. Зупиніть те, що не потрібне.

Завдання 2: Жорсткий скидання WSL для повернення пам’яті хосту

cr0x@server:~$ wsl.exe --shutdown

Значення: Всі дистрибутиви WSL і VM WSL2 завершуються. Пам’ять має знизитися незабаром після цього.

Рішення: Використовуйте це, коли Windows під тиском зараз. Не перетворюйте це на щоденний ритуал замість налаштувань лімітів.

Завдання 3: Подивитися слід пам’яті WSL на стороні хоста (швидко і грубо)

cr0x@server:~$ powershell.exe -NoProfile -Command "Get-Process vmmem | Select-Object Name,Id,@{n='WS(MB)';e={[math]::Round($_.WorkingSet64/1MB,0)}},CPU"
Name  Id   WS(MB) CPU
vmmem 9480 10324  812.55

Значення: VM тримає близько 10 ГБ робочого набору. Час CPU вказує на активність.

Рішення: Якщо Windows підкачують і це велике, застосуйте обмеження пам’яті і/або вимкніть WSL.

Завдання 4: Перевірити пам’ять всередині WSL (відокремити кеш від навантаження)

cr0x@server:~$ free -h
               total        used        free      shared  buff/cache   available
Mem:           7.6Gi       2.1Gi       1.2Gi       128Mi       4.3Gi       5.1Gi
Swap:          4.0Gi       0.0Gi       4.0Gi

Значення: Більшість пам’яті — у buff/cache, але available здоровий. Це не аварія всередині Linux.

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

Завдання 5: Визначити топ-споживачів пам’яті (реальний RSS, а не відчуття)

cr0x@server:~$ ps aux --sort=-rss | head -n 8
USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
root      1321  3.2  6.1 912648 475832 ?       Ssl  09:12   2:44 dockerd
cr0x      4882  1.1  4.8 2879300 376544 ?      Sl   10:01   0:51 node
cr0x      5021 18.9  4.2 1845500 332100 ?      Rl   10:05   1:32 rustc
postgres  2110  0.7  2.0  891200 158300 ?      Ssl  09:20   0:33 postgres
root       823  0.2  1.1  368012  88224 ?      Ss   09:10   0:08 containerd

Значення: Це реальна пам’ять процесів (RSS). Тут Docker і збірки — основні споживачі.

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

Завдання 6: Подивитися, чи відбувається підкачка всередині WSL

cr0x@server:~$ swapon --show
NAME      TYPE SIZE USED PRIO
/swapfile file   4G  512M   -2

Значення: Swap використовується. Це не автоматично погано, але це попередження щодо продуктивності.

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

Завдання 7: Знайти I/O wait (чи диск — справжнє вузьке місце?)

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 524288 842000  68000 3380000  20   45  1200   800  560  940 18  7 62 13  0
 1  1 524288 812000  68000 3310000  10   25  2400  1900  620 1020 12  6 58 24  0
 0  1 524288 798000  68000 3290000   0   12  3100  2200  640 1090 10  5 52 33  0

Значення: wa (I/O wait) зростає. Відбувається підкачка в/з. Ви тепер платите відсотки за борг по пам’яті.

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

Завдання 8: Перевірити конкуренцію CPU і навантаження всередині WSL

cr0x@server:~$ uptime
 10:14:22 up  1:08,  0 users,  load average: 9.12, 7.44, 5.81

Значення: Load average висока відносно виділених CPU. Якщо ви обмежили CPU до 4, а load — 9, у вас черга.

Рішення: Або підніміть processors, або зменшіть паралелізм (make -j, інструменти збірки, репліки контейнерів).

Завдання 9: Підтвердити, скільки CPU бачить WSL

cr0x@server:~$ nproc
4

Значення: Ваша поточна VM WSL2 бачить 4 CPU. Це відповідає processors=4.

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

Завдання 10: Знайти реальних винуватців дискового використання в WSL

cr0x@server:~$ sudo du -xh /var/lib | sort -h | tail -n 8
1.1G	/var/lib/apt
2.4G	/var/lib/snapd
6.2G	/var/lib/docker
6.2G	/var/lib/docker/overlay2
7.9G	/var/lib

Значення: Сховище Docker домінує. Це корелює з тиском пам’яті теж (page cache, метадані).

Рішення: Обріжте образи/томи, перенесіть збірки або прийміть, що накопичення локальних контейнерів має витрати.

Завдання 11: Підтвердити застосовані з Windows обмеження (перевірка здорового глузду)

cr0x@server:~$ cat /proc/meminfo | head -n 5
MemTotal:        7961888 kB
MemFree:         1214320 kB
MemAvailable:    5389120 kB
Buffers:           68040 kB
Cached:          3129480 kB

Значення: MemTotal близько 7.6–7.9 ГБ, що вказує, що ваш ліміт пам’яті WSL2 діє.

Рішення: Якщо ви очікували 16 ГБ, а отримали 8 ГБ — ваш ліміт замалий для цього навантаження (або це правильний ліміт і навантаження треба змінити).

Завдання 12: Перевірити, чи systemd-сервіси тихо їдять ресурси

cr0x@server:~$ systemctl --no-pager --type=service --state=running | head -n 12
  UNIT                         LOAD   ACTIVE SUB     DESCRIPTION
  cron.service                  loaded active running Regular background program processing daemon
  dbus.service                  loaded active running D-Bus System Message Bus
  docker.service                loaded active running Docker Application Container Engine
  rsyslog.service               loaded active running System Logging Service
  ssh.service                   loaded active running OpenBSD Secure Shell server
  systemd-journald.service      loaded active running Journal Service

Значення: Docker і SSH працюють, плюс базові служби. Це реальний фонова відбиток.

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

Завдання 13: Зупинити важкий сервіс і підтвердити зміну

cr0x@server:~$ sudo systemctl stop docker
cr0x@server:~$ ps aux --sort=-rss | head -n 5
USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
cr0x      4882  0.8  4.6 2879300 362112 ?      Sl   10:01   0:54 node
postgres  2110  0.7  2.0  891200 158100 ?      Ssl  09:20   0:33 postgres
root       823  0.1  0.9  342200  72140 ?      Ss   09:10   0:08 containerd

Значення: Процеси, пов’язані з Docker, впали. Пам’ять має знизитися з часом; пробудження CPU зменшиться негайно.

Рішення: Якщо це суттєво покращує відчуття Windows, ви знайшли основного винуватця. Задайте політику: не запускати Docker постійно, якщо це не навмисно.

Завдання 14: Підтвердити, що Windows бачить ліміти після перезапуску

cr0x@server:~$ wsl.exe --shutdown
cr0x@server:~$ wsl.exe -d Ubuntu-22.04 -- cat /proc/meminfo | head -n 1
MemTotal:        7961888 kB

Значення: VM перезапустилась і все ще обмежена приблизно 8 ГБ.

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

Три міні-історії з корпоративного життя (бо продакшн завжди має думку)

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

Одна команда впровадила WSL2 як стандартне середовище розробника. Це було розумно: однакові інструменти, менше «працює на моїй машині» і простіше онбординг. Вони сказали всім: «Це легковагове». Ця фраза завдала шкоди.

За тиждень посипались скарги на ноутбуки: VPN відвалюється, Teams замерзає під час дзвінків, весь інтерфейс Windows смикається. IT подумали, що причина — захист кінцевих точок. Розробники звинувачували оновлення Windows. Реальність була простішою: люди цілий день запускали контейнери, і WSL2 VM щасливо розширювався, щоб заповнити пам’ять. Хост почав підкачувати, і все, що потребує передбачуваної затримки, почало хитатися.

Неправильне припущення було не «WSL2 поганий», а «WSL2 за замовчуванням малий». У VM-світі «за замовчуванням» зазвичай означає «без ліміту». Вони виправили це, опублікувавши стандартний .wslconfig (ліміти пам’яті й CPU) плюс внутрішнє правило: якщо потрібно більше, це запит і обґрунтування.

Дивовижне: часи збірки майже не змінились. Інтерактивна стабільність покращилась одразу. Так буває, коли ви припиняєте боротися за останні 2 ГБ RAM, ніби це рідкісний ресурс.

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

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

Потім прийшов відкат: розробники також запускали Windows IDE, браузери й агенти безпеки. Дати WSL2 всі ядра не означає «вкрасти» їх назавжди, але це створило постійну конкуренцію. Паралельні збірки, перевірки стану контейнерів і фонова індексація у WSL2 породили постійні готові для виконання потоки. Windows лишалася відповідальною в тривіальному сенсі (мишка рухалась), але затримко-чутлива робота деградувала: відеодзвінки, демонстрація екрану, навіть набір тексту відчували лаги під навантаженням.

Вони спробували друге «виправлення»: знизити ліміт пам’яті WSL2 і залишити CPU без ліміту. Це перетворило систему на фабрику підкачки. Збірки стали повільнішими, ніж раніше. Ще гірше — непередбачуваними: швидко в понеділок, жахливо у вівторок, залежно від того, що ще запускалось.

Насправді рішення було нудним: обмежити CPU до здорової частки, обмежити пам’ять, щоб захистити хост, і налаштувати паралелізм збірки по проекту. Піковий пропуск знизився трохи. Медіанний досвід розробника покращився значно. У корпоративному середовищі саме медіана важлива.

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

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

Потім вдарило велике оновлення залежностей. Збільшилися пам’ятні потреби збірок, образи контейнерів виросли, локальні тестові кластери стали важчими. Організація без стандартів почала гасити пожежі: «Чому машини плавляться?» Організація з профілем побачила певні уповільнення, але масової нестабільності не стало.

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

Коли оновлення залежностей підвищило потреби, команда платформи обережно відрегулювала базові ліміти і донесла компроміси. Ніхто не був у захваті, але ніхто не втратив день через загадкові лаги. Нудне знову врятувало день. Це по суті SRE в одному реченні.

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

1) Симптом: Windows повільний, у Диспетчері задач видно, що vmmem використовує «занадто багато» RAM

Корінна причина: VM WSL2 розширилася через page cache або використання пам’яті навантаження, і хост під тиском пам’яті.

Виправлення: Встановіть memory= у .wslconfig, потім wsl.exe --shutdown. Якщо потрібно повернути пам’ять негайно — спочатку вимкніть WSL, потім налаштуйте.

2) Симптом: WSL2 повільний, хоча ви «дали йому ліміти»

Корінна причина: Ліміти занадто суворі, і Linux постійно підкачує або звільняє кеш.

Виправлення: Перевірте swapon --show і vmstat. Збільште memory або зменшіть паралелізм навантаження. Не моріть гостя й очікуйте швидкості.

3) Симптом: CPU завантажений, інтерфейс Windows смикається під час збірок

Корінна причина: У WSL2 занадто багато vCPU або інструменти збірки надмірно паралелять потоки.

Виправлення: Встановіть processors= на розумне значення. Також налаштуйте конкаренцію збірки (наприклад, зменште -j або числа воркерів у інструментах).

4) Симптом: vmmem залишається великим після зупинки Linux-процесів

Корінна причина: Page cache залишився виділеним; хостна рекламація не миттєва.

Виправлення: Прийміть це, якщо у хоста є запас. Якщо ні — використайте wsl.exe --shutdown і впровадьте ліміти, щоб воно не росло понад бюджет.

5) Симптом: Диск зайнятий, вентилятори працюють, усе періодично зависає

Корінна причина: Swap і інтенсивна робота з файловою системою (часто Docker overlay) викликають сплески I/O wait.

Виправлення: Зменшіть тиск на пам’ять, очистіть Docker-sховище, уникайте важких збірок на /mnt/c і тримайте swap помірним. Якщо вам потрібна велика пам’ять — оновіть RAM, а не «налаштовуйте» сильніше.

6) Симптом: Мережа здається повільною; люди звинувачують CPU або пам’ять

Корінна причина: Часто це DNS-помилки, взаємодія з VPN або проблеми з localhost forwarding — маскуються під «гальма системи».

Виправлення: Перевірте, чи справді WSL CPU/пам’ять забиті перед налаштуванням. Тримайте localhostForwarding=true, якщо немає специфічної причини відключити.

7) Симптом: Після редагування .wslconfig нічого не змінилося

Корінна причина: Файл у неправильному місці, синтаксис недійсний або WSL не був перезапущений.

Виправлення: Переконайтесь, що файл у шляху профілю користувача Windows, перевірте ключі, потім wsl.exe --shutdown і знову запустіть дистрибутив. Підтвердіть через /proc/meminfo і nproc.

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

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

1. Спочатку виміряйте. Перевірте робочий набір vmmem і тиск пам’яті Windows.
2. Перелічіть, що запущено. wsl.exe --list --verbose, потім всередині WSL перевірте топ-процеси.
3. Визначте бюджет. Виберіть ліміти пам’яті й CPU залежно від RAM/ядер хоста і того, що має залишатися відповідальним у Windows.
4. Застосуйте .wslconfig. Встановіть memory, processors та swap цілеспрямовано.
5. Перезапустіть WSL. wsl.exe --shutdown і перезапустіть дистрибутив.
6. Підтвердьте ліміти. Використайте /proc/meminfo і nproc.
7. Спостерігайте swap. Якщо swap росте під час звичайної роботи — ліміти занадто низькі або навантаження завелике.
8. Виправте навантаження. Зупиніть фонові сервіси, очистіть контейнерне сховище, зменшіть паралелізм збірок.

План B: Якщо ваш ноутбук вже «горить» (режим термінової допомоги)

1. Негайне полегшення: wsl.exe --shutdown.
2. Підтвердіть відновлення Windows: пам’ять знижується, диск припиняє треш і інтерфейс відновлюється.
3. Застосуйте ліміти перед повторним запуском важких робіт: створіть або відкоригуйте .wslconfig.
4. Запускайте лише те, що потрібно: увімкніть один дистрибутив; уникайте автозапуску Docker/Kubernetes поки не підтверджено стабільність.
5. Повторіть план швидкої діагностики: перевірте, чи наступне вузьке місце — CPU, пам’ять чи диск.

План C: Зробити це стійким для команд

1. Стандартизувати базу. Опублікуйте рекомендований .wslconfig для типових tiers ноутбуків (16 ГБ, 32 ГБ).
2. Визначити шляхи ескалації. Якщо комусь потрібно 20 ГБ у WSL2 — це апаратне прохання або стратегія віддалених збірок, а не таємна локальна правка.
3. Навчити, що «кеш — не зло». Навчіть читати available пам’ять, використання swap і I/O wait.
4. Будуйте з бюджетами. CI має відображати реальність; не дозволяйте локальним середовищам розростатися в міні-датацентри без запобіжників.

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

1) Чому WSL2 використовує стільки RAM, навіть коли я «нічого не роблю»?

Тому що Linux агресивно кешує, а WSL2 — це VM. «Нічого» часто включає демони Docker, watcher-и, language server-и і кеш файлової системи. Перевірте free -h і подивіться на available проти buff/cache.

2) Чи безпечно обмежувати пам’ять WSL2?

Так. Це часто правильний крок. Ризик — поставити занадто низько й примусити підкачку або OOM-вбивства всередині Linux. Встановіть ліміт достатньо високим для реального навантаження, а не для оптимістичного.

3) Чому закриття Linux-додатків негайно не зменшує vmmem у Диспетчері задач?

Бо VM може все ще тримати пам’ять для кешу, і хост не відбирає її миттєво. Якщо Windows потребує її зараз — вимкніть WSL. Якщо Windows OK — не панікуйте через число.

4) Чи видаляє wsl.exe --shutdown щось?

Ні. Це завершує екземпляри WSL. Ваші файли й стан дистрибутиву зберігаються на диску. Ви втратите лише сесії в пам’яті, як після перезавантаження.

5) Чи варто ставити swap у 0?

Іноді. Якщо ви віддаєте перевагу швидкому провалу (OOM) замість повільного thrash, відключення swap може бути обґрунтованим. Для більшості розробників помірний swap — страховка. Якщо відключаєте — будьте готові до раптових завершень процесів при тиску.

6) Яке розумне значення для processors?

За замовчуванням — половина ваших ядер. Якщо у вас 8 ядер — дайте WSL2 4. Якщо 16 — дайте 6–8. Якщо ви робите важкі паралельні збірки і Windows інакше проста — підніміть. Якщо важлива інтерактивність UI — обмежуйте.

7) Чи працювати в /mnt/c повільніше, ніж у файловій системі Linux?

Зазвичай так — особливо для навантажень з великою кількістю дрібних операцій з файлами (node_modules, Rust target dirs, шари контейнерів). Тримайте важкі дерева збірок всередині файлової системи дистрибутиву для кращої продуктивності та менше дивних кейсів.

8) Я використовую Docker Desktop з WSL2. Що налаштовувати — Docker чи WSL?

Почніть з WSL2, бо це жорстка стеля для VM. Потім налаштуйте Docker-навантаження (очистіть образи, відрегулюйте кількість реплік у compose, встановіть ліміти пам’яті для контейнерів), щоб залишатися в межах цієї стелі.

9) Чи можна встановити різні ліміти для різних дистрибутивів?

.wslconfig глобальний для поведінки WSL2 VM. Якщо потрібна ізоляція на рівні дистрибутиву — це вже про окремі VMs або інші інструменти, а не лише налаштування WSL2.

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

Шукайте активність swap і I/O wait. Всередині WSL swapon --show покаже, чи використовується swap; vmstat покаже wa і підкачку в/з. Якщо wa високе й swap активний — диск тепер вузьке місце.

Наступні кроки, які справді працюють

Якщо WSL2 «їсть» вашу RAM, не ставтесь до цього як до дивного багу Windows. Ставтесь до цього як до того, що воно є: VM, що запускає справжню ОС з реальним кешуванням. І зробіть те, що роблять дорослі в продакшн-системах: задайте бюджети, вимірюйте й реагуйте на тиск вчасно.

1. Виберіть бюджет сьогодні: встановіть memory і processors у .wslconfig і перезапустіть WSL.
2. Підтвердіть доказами: переконайтесь, що /proc/meminfo і nproc відповідають вашим намірам.
3. Слідкуйте за swap і I/O wait: якщо бачите їх під час звичайної роботи — або підніміть ліміт, або зменшіть навантаження.
4. Не допускайте, щоб важкі сервіси простоювали: Docker/Kubernetes мають бути свідомим вибором, а не фоновим способом життя.
5. Використовуйте shutdown як інструмент, але не як милицю: це чудовий аварійний важіль, але ліміти — довгострокове рішення.

Після цього WSL2 стане тим, чим має бути: надійним Linux-середовищем у Windows. Не небажаним співмешканцем з власною думкою про ваш бюджет пам’яті.