Your machine may become sluggish as it struggles to run resource-hungry host processes like Google Chrome or your favorite IDE alongside VM processes. Whatever the case may be, if your machine doesn’t have enough memory to begin with, then you’ve probably seen some noticeable slowdowns due to WSL 2.
Since I’m running a Windows 10 build that’s older than 20175 at the time of this writing, my WSL reserves 80% of my host RAM (8 GB), which in this case is 6.4 GB. On my system, that shows the following output, where each number is in gigabytes: total used free shared buff/cache available You can check how much memory and swap space are allocated to WSL using the free command from within a WSL distribution: free -h -giga On builds older than 20175, WSL could consume up to 80% of your host RAM. On machines running build 20175 or higher, RAM is limited to either 50% of your total memory or 8GB, whichever happens to be smaller. According to Microsoft’s documentation, the amount of RAM that gets allocated to WSL depends on your Windows build number. This special process represents all the resources consumed by your Linux VM while WSL is running. The best way to install the htop is using snap because it works well on any of the Linux distros.If you’ve ever opened up Task Manager while WSL 2 was running on a Windows machine, you’ve probably noticed a process named vmmem hogging a sizable chunk of your memory and slowing down your machine.
In most of the distros, the top is installed by default, and we have to install the htop manually. In this, we can also scroll horizontal as well as vertical. As compared to the top, the htop UI has better quality. The htop's default display is more user-friendly. On the other hand, the htop command offers a better quality-of-life experience. In terms of system monitoring both commands offer the same functionality.
Each value indicates how much time the CPU spends performing a task. In the above output, the main line to focus on is the line number third.
0 kommentar(er)
