My host has been tightening it's TOS (to such an extent it seems like anything other than a staticsite is going to violate the TOS ) and my cron seems to be getting killed virtually every time it runs. According to support at my host:
PHP scripts are killed after 2 minutes of execution. Your PHP scripts are being killed around 2 to 3 minutes of execution. For example:
[Mon Sep 11 13:22:57 EDT 2006] KILLING /usr/bin/php belonging to cfalscom (Overrunning PHP process)
[Mon Sep 11 16:02:22 EDT 2006] KILLING /usr/bin/php belonging to cfalscom (Overrunning PHP process)
We may assume that the first one started at 13:20 and the second at 16:00. Please check your script code as it seems to be taking more than expected to complete.
Is there any rule of thumb for the time it should take based on a fairly small site? (Approx 3 or 4 users per day, half a dozen courses, virtually no activity in forums, chat etc.) Not sure where to even begin looking - but am looking for a new host and to go dedicated server.
Any pointers much appreciated.
It all depends on the host's systems, but mine are rarely over 5s nowadays (the largest I've seen is 100s which is when we have a lot of enrolments to do).
A few ideas:
1. Try reading through the admin/cron.php file - and look at the comments so that you're familiar with what the cron.php does and in which order.
2. Also run the cron.php manually from your browser and watch where it pauses and look at the timing info at the bottom of the page.
3. From the developer's comments in the code, one process which may be taking up time is the moodle backups, so consider doing those outside cron, if they coincide with the time of the long cron runs.
Also, in theory, by increasing the number of time cron.php runs (to a limit) the script will have less to do and so you'll reduce it's execution time. So, if you've set cron.php to run every 5mins, try reducing to say 3mins and see how things go - but be careful you don't get any overruns .
Thanks for the response
Looks like it's the backup that's the problem but cest la vie, time to move to a dedicated host anyway.
As for increasing the number of times cron runs - sadly not an option, had it set to run every 10 minutes, one of the reasons I need to move hosts is the new TOS states cron can not be run more than once every 15 minutes
I can see where they are coming from, it is a shared server after all and may be having a detrimental impact on other users, so has just forced me to jump a couple of months before I was going to.
Think you hit it on the head there. The few courses we have are fairly heavy when it comes to resource sizes which I expect, as you say, is what is causing the length of time the cron runs when performing backups.
As mentioned in my reply to Ken, time to move to dedicated so will shortly no longer be an issue.
Thanks for the reply