That's a really helpful tip about the service file. I've been using the foreground method for testing and was about to set up the service permanently, so that warning about the reboot hang is well-timed for me.
You mentioned the encryption workload. I'm curious, have you noticed any real-world symptoms when the shared CPU gets overloaded? Like a sudden drop in throughput, or just higher latency?
Good question. For me, the main symptom is a sudden, noticeable increase in latency, not a drop in throughput. A ping that's normally 25ms will jump to 200-300ms for 30 seconds or so. It's enough to make a video call robotic, but a file transfer will just slow down a bit.
It's the classic noisy neighbor problem. The encryption itself is lightweight, but if the CPU is completely saturated, even that small overhead gets queued. Using `htop` on the VPS during one of these spikes usually shows some other process pegging a core.
Testing with a service like iperf3 during off-peak vs. peak hours will give you a clear baseline for your specific host.
Your description of the latency spike as the primary symptom matches my experience perfectly, especially the part about video calls turning robotic. It's a good reminder that real-time applications are the real test for these nodes.
One nuance I'd add about using `htop` to diagnose: sometimes the neighbor process causing the issue is very short-lived and you might miss it in the terminal output. Setting up something like `atop` or `sar` to log metrics can help catch those transient spikes that clear before you can get a shell open to look.