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
    You mean any suggestions aside from paying more money to get a higher tier server? – Ryan Bolger May 11 '16 at 16:15
  • No current way round it. Google Cloud Compute support suggesting adding a new feature request to their issue tracker – Andrew Murphy May 15 '16 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 Nov 19 '17 at 19:28
  • 1
    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 Nov 19 '17 at 22:28
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.

| improve this answer | |
  • 1
    Page link to CPU Bursting is documented here: cloud.google.com/compute/docs/machine-types#sharedcore – Chetabahana Sep 1 '19 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 Jun 1 at 14:20

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.