>Why isn't this the default (or at least a configuration option)?
Because 1) you still need a second machine to wait for incoming requests, 2) in a server there's no general way to check if the server is serving requests or not. Plex happened to provide an API that specifically does what you needed, but you had to resort to a bit of a hack for Time Machine. This is unlike a desktop context, where you can check if the user has moved the mouse or pressed a key in the last N minutes. And 3) because the delay of waiting for the server to wake back up is undesirable.
>Seriously, there is soooo much potential to save energy in IT.
I don't think so. For VPS instances it doesn't matter, and for internal servers it's almost certainly more efficient to virtualize a bunch of services onto a single box, if there's multiple servers idle most of the time.
your VPS will have a shared CPU with hundreds of other customers... So will probably be using far less power (for you) than your home server.
In Europe at least, most industrial users were paying more for electricity than residential users over the winter (gas shortage). Governments subsidized residential users more than most businesses.
And doing this is not going to largely affect the energy usage of the EU - at least, in comparison to, say, Dell putting Platinum rated PSUs in their workstations and AMD making good server chips that are twice as efficient at the same performance point as Intel's chips.
Ok, the implementation wasn’t very fantastic cost wise. However I still think this could be a big area of improvement. How can we reduce energy usage of servers?
There’s a lot of work with ARM lately, I’m curious if that could be used in server workloads like this.
The most effective way is to be able to dynamically distribute load across a large array of servers, turning some off at times of lower load. Anyone who runs a large datacenter probably already does this or something equivalent, either to save money or to service more customers with the same amount of hardware. It's more effective to optimize the hardware architecture, but it's worth noting that improvements in efficiency usually don't translate to reductions in power consumption. Instead, it causes induced demand and usage increases to fill available capacity.
> Anyone who runs a large datacenter probably already does this or something equivalent, either to save money or to service more customers with the same amount of hardware.
Possibly, but few cloud providers actually do live migration[0] since it's risky to pause a VM for typically less than 1 second, but up to 5 seconds.
Real world pause times for live migration are mostly imperceptibly small. Like, you might as well have a router glitch for the same whatever milliseconds.
To demonstrate Ceph RBD network block storage back in the day, I ran VNC sessions to two libvirt hosts and live migrated a full VM with a desktop and a bouncing ball animation in a window between the two hosts & VNC sessions. The only thing a human could perceive was that the desktop image in one VNC window goes black, and the animation continues in the other.
I was actually thinking about elastic AWS instances when I wrote that. IIRC they're meant to be spun up and then shut down as a service's demand varies.
VPS providers are already overprovisioned anyway, so they have less idle hardware to begin with.
Isn't that really expensive? Far more expensive than just keeping a cluster running 24x7? I think the much bigger cost here is shelf space and the hardware, and so the retail price isn't impact much by the cost of power.
For the record I like the concept and hope it becomes a lot cheaper over time.
Because 1) you still need a second machine to wait for incoming requests, 2) in a server there's no general way to check if the server is serving requests or not. Plex happened to provide an API that specifically does what you needed, but you had to resort to a bit of a hack for Time Machine. This is unlike a desktop context, where you can check if the user has moved the mouse or pressed a key in the last N minutes. And 3) because the delay of waiting for the server to wake back up is undesirable.
>Seriously, there is soooo much potential to save energy in IT.
I don't think so. For VPS instances it doesn't matter, and for internal servers it's almost certainly more efficient to virtualize a bunch of services onto a single box, if there's multiple servers idle most of the time.