I've seen this use over 8GB (roughly size of image) in memory, which if there was not enough free would fail even if there is adequate disk space. Running these two commands sequentially without the pipe avoids the high memory usage.
It might be good to offer an option to opt-in for the alternative without using a pipe?
I could be mistaken, I've not tried to use wslcompact on a much larger VM disk to see if the memory required is expected to scale. Doesn't seem like it's affected by the original size, but the compacted export size might be the memory requirement which is being piped?
I recently also ran wslcompact and it was managing at 98% memory usage (32GB system), although I think this was not failing as some other processes that are memory gluttons like Edge will release memory when the system is under pressure.
I did realize I was not going to have enough disk space and pressed Ctrl +C during the operation, VmmemWSL process was using roughly 10GB of memory (nothing else open due to wsl --shutdown). However I wasn't able to release it via explicit wsl --shutdown command (hangs), and the process was not permitted to terminate via the Task Manager.
I vaguely recall something similar with the memory pipe failure I experienced last month. I didn't abort that operation, but the failure didn't release the memory either IIRC.
EDIT: I roughly documented it in the middle of this comment, closing the powershell terminal app didn't make a difference this time, although the memory usage of VmmemWSL process has been slowly reducing over the past hour from 10GB to 2GB presently (now 1.4GB).
I think this is related to the approach to pipe the export to import:
https://github.com/okibcn/wslcompact/blob/b9eee55425820f18d6d48c367f9d1d9e5826efa7/WslCompact/WslCompact.psm1#L95-L97
I've seen this use over 8GB (roughly size of image) in memory, which if there was not enough free would fail even if there is adequate disk space. Running these two commands sequentially without the pipe avoids the high memory usage.
It might be good to offer an option to opt-in for the alternative without using a pipe?
I could be mistaken, I've not tried to use
wslcompacton a much larger VM disk to see if the memory required is expected to scale. Doesn't seem like it's affected by the original size, but the compacted export size might be the memory requirement which is being piped?I recently also ran
wslcompactand it was managing at 98% memory usage (32GB system), although I think this was not failing as some other processes that are memory gluttons like Edge will release memory when the system is under pressure.I did realize I was not going to have enough disk space and pressed
Ctrl +Cduring the operation,VmmemWSLprocess was using roughly 10GB of memory (nothing else open due towsl --shutdown). However I wasn't able to release it via explicitwsl --shutdowncommand (hangs), and the process was not permitted to terminate via the Task Manager.I vaguely recall something similar with the memory pipe failure I experienced last month. I didn't abort that operation, but the failure didn't release the memory either IIRC.
EDIT: I roughly documented it in the middle of this comment, closing the powershell terminal app didn't make a difference this time, although the memory usage of
VmmemWSLprocess has been slowly reducing over the past hour from 10GB to 2GB presently (now 1.4GB).