I've been scanning the forums for a while now, and I have given up trying to find someone with the same symptoms I do.
Moodle performance MOST of the time is good. At any given time in the afternoon it handles about 30 simultaneous users without any problems.
However, without warning... during some peak usages in the afternoon, about a hundred simultaneous database connections start piling up, but the strange thing is they are almost all idle.
Once this happens people trying to access moodle get the usual "database connection problem" message because PostgreSQL won't allow any more connections to be opened.
The odd thing is... the machine starts to slow down.. (as in a linux server load value close to "50".. sometimes even "100"), but not much cpu or disk io is being used... then it slips into a crashed state and I actually have to do a hard reset.
I did not set moodle to use persistant connections and I did not enable stats.
Any ideas?
Here are my specs:
Moodle 1.6.1+
dedicated IBM x440 server ( 8 cpu P4 xeons with HT enabled) ,
Hosted on a university connect
10 gigs of ram.
HBA FibreChannel SAN disk (fibre optic connection to network attached storage... huge raid array),
Gentoo linux kernel: linux-2.6.15-gentoo-r1
Apache 1.3.31
PHP 4.3.9
PostgreSQL 8.1.4
Performance problem leading to complete crash.. ON A SUPERCOMPUTER
Number of replies: 5Re: Performance problem leading to complete crash.. ON A SUPERCOMPUTER
i´ve got almost the same problem (with an earlier version)
are you using moodle "as is" or has any customization?
aditional modules?
are you using moodle "as is" or has any customization?
aditional modules?
Re: Performance problem leading to complete crash.. ON A SUPERCOMPUTER
I'm using it "as is".
The only real custom stuff I've done, involves inserting enrollment directly into the mdl_user_students table via a script that runs in the early morning. I'm quite sure that has nothing to do with the problem.
I'm curious are you using PostgreSQL 8.1.4 ? I'm wondering if its a database server bug.
The only real custom stuff I've done, involves inserting enrollment directly into the mdl_user_students table via a script that runs in the early morning. I'm quite sure that has nothing to do with the problem.
I'm curious are you using PostgreSQL 8.1.4 ? I'm wondering if its a database server bug.
Re: Performance problem leading to complete crash.. ON A SUPERCOMPUTER
we are using mysql 4.1.xx
i discovered our problem was the default mysql table format (MyISAM) locks the entire table when querying.. so we´ll change to InnoDB table type, that locks just the register... avoinding a query queue on the server... i suposed (and hope) this gonna work..
i wonder if there is nothing similar on postgress that could be the cause of your problem
memory and process parameters are also important (max clients and max connections, for apache and your database)
there is a formula that defines max_clients somewhere on this forum...
and more important: there is a moodle/admin/dbperformance.php file that can helps a lot...
cheers
i discovered our problem was the default mysql table format (MyISAM) locks the entire table when querying.. so we´ll change to InnoDB table type, that locks just the register... avoinding a query queue on the server... i suposed (and hope) this gonna work..
i wonder if there is nothing similar on postgress that could be the cause of your problem
memory and process parameters are also important (max clients and max connections, for apache and your database)
there is a formula that defines max_clients somewhere on this forum...
and more important: there is a moodle/admin/dbperformance.php file that can helps a lot...
cheers
Re: Performance problem leading to complete crash.. ON A SUPERCOMPUTER
I'd take a crack at upgrading PHP to see if that makes any difference!
good luck!
Dan
good luck!
Dan
Re: Performance problem leading to complete crash.. ON A SUPERCOMPUTER
I'd say the problem is not in moodle 
Have you read this forum much? There are heaps of stats you can monitor (and post info on) that will lead you to find the culprit. In this case, I'd definitely think the output of sysstat would be interesting. Actually, search this forum for sysstat, you'll find other bits and pieces. Post back with that info
Hmmmm. Here's an idea: more concurrency means apache takes more memory. Maybe it's hitting some flaky parts of the memory OR it tries to use swap and hits a bad disk sector or SCSI controller bug?
Run memtest on it for a couple of days, spin the disks silly...
Have you read this forum much? There are heaps of stats you can monitor (and post info on) that will lead you to find the culprit. In this case, I'd definitely think the output of sysstat would be interesting. Actually, search this forum for sysstat, you'll find other bits and pieces. Post back with that info
Hmmmm. Here's an idea: more concurrency means apache takes more memory. Maybe it's hitting some flaky parts of the memory OR it tries to use swap and hits a bad disk sector or SCSI controller bug?
Run memtest on it for a couple of days, spin the disks silly...