I know this is off-topic, but please excuse as I think it has more chance of getting an appropriate audience.
We have been having problems with backups of large-ish courses not completing in 1.8.2+ (regardless of user data). The complete site grinds to a complete halt when the backup is running - you can do nothing.
This in logs...
[Tue Sep 18 15:45:07 2007] Script: '/usr/local/apache/htdocs/vet/moodle/index.php'
Zend/zend_language_scanner.c(4645) : Freeing 0x087EFD44 (5 bytes),
script=/usr/local/apache/htdocs/vet/moodle/index.php
Last leak repeated 34 times
[Tue Sep 18 15:45:07 2007] Script: '/usr/local/apache/htdocs/vet/moodle/index.php'
/packages/php-5.2.2/Zend/zend_compile.c(249) : Freeing 0x087F347C (192 bytes),
script=/usr/local/apache/htdocs/vet/moodle/index.php
Last leak repeated 2 times
[Tue Sep 18 15:45:07 2007] Script: '/usr/local/apache/htdocs/vet/moodle/index.php'
/packages/php-5.2.2/Zend/zend_compile.c(3602) : Freeing 0x087F3568 (4 bytes),
script=/usr/local/apache/htdocs/vet/moodle/index.php
Last leak repeated 4 times
[Tue Sep 18 15:45:07 2007] Script: '/usr/local/apache/htdocs/vet/moodle/index.php'
/packages/php-5.2.2/main/spprintf.c(727) : Freeing 0x087F3B58 (79 bytes),
script=/usr/local/apache/htdocs/vet/moodle/index.php
=== Total 1089 memory leaks detected ===
I've never seen logs like this. What's going on? ...or where do I look next?
Some quick notes...
First - don't run cron under apache! That's for toy sites only, there's a good chance that switching to using the commandline php will help you resolve it. When you setup the cronjob, make sure that the output is logged somewhere you can review later. For example, my cron entries (in /etc/cron.d/moodle ) usually look roughly like
*/15 * * * * www-data (php4 -c /etc/php4/apache/php4.ini /path/to/moodle/admin/cron.php 2>&1 ) >> /path/to/moodledata/logs/moodlecron.log
1 1 * * * www-data savelog -q /path/to/moodledata/logs/moodlecron.log
In the above, you'll see some practices
- be explicit as to which PHP I want to execute (on some boxes we have both v4 and v5!)
- be explicit as to which config file -- and make that the same config file apache uses to avoid configuration mismatches
- run it under the same user as apache does (nobody in redhat, www-data in debian)
- run it only every 15
- store stderr and stdout in moodlecron.log so you can debug problems -- in your case, doing this means that you'll see under what module it's dying
- use savelog to rotate/compress logs daily as they can grow to several gigs
Second -- there are some bugs in backups of large courses being worked that could be affecting you. MDL-11160 springs to mind.
Thanks Martin -
this was actually a "manually" run backup, does this still apply? As you are being explicit about the php version, does this imply that you would recommend a particular variety?
this was actually a "manually" run backup, does this still apply? As you are being explicit about the php version, does this imply that you would recommend a particular variety?
Ah! If it is a manual backup, what you need is more hands helping replace get_records() with get_recordset() in the backup code... PHP version won't change a thing 
I can maybe bring some effort to bear....
Is there more info/discussion somewhere?
Is there more info/discussion somewhere?
See MDL-11160 - search the tracker...
Mmm... I did. But, it looks a bit like an argument to me! Not sure I want to get involved 
This may have nothing to do with memory leaks or enrolments. Can you try turning on the Moodle debugging up to full and also MySQL logging, then try it again while watching to see what happens? You might see it hanging on an obvious SQL statement or PHP error.
For MySQL Logging, add this:
For MySQL Logging, add this:
log=/tmp/mysql_query.logto your [mysqld] section in your my.cnf file (then restart MySQL).