I've alleviated the memory-exhausted problem by jacking up the php memory limit to 32M. I also set the php-accelerator cache to 16(M). However on re-starting apache the php-accelerator seems to be in a bit of sulk. phpa_cache_admin is now reporting
No shm cache available with key ....
Anybody else had much exerperience of running php-accelerator with Moodle?
I had some problem that looks the same as these.
I increased the memory for PHP-accelerator, but when I set it
more than 30 MB phpa stops working.
I never find a solution for this issue, but since there are more PHP apps running on my webserver, I excluded some not frequently used software for the phpa SHM.
I'm using Linux 2.4.19, PHP 4.2.2, apache 1.3.26.
What OS are you using?!
Did realy stop all the apache processes?!
You can try to flush the SHM and disk cache of PHPA before you apache restart.
Hope this helps.
With kind regards,
Huib van Wees
Personally I had nothing but trouble with php-accelerator and moodle. This was both on my test machine running standard Debian Woody packages and the main server (soon to be Debian by the looks of it) running standard Red Hat 7.2 everything. Strangely no one else mentioned problems though? Tried all the options too.
No problems at all with Turck MMCache though. We're using 2.3.23. It has to be compiled from source but this was easy enough provided all the necessary "dev" packages are in place.
Good Luck, Paul.
What sort of system are you running?
I wish I had an Alpha, but it is a x86 cpu.
But did it work before the change of the memory settings?!
Good point about letting apache die, the restarts have been necessarily pretty swift. I've switch phpa off for a day and then try again (that will be next week now)
Yes, it gave every indication of running before I changed the memory settings, not that the site felt much different. On my development system (similar but running PHP 4.3.3) the effect of adding phpa (with the default settings) on a page which takes about 10 seconds to create is not really noticably. phpa_cache_admin gives
mempool size 8.0MB
mempool bytes allocated 65.1KB
mempool max bytes allocated 7.9MB
mempool bytes free 7.9MB
mempool overhead 8.2KB
and /tmp has about 11M of files begining phpa.... (On the production server these files took about 26Mbyes.)
Going back to tweaking some of the options...
I share my PHPA experience with you
RedHat 7.2 (kernel 2.4.7-10)
Machine PIII - 1000 Mhz (Coppermine) with 1156 Mb RAM (512+512+128)
In php.ini , memory_limit = 32 M (16M was even too less after a while)
php-accelerator uses 8M Cache (standard)
Main goal for the machine is to provide Moodle and a Content Managing System called Typo3. Moodle has about 250 participants, and still growing.
The combination php <--> phpa worked very well for a while, then troubles begin ... a complete "hang " of the machine, no service was reachable remote nor local. It had to reset the machine 3 times.
Then I decide to disabled phpa in php.ini and now it runs without phpa for a few days. From things I read on the net, php4.1.2 doesn't seems to be a "reliable" choise.
"phpa - people" blaim php4.1.2 and not phpa ...
Still don't know what went wrong, can't find anything suspecious in log-files. I even have a Intrusion Detection System (Snort) running to better understand what is going on. Maybe it was an attack that "killed" the machine but no ...
I really miss the performance now, with phpa it was a lot faster ...
If I can find time I will try MMCache, another php accelerator.
I'm also testing Moodle on FreeBSD 5.x which will replace my "old" RedHat 7.2 , the only problem is the time ...
My server appears to have got it's PHPA cache memory together over the weekend (apache and mysql close themselves down each night bless them, I found it easier to handle the logs that way) Anyway phpa_cache_admin is now reporting sensible (but high) figures now. I reset the cache to 16M and it says 15.3M is allocated with the max allocation of 15.9M. All a bit worrying high?
The performance is still disaapointing. I was I looking for an improvement in the speed of the code. The server is not gets all that many hits. I was hoping that some of the pages would just speed up when running through lots of code. I guess PHPA doesn't do that. It just helps a server which is gets loads of hits.
Those memory sizes seem too large ... but I don't have any immediately helpful suggestions beyond what's already been discussed. Try upgrading PHP 4.1.2, though ... that's YEARS old now ...
I think Moodle 2.0 should split up each module lib.php into two files ... one with "central" functions and one with "local" functions. to help reduce the amount getting parsed by things like Recent Activity.
I'm running the Exercise module with a big class (nearly 500 students) and the database now has about 5000 assessments and 2000 submissions. Some the teacher's pages were begining to creak. On my development machine one page was taking about 30 seconds to build and another about 50 seconds. (On the production server the pages were taking about a fifth of those times but it was begining to feel distinctly slow.) As I said earlier in this tread PHPA was not improving matters.
Then I looked at the actual processes on the server. What was using up 90% of the CPU during the building of these particular pages was MySQL. Ah, I had that problem before, adding an index or two was the answer then. And it was again.
Adding an index to the assessment table and another to the submission table got the times down from 30 seconds to 5 seconds and from 50 seconds down to 10 seconds. (Which translates on the production server to very quick and quick.) Now looking at the cpu usage of Apache and MySQL it's roughly equal with, if anything, Apache (that is PHP) needing the greater share.
With the database not hogging all the cpu (as it did without the extra indices) PHPA could well improve matters a bit. Although I would not expect too much of an effect (as the database will not be speeded up, just hit a bit harder)
One other thing I have found. When running PHP 4.3.3 and the matching PHPA both seem happy with 24M of memory. PHP itelf seems to want more than 16M. The PHPA cache reports about 12M of the 24M is used once Moodle has run through a few pages.
Anyway, as you can see, you still will have problems with database access. Than can be solved using latest version of MySQL 4.0.x (currently 4.0.16), wich is now stable and does have a good query cache that makes Moodle much faster. Adding indexes would help too, but you are hacking normal Moodle behaviour, and those kind of thing could be bad for the manteinance of your server (Moodle upgrades and so on). Perhaps it is not the case, when talking about indexes, but it is better not to take any risks on that.
By the way, back to the increasing memory usage... I don't mean to point the finger but one gets an indication of the reason for this is starting to happen recently from looking at the lib.php sizes in kilobytes:
> cd mod
> du -sk */lib.php | sort -nr
How about we separate lib.php into two files?
core.php - contains all the main functions needed by core services as well as any functions they depend on.
lib.php - contains all the other functions for the module
I could modify the core services to check for lib.php if core.php wasn't found, which should preserve backward compatibility while modules are converted (note that that all the module files will need to include both manually).
How does that sound?
My own thoughts on a naming convention were lib.php for the "global" services and modlib.php for the extra internal routines needed by the module. That way the recent activity, grades... polling routines wouldn't need changing. But I'm happy with either way.
modlib.php (or libmod.php for nicer listing!) may cause a little confusion with mod.html I suppose (which actually works in concert with the core lib.php!) ... but I can't think of much better .... lib2.php ?
Without Turck MMCache:
Avg 4622 ms
Median 2241 ms
Deviation 5375 ms
With Turck MMCache
Avg 110 ms
Med 57 ms
Deviation 207 ms
I was truly stunned by these numbers!
phpa.enable_php_memory_bug_workaround = 1I also recently increased my PHPA cache on this server to 32M and it improved things a great deal.