Od jakiegoś czasu komputer jakoś muli, a nie obciążasz go bardziej, niż zwykle. Zaglądasz do Menedżera zadań a tam jakiś Vmmem wysysa 8GB pamięci. Co robić? Jak żyć? Co to za zwierz ten Vmmem?
Przypominasz sobie, że jakoś tak niedawno ustawiałeś Docker Desktop, żeby uruchamiał się przy logowaniu do Windows. Zaglądasz do niego, a tam zonk – 7GB bez ani jednego działającego kontenera. To właśnie tyle, ile zabiera Vmmem według Menedżera zadań.
Zbieg okoliczności?
To nie jest przypadowa korelacja. Jaki jest związek między Vmmem a dockerem? Docker Desktop domyślnie uruchamia docker engine w WSL2, bo to ma zapewniać lepsze osiągi, niż silnik uruchomiony bezpośrednio jako proces Hyper-V. O tym mówi nam zakładka Settings | General. Zatem linuxowy silnik dockera uruchamiany jest w WSL2, który jest uruchamiany… jako maszyna wirtualna. Vmmem to wirtualny proces pokazujący zużycie zasobów przez wszystkie maszyny wirtualne. Bingo! Czyli Vmmem pokazuje nam także naszego żarłocznego dockera. Jesteśmy blisko 🙂
I co teraz?
Teraz wystarczy nakłonić WSL, by zmitygował swoją pamięciożerność. Jak on dostanie mniej, to i docker dostanie mniej. Logika by wskazywała, żeby ograniczyć samego dockera, ale nie znalazłem odpowiednich ustawień. Pozostaje WSL. Wszystko to opisał Microsoft tutaj. Ja podam tylko kilka dodatkowych uwag.
W trzech komputerach z W10 nie znalazłem pliku konfiguracyjnego .wslconfig, który mógłbym poddać edycji. Trzeba go utworzyć samodzielnie w folderze C:\Users\uzytkownik. Mój plik wygląda tak:
# Settings apply across all Linux distros running on WSL 2
[wsl2]
# Limits VM memory. This can be set as whole numbers using GB or MB
memory=4GB
# Sets the VM to use two virtual processors
processors=2
# Sets swapfile path location, default is %USERPROFILE%\AppData\Local\Temp\swap.vhdx
#swapfile=X:\\temp\\wsl-swap.vhdx
# Sets amount of swap storage space to 8GB, default is 25% of available RAM
swap=8GB
# Sets to turn on or off support for GUI applications in WSL. Only available for Windows 11.
guiApplications=falseOstatnia linia jest nieco na wyrost, bo nie korzystam z W11. Żeby zmiany odniosły skutek, należy zamnąć wszystkie maszyny wirtualne. Na początek sprawdź, jakie działają. Możesz użyć polecenia wsl -l -v. Potem zamknij w kontrolowany sposób te, które zidentyfikujesz (np. zamykając Docker Desktop zamkniesz te związane z konteneryzacją). A jeśli na koniec zostaną jakieś jeszcze, to pomoże wsl --shutdown. Na koniec uruchom Docker Desktop, a przekonasz się, że zajętość RAM spadła poniżej 3GB.
Jeśli ktoś ma wymagające szybkości kontenery, to swap file można umieścić na jakimś szybkim dysku (np. tanim jak barszcz 16GB Intel Optane M10). Na powyższym listingu ta opcja jest zakomentowana. Pamiętaj, że folder \temp\ musisz utworzyć samodzielnie. Teraz wystarczy poobserwować, jak sprawują się nasze kontenery ze zmniejszoną pamięcią i w razie potrzeby dokonać korekty. Z mojego doświadczenia wynika, że dość wymagający MS SQL Server z niewielkimi bazami nie ma problemu z 4GB, a zaczyna protestować (ostrzeżenie w logach) poniżej 2GB.