tal@lemmy.today 3 days ago
Hmm.
A lot of these are going to be just request-driven.
If the idle memory usage is an actual concern…I kind of assume that someone has built some sort of system that works like inetd — you register a port, and then inetd listens on it. When someone connects, it starts up the daemon. Just need to start the container on demand.
smallserverdata@lemmy.ml 3 days ago
Agreed, and this cuts deeper than the sizing question.
Most of these are idle event loops waiting on a socket. The memory is mostly runtime and heap that was allocated and never returned, so on a box under pressure a lot of it is reclaimable or swappable and the RSS I am reporting overstates what is genuinely needed at rest. That is another reason the idle number is weak.
Socket activation is the real version of your point. If an app is genuinely request driven then its idle cost can be near zero and the number that matters is what it grows to on first request and whether it ever gives it back. I do not measure the giving-it-back part at all right now, which I should, because that is the difference between a stack that fits in 2 GB and one that slowly does not.
Adding a post-load settle measurement to the harness is cheap so I will do that. I already sample for 10 seconds after load stops and the peak does not come back down much, but I have not run it long enough to say anything solid.