New on LowEndTalk? Please Register and read our Community Rules.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
Comments
RAM ballooning
Thank you brother, this worked beautifully. Cheers
Thanks to @forest also.
@angstrom can you please close this one? Thank you
Your RAM is not dedicated.
Hostnode is out of RAM.
Your provider is overselling the RAM.
Fucked if true. Might as well add swap to avoid crash
tbh after the blacklist, the ram have not moved a bit. Its 4GB all the time.
His provider is already using SWAP. Adding more SWAP will make the VM slow as F.
Ah, 😅
How do you know they are using swap?
Btw, I don't think this thread needs to be closed. I think it could be a useful discussion about the provider in question.
Usually, memory ballooning should only kick in in an emergency. It's possible (and I have no idea if it's true) that there is just a transient increase in memory pressure for reasons unrelated to overselling. For example, perhaps a node failed and its VMs had to get distributed among the remaining nodes, and there's not enough memory to go around.
In theory, memory ballooning is great and allows more equitable allocation of resources. Just like sharing physical cores, most guests will not max out their resource usage at the same time. But in practice, the ballooning driver can't communicate to the guest's memory management system that the "stolen" memory is not gone for good. It just triggers the memory hotplug subsystem, so the kernel suddenly sees total memory go down and starts to freak out, thinking that it's just lost a whole lot of wiggle room. Now it'll start evicting reclaimable pages, disk I/O skyrockets as mapped pages need to be repeatedly faulted back in, and performance overall suffers.
It would be a lot better if the ballooning driver could communicate to the host that the guest needs more memory so that it can be returned when needed. That way, the host could act as if nothing was really stolen from it and could treat the process the same way it treats virtual memory overcommit. But that's not the world we live in.
@forest Note: This VM is in virtualizor node.
Anything using QEMU supports memory ballooning. Is Virtualizor the only one that supports seamlessly enabling it or something?