General help

Hi Mary

HNY 2009!

I have read some useful comments on this from Amr Hourani (no doubt you have found those too).

On that basis I think the first thing to do is enter phpMyAdmin (probably via cPanel)
- assuming that you are on MySQL (not a Microsoft MSSQL Server) and open the table mdl_log.

If you click the Browse tab, does it show 30 rows, but report many THOUSANDS?

Now click the SQL tab above the table contents and paste in...

SHOW TABLE STATUS LIKE 'mdl_log';

(note that THIS command seems to require the trailing ; when many others don't!)

You should get something like the attached... but is your Data_length huge?
Approaching the max_data_length?
Is Data_free very low?
Is Auto_increment huge?

If this is the case you should either be able to force the table to allow more that 4 GB space (as Amr suggests), or copy relatively recent logs into a new table mdl_log_old and then TRUNCATE this one, automatically deleting all its contents and resetting autoincrement to 1. If you need more on this, just say so.

If the size of the log file has become a problem then you probably have the default setting 'Never delete logs' in Site Administration->Server->Cleanup, and frankly you could just reconsider the worth of this position! Changing this setting and then waiting for cron to do its work (I presume) might be all that's needed anyway!

Hope something here helps.

Regards,
John

PS: If your log file is not huge, then the above could all be a red herring!!!

Mary - Before checking the stuff that John suggests (which I think are good suggestions), I might first verify that it is not simply a corrupt table. When I have seen a failed insert on mdl_log it has often been because the mdl_log table became corrupted (this seems to be more common with mysql). Using phpmyadmin, I would first try to repair the mdl_log table. Peace - Anthony

I had such an issue after mooving my production server to a VMware virtual machine. Despite importing the moodle database through a dump, the system began to timeout with database connection errors.

One of my investigations threads resulted in the mentioned insertion error in the moodle-log table. As I had 1.4 million rows I truncated (emptied) the table with phpMyAdmin, but after a few days mysqld began to hang again. So I turned off all cron-jobs of moodle, i.e. nightly backups (truncated also this table because it had also a lot of rows) and statistics (maybe I truncated also these few tables) and I truncated mdl_log again. I tryied also

myisamchk -a -S /var/lib/mysql/moodle/*.MYI

as proposed in a moodle-doc. You have to shut down mysqld to do this. It seems to rebuild the indexes and I have no clue what the difference is, compared to CHECK, REPAIR or OPTIMIZE TABLE you can use directly on the mysql prompt or in phpMyAdmin.

After that mysqld recovered normal operation and I enabled course backups again. Seeing that nightly backups and statistics cumulated a lot of CPU-time on mysqld, I switched off statistics again and reduced backups to Mo, We and Fr. It may be worth mentioning that our site has 2'500 courses and 8'000 users, increasing!

On the VM ESX with SUSE 11 I still did not get a stable operation and hence migrated back to the previous physical server. I am still investigating on my VM since, which seems to time-out or serve Moodle-Pages very quickly if not under load, but starts to eat 18 secs and more to return a page if under load (e.g. 100 concurrent wget in a loop).

I described my nightmare in another thread because more than one reason was involved (http://moodle.org/mod/forum/discuss.php?d=125702)

Rosario