When a machine is paused, I don’t pay for its computing and memory, right?
How to determine, how often a machine is auto-paused (and so I don’t pay for memory and computing), both for:
A machine is un-paused quickly (how quickly?), when it receives a HTTP(S) in message, right?
Hi!
Correct. You do pay for its rootfs storage ($0.15/GB/month).
If the machine is configured with auto_stop_machines = true , it will stop after about 5 minutes of not receiving any requests to any of the configured services or http services. It’s not always exactly 5 minutes, the heuristic is a bit complex and we reserve the right to tweak it or update it, but about 5 minutes is good for estimations.
One very important thing to keep in mind: You have no control over which requests coming from the Internet may hit your machine randomly, and thus wake it up. It’s wild out there. Don’t rely on auto_stop as a measure to control costs: try to see it as a best-effort optimization.
If you have an unmanaged Postgres with the development configuration and auto-stop-on-idle, it will stop after 1 hour with no client connections.
An idle machine is outright stopped - shut down, turned off.
When a request comes in, the machine cold-starts - the actual boot sequence takes milliseconds, but then it’s up to how fast your app can load, start and be ready to start serving requests.
I’ve seen times as short as 100-200 milliseconds for a simple nginx server, and as long as 40 seconds for some insane Node, Python or Ruby apps with tons of dependencies and lengthy warm-up initialization at startup time.
Cheers!
And what’s with managed Postgres?
What? Isn’t it just paused (like hibernation of a laptop), to unpause in less than a second?
Managed Postgres is designed to be a managed, production-grade database - and you don’t want a production database stopping randomly 
so no, no suspend available on Managed Postgres.
generally: no. As I said, they are fully stopped.
If you set auto_stop_machines=suspend, then it does behave like hibernate-to-disk. But here’s the thing: unless your app is molasses slow to start up, they’re usually pretty close in startup times, and suspend gets slower the larger your machine’s memory size is. It doesn’t make sense to use suspend for machines 4GB or larger, because the time to read the memory contents back from disk to start the machine tend to be longer tha the cold-boot start time from a fully stopped machine (although as I said, this depends on the app/framework/other factors). Firecracker VMs boot up really fast!
This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.