When I run “fly scale vm dedicated-cpu-1x” to change the VM type from shared-cpu-1x, it causes all apps to stop instantly and brings up the new ones. This causes downtime for the app while the new VMs boot.
Is there a way to avoid this?
I was just looking at the docs and it seems not:
What would be handy is if that scale command supported the --strategy flag. That flag seems designed for this very problem: how to replace running instances. That is supported for e.g fly deploy:
I guess if it’s not a production app you could try adding that flag to see what happens. Maybe it will be rejected, or do nothing, or maybe it is supported but just not documented.
Scaling VM sizes uses the rolling strategy by default. That strategy will will do 50% of your instances (max: 10) at a time.
Is your app slow to start?
We should probably tweak the rolling strategy to do less at once in any case.
That’s true. Especially since we now have a rolling_one strategy that will only do 1 instance at a time.
@iamliamnorton I just looked at your app and I’m pretty sure I know what’s happening.
When you run fly vm scale it does a rolling update. If you run something like fly scale count <x> before the rolling update is finished, it implements both changes immediately. It looks like your app is getting very quick vm scale + scale count commands issued to it pretty frequently.
When you run
fly vm scaleit does a rolling update. If you run something likefly scale count <x>before the rolling update is finished, it implements both changes immediately. It looks like your app is getting very quick vm scale + scale count commands issued to it pretty frequently.
Ahh yes, this is what I’ve done a few times and could be related. I will avoid this moving forward.