CPU with burst capability, cpu throttling and sys admin tasks

83 views
Skip to first unread message

Andrew Murphy

unread,
May 13, 2016, 8:58:46 AM5/13/16
to gce-discussion
Hi

I have a small shared (f1) instance. The CPU has a burst capability.

Its used for a low use Apache web server with static HTML files, so 99.99% of the time that's fine.

Occasionally, I need to run one-off programs, e.g. install a software update, or run a Perl script to update the HTML files. 
=> They "burst" for the first 30 seconds or so, then slow to a crawl for the remainder.
=> Which is a drag waiting for it to complete. 
=> e.g. Installing the newest version of Perl (or anything else for which no Ubuntu module available yet)  would take ages.

1) Is there an (SLA compliant) way around it, e.g. using "nice"?

2) Or, could 'burst' be changed to allow for occasional sys-admin tasks that require occasional but sustained resources? There be a new class of burst-cpu machine to allow for this need.

3) Or, could an instance be live-upgraded (then downgraded afterwards) within the same class of machine (say f1 to/from g1) from without stop/starting it, i.e. pay more for the extra resource only when needed
(i.e. you could do this now by stopping it, starting it as a new machine type, installing updates, stopping it, restarting as the original type, but A) downtime, B) a drag)

Thanks

Andrew
 

Faizan (Google Cloud Support)

unread,
May 13, 2016, 4:50:16 PM5/13/16
to gce-discussion
Hello Andrew,

Kindly find the answer to your questions below.


On Friday, May 13, 2016 at 8:58:46 AM UTC-4, Andrew Murphy wrote:
Hi

I have a small shared (f1) instance. The CPU has a burst capability.

Its used for a low use Apache web server with static HTML files, so 99.99% of the time that's fine.

Occasionally, I need to run one-off programs, e.g. install a software update, or run a Perl script to update the HTML files. 
=> They "burst" for the first 30 seconds or so, then slow to a crawl for the remainder.
=> Which is a drag waiting for it to complete. 
=> e.g. Installing the newest version of Perl (or anything else for which no Ubuntu module available yet)  would take ages.

1) Is there an (SLA compliant) way around it, e.g. using "nice"?

 
You can use nice on your instance to priorities the CPU usage.
 
2) Or, could 'burst' be changed to allow for occasional sys-admin tasks that require occasional but sustained resources? There be a new class of burst-cpu machine to allow for this need.

These machine types are currently not available. 

3) Or, could an instance be live-upgraded (then downgraded afterwards) within the same class of machine (say f1 to/from g1) from without stop/starting it, i.e. pay more for the extra resource only when needed
(i.e. you could do this now by stopping it, starting it as a new machine type, installing updates, stopping it, restarting as the original type, but A) downtime, B) a drag)

This feature is not available. 

Please feel free to file a feature request through Google Compute Engine issue tracker. Once done, let me know I'll go ahead and send it to the product engineering team for review.

I hope that helps.


Thanks

Andrew
 
 

Andrew Murphy

unread,
May 14, 2016, 7:27:57 AM5/14/16
to gce-discussion
Hi

Thanks for the reply

Issue # 332

Paul Nash

unread,
May 17, 2016, 1:54:48 AM5/17/16
to gce-discussion
Hi Andrew, thanks for filing your request. This is an interesting use case, definitely something we'll think about. In the meantime, I wanted to note that if you are planning to perform significant updates to your server, there might be a couple other options you can try:

1) The easiest way is to change the machine type. This can only be done on a stopped instance, however, so you'll need to stop, change, reboot (and then again when done).

2) If you would prefer to avoid downtime, you could create a snapshot of the instance's disk, then start a second instance, creating a new disk out of that snapshot. Then spend as much time as you want configuring (and testing?) that instance. When you're ready, shut down the instances and switch the disks so the new disk is running on the small instance. Be careful when creating the snapshot to flush disk buffers if you're going to snap a running VM.

Sorry, I haven't had a chance to try these ideas out in detail or give you detailed instructions, but thought I'd pass you some concepts to play with that would be possible to achieve what you want. You can take these further with features like Managed Instance Groups and Instance Group Updater to do the cutover for you, but this may be overkill for your scenario.

Thanks,
-P
Reply all
Reply to author
Forward
0 new messages