Further to Steve's message, the Apache processing module on Windows is
mpm_winnt.
http://httpd.apache.org/docs/2.0/mod/mpm_winnt.html
This is analogous (but not identical) to the mpm_worker module, so your
key setting for preventing too much memory usage by Apache is
ThreadsPerChild.
Open Windows Task Manager and click the "Processes" tab. Sort by "Image
name". You should see two Apache processes (either called "Apache.exe"
or "httpd.exe"). One will have virtually no CPU usage, have less memory
allocated of the two, and be running a very small number of threads.
This is the control process.
The other will be using much more CPU, have more memory allocated and
have many threads running. This is the child process that is serving
client requests. The number of threads should be the value of
ThreadsPerChild. Look at the memory usage. If the child process is
consuming too much memory, reduce the value of ThreadsPerChild and
restart Apache. If the memory seems within acceptable limits, your
problem may lie elsewhere.
I note in your original message that you're running Moodle 1.8.7. The
database queries in accesslib.php (for roles and capabilities) were
substantially rewritten in 1.9, and I've seen claims of a thousandfold
increase in performance for certain queries. Whether that would have a
significant impact on your memory usage, I don't know, but an upgrade
probably wouldn't hurt.
Finally, I'm sure you've already seen this, but just in case:
http://docs.moodle.org/en/Performance
Chris
> -----Original Message-----
> From: List dedicated to technical discussions about Moodle
> [mailto:[log in to unmask]] On Behalf Of
> Stephen Baxter
> Sent: 19 May 2009 09:10
> To: [log in to unmask]
> Subject: Re: Performance problems
>
> Barbara,
>
> It's possible that your server is creating too many apache2
> processes under heavy load.
>
> You need to check that your Apache2 config is suitable for
> the machine it's running on. I'm only used to Apache on Linux
> but spent quite some time tuning my Apache config to suit the
> machine Moodle is running on. It's a LAMP so MySql instead of
> Postgre.
>
> Here are the key settings from my apache2.conf which may help
> you: My machine has 4Gb of RAM and dual procs so these
> settings should be fairly similar for you. I'm not saying
> they're perfect there's a lot to learn yet !
>
> As a rough guide I will have no more than 20 apache processes
> active at once defined by the MaxClients setting (each
> process is around 100Mb each so apache can never take up more
> than 2Gb 50% of server's physical RAM ). In the worst case
> scenario of extremely high load apache is prevented from
> getting "too big".
>
>
> Timeout 15
> KeepAlive On
> MaxKeepAliveRequests 1000
> KeepAliveTimeout 2
>
> # I don't know which process model you use so there are
> settings for both
>
> <IfModule mpm_prefork_module>
> StartServers 5
> MinSpareServers 5
> MaxSpareServers 10
> MaxClients 20
> MaxRequestsPerChild 10000
> </IfModule>
>
>
> <IfModule mpm_worker_module>
> StartServers 2
> MaxClients 20
> MinSpareThreads 25
> MaxSpareThreads 75
> ThreadsPerChild 25
> MaxRequestsPerChild 10000
> </IfModule>
>
> HostnameLookups Off
>
>
>
>
> Hope that helps !
>
> Steve Baxter
> IS Programmer
>
>
>
> ________________________________________
> From: List dedicated to technical discussions about Moodle
> [[log in to unmask]] On Behalf Of Taliesin
> Nuin [[log in to unmask]]
> Sent: 18 May 2009 13:28
> To: [log in to unmask]
> Subject: Re: Performance problems
>
> Sorry, just to clarify something else looking at your post a
> second time. You said that Moodle's memory usage spirals up
> to 1GB. Which process actually has that memory allocated to
> it? Is it the postgreSQL process or Apache itself? If the
> latter, then something is definitely snafu'd. Please confirm
> what you meant.
>
> Regards,
>
> Taliesin.
>
> Taliesin Nuin wrote:
> Barbara Lawrence wrote:
>
> Can anyone offer any advice on how to tune a windows / apache
> / postgresql
> system? Our setup is regularly experiencing problems with
> moodle's memory
> usage mounting to over 1,000,000 k, and the system stalls.
> Restarting the
> server is the only way to get it going again. Moodle is
> running on a dual
> Xeon 2.00 ghz processor with 4Gb RAM, and we recently moved
> the database to
> a separate server with a similar spec. This has not improved
> the situation -
> if anything it is worse.
>
> We are running Apache 2.2.10, PHP 5.2.6, Moodle 1.8.7,
> PostgreSQL 8.2. We
> had similar problems a few months ago, which I thought was
> due to the known
> Windows "memory leak" which occurs with certain combinations
> of apache / php
> versions. Upgrading to out currentversions of Apache / PHP did show
> considerable improvement but now it is happening again (maybe
> because the
> number of users has increased?).
>
> I have autovacuum set to on for postgres, but don't do any
> other regular
> vacuuming. Should I?
>
> Any suggestions gratefully received.
>
>
> Barbara,
>
> This is a very big area. I am also, only familiar with
> running Apache and PostgreSQL on Linux / UNIX / Solaris boxes
> rather than Windows, which might limit how much I can help.
>
> How large is your installation, e.g. number of courses,
> number of users, roughly how active. The specifications you
> listed ought to be at least reasonable and there PostgreSQL
> is certainly capable of doing a very good job.
>
> As *initial* suggestions, I would propose the following:
>
> Check the indexes on your database, using the XMLDB tool
> built into Moodle. You run this from within Moodle by going
> from the Administration block to Miscellaneous->XMLDB
> editor->Check Indexes. If any indexes are reported missing,
> then that is likely your problem.
>
> If the first doesn't reveal any problems (or I'm explaining
> the obvious to you for which I apologise), I would recommend
> trying slow query logging on the live system (assuming you
> can't replicate the problems on a copy). In the
> postgresql.conf file you should find a variable called
>
> log_min_duration_statement
>
> Set this to some suitable number, e.g. 300 for 300
> milliseconds, and it will write difficult queries to the log
> file (sorry - don't know exactly where this would be on
> Windows). You can then have a look through and see if
> anything leaps out. Again, I'm kind of looking for broken
> indexes, etc. That it is eating up so much memory suggests
> something of this kind to me. I don't know a great deal about
> optimising postgreSQL as I've only ever used it for fun,
> really - not had the opportunity to deploy it in heavy
> environment. If you can't identify any problems with the
> actual database and do want to look into serious performance
> tuning, I'd first try looking at this resource:
>
> http://www.revsys.com/writings/postgresql-performance.html
>
> (The query optimisation obviously isn't an option without
> branching your code, but there's a good section on general
> tuning.) And as a second step, join the
> comp.databases.postgresql newsgroup for some really serious
> expertise on tap.
>
> Hope this helps. As said, I think you *probably* have a more
> fundamental problem than tweaking performance paramaters, but
> I could well be wrong. Let me know the size of your
> installation and it might be possible to ballpark whether
> your servers are up to spec (I think it is likely that they are).
>
> Taliesin Nuin.
>
> ________________________________
>
> Email the way you want it - scanned for viruses and unwanted
> content by the Email Protection
> Agency<http://www.epagency.net/email_filtering_services.htm>
> If you consider this email spam, please forward it to
> [log in to unmask]
>
> ********************************************************
> This email and any files transmitted with it are
> confidential and may be legally privileged and
> are intended solely for the use of the individual
> or entity to whom they are addressed. If you
> are not the intended recipient please notify the
> sender named above immediately by email. Any
> use, disclosure, copying or forwarding of this
> email and/or it's attachments is unauthorised.
>
> Charity Number (SC021189)
>
> Dumfries and Galloway College
> Bankend Road
> Dumfries
> DG1 4FD
> TEL: +44 (0)1387 734000
>
> ********************************************************
> This email has been scanned for viruses by the Email Protection Agency
> For more information please visit http://www.epagency.net
> __________________________________________________
>
Please access the attached hyperlink for an important electronic communications disclaimer: http://www.lse.ac.uk/collections/secretariat/legal/disclaimer.htm
|
