Akeeba Backup for Joomla!

Saturday, 26 January 2013 04:11 CST

rbradbury

Mandatory information about my setup:

Have I read the related troubleshooter articles above before posting (which pages?)? Yes - Any other Akeeba Backup related question
Have I searched the tickets before posting? Yes
Have I read the documentation before posting (which pages?)? Fine Tuning
Joomla! version: 1.5.26
PHP version: 5.3.20
MySQL version: 5.1.66-cll
Host: Rochen
Akeeba Backup version: 1.5.26

EXTREMELY IMPORTANT: Please attach a ZIP file containing your Akeeba Backup log file in order for us to help you with any backup or restoration issue. If the file is over 2Mb, please upload it on your server and post a link to it.

Hi Nicholas

Description of my issue: Rochen advise that their shared hosting daily CPU limit of 2% has been exceeded - 2.78% usage over a 24 hr period. (The site comprises an SMF forum with approx 100 users/day accessing it - however the site is 3GB in size due to its 13 year history)

My question is will tweaking the Fine Tuning settings reduce average daily CPU usage, not just the peak CPU usage?

Further details:

The CLI initiated overnight backup appears top of the Process list - the backup is large at 2GB and uploads to Amazon S3

Top Process %CPU 59.2 /usr/bin/php5-cli /home/laverdaf/public_html/administrator/components/com_akeeba/backup.php
Top Process %CPU 49.0 /usr/bin/php /home/laverdaf/public_html/forum/index.php
Top Process %CPU 48.4 /usr/bin/php5-cli /home/laverdaf/public_html/administrator/components/com_akeeba/backup.php

Searching on 'CPU usage' suggests that adjusting fine tuning settings will reduce CPU usage. My question is will it reduce average usage - presumably the job still makes the same calls, just throttled back over a longer period of time?

Original settings Min execution 0.5sec; Max execution 25sec; Bias 95% with 200MB chunks uploaded to S3 (immediate processing) which delivers a completed archive in ~14 mins

Revised settings (for which log attached) Min execution 0.5%; Max 18 sec; Bias 75%

Thanks & regards

Bob

Saturday, 26 January 2013 04:20 CST

nicholas

While Akeeba Backup is taking a backup (but not while it's merely uploading the backup archive to S3) it uses a lot of CPU and memory. This is by definition. Backing up a site means that you need to access all of its files and database and put them in a compressed backup archive as fast as possible. The corollary is that CPU and memory usage spikes. However that takes a relatively very low amount of time. Uploading to S3 uses hardly any CPU. It's a network-intensive, not a CPU-intensive, task. Therefore there is no need to change any of your backup settings. The only thing you'd achieve is making the backup take longer.

I mean, thing about it. You have a 50% CPU spike during 14 minutes every day. 14 minutes per day is 50% CPU usage over 0.97% of the day, or a 0.485% of the server's maximum daily CPU usage. Even if you spread it to a longer timeframe (e.g. the backup taking 2 hours instead of 14 minutes) you'd end up with the same percentage of daily CPU usage. Actually, you'd end up with slightly (~0.05%) more daily CPU usage because of the overhead involved whenever Akeeba Backup breaks and starts a backup step. What's more important is this:

Top Process %CPU 49.0 /usr/bin/php /home/laverdaf/public_html/forum/index.php

Your forum which is accessed hundreds of times every day throws CPU spikes. If you want to reduce that 2% CPU usage this is where you should be looking.

Nicholas K. Dionysopoulos

Lead Developer and Director

🇬🇷Greek: native 🇬🇧English: excellent 🇫🇷French: basic • 🕐 My time zone is Europe / Athens
Please keep in mind my timezone and cultural differences when reading my replies. Thank you!

Saturday, 26 January 2013 06:55 CST

rbradbury

Nicholas - thanks for a detailed quick reply and 'doing the maths' on the CPU spike ..... should have done that myself instead of jumping to the wrong conclusion. It's also useful to know how the various backup and archiving processes / timings impact the server.

I'll take a closer look at site traffic now - I'd overlooked that as presently configured, our forum users don't need to be logged in which means the SMF stats may be misleading.

Best regards

Bob

Saturday, 26 January 2013 07:05 CST

nicholas

Your request did make sense. After all, the documentation refers to "CPU usage" and tells you that the timing options are the solution. But that is trying to solve a different CPU usage issue. Many servers don't allow CPU usage spikes. What they actually do is check how many CPU seconds a particular user account consumes in a predefined amount of time (in the area of a few seconds to a couple of minutes). If that's over a threshold they kill the running scripts. In this case we want to "spread" the CPU usage to a bigger amount of time. With the timing options we end up creating a short spike (0.5-2 seconds), then have a long "quiet time" (5-7 seconds), artificailly lowering the CPU usage over the short amount of time the kernel gets to measure*. The end result is that backups get to run on those servers.

Since you are interested about the overall CPU usage in the course of 24 hours, it is impractical to spread the backup over more than 24 hours; you'd end up backing up a very inconsistent state of your site. Moreover, the contribution to the CPU usage is so small that it makes no sense.

Well, now you have the full picture and you understand why I couldn't write that stuff in the troubleshooting documentation which is meant to be read by the average user :)

* To any pedantic Linux kernel developers: yes, OK, this is technically not 100% accurate but I'm trying to give the executive summary here.

Nicholas K. Dionysopoulos

Lead Developer and Director

🇬🇷Greek: native 🇬🇧English: excellent 🇫🇷French: basic • 🕐 My time zone is Europe / Athens
Please keep in mind my timezone and cultural differences when reading my replies. Thank you!

Support