1

I have the lowest tier of Google Cloud Compute server. It has a shared CPU with 'burstable' or 'bursting' capability.

For most things I need (an Apache websever + static HTML pages) its fine.

But occasionally, using a console window, I need to run a one-off script, or compile something, or install a new Ubuntu module.

It'll run very fast for 30 secs or so (the 'burstable' bit), then slow to a crawl for the remainder.

What 'burstable' means isn't defined in the documentation.

I've tried playing nicely (i.e. "nice script-name" to lower the process priority), but that makes no difference. I was hoping that this would solve the problem, i.e. use any spare capacity, but any other user gets priority.

Also tried adding a few "sleep 1 second" in scripts, but this makes no difference either.

Any suggestions to avoid being throttled?

5
  • 5
    You mean any suggestions aside from paying more money to get a higher tier server? Commented May 11, 2016 at 16:15
  • No current way round it. Google Cloud Compute support suggesting adding a new feature request to their issue tracker Commented May 15, 2016 at 15:45
  • You could use cgroups to limit the script's CPU usage. Whether or not that's helpful, though, depends on the script and how long it can take to complete its task. I talk about cgroups here: kennystechtalk.blogspot.co.uk/2015/04/… - this is out of date, but the philosophy and mechanism is the same. If I ever figure it out on newer Ubuntus I'll post an answer. As for compiling... you want to do that on a fast computer anyway - you don't need to do it on the cloud instance.
    – Ken Sharp
    Commented Nov 19, 2017 at 19:28
  • 2
    From what I can see my suggestions in the blog post will work, but you can also use CPUQuota in a systemd unit file. Or you can do it all manually by adding to the scripts. CPUQuota=10% for example should stop the process from reaching 10%+ and hence will not be bursty. All depends on how GC implements the burstiness of course. I've only quickly tested with systemd but it worked (to my astonishment!)
    – Ken Sharp
    Commented Nov 19, 2017 at 22:28
  • Amazon's cloud has a feature that implements this. You "earn" a minute (or whatever) of full CPU time per hour of uptime. So, if (say) you've been running a month, you have enough in the bank to do occasional sys admin tasks. Still no progress from Google after 4 years. Commented Oct 1, 2020 at 0:25

1 Answer 1

3

The behavior of shared-core machine types and bursting is documented here. “f1-micro instances get 0.2 of a vCPU and is allowed to burst up to a full vCPU for short periods. g1-small instances get 0.5 of a vCPU and is allowed to burst up to a full vCPU for short periods.”. If needed, you might want to consider the use of an non shared-core machine.

2
  • 1
    Page link to CPU Bursting is documented here: cloud.google.com/compute/docs/machine-types#sharedcore
    – eQ19
    Commented Sep 1, 2019 at 21:05
  • For long-running tasks, you could bring up a larger instance, run the task there, copy the results to the small instance and terminate the larger one. This will still incur a higher cost, but should be much cheaper than upgrading your small instance permanently.
    – deGoot
    Commented Jun 1, 2020 at 14:20

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .