On 20 February 2010 05:52, Lukasz Szybalski <[email protected]> wrote:
> Hello,
> Reading your post on
> http://blog.dscpl.com.au/2009/03/load-spikes-and-excessive-memory-usage.html
>
> I was wondering if you could comment on "the next step" after going
> deamon modwsgi way. How to conclude that optimization is required?
>
> Going with deamon mode made it easy to deploy apps, and the article
> explains nicely why prefork or worker vs deamon or embeded will apply
> to different kind of scenarios. The safest bet is deamon to start with
> but what after you find your app "slowing down" after few months.
>
> I'm at the point where the "trac" deployed via modwsgi in deamon mode
> is using up to 80% cpu at times. 120K tickets+
> WSGIDaemonProcess trac threads=30 processes=3 maximum-requests=10000
> WSGIProcessGroup trac
> WSGIScriptAlias /UWtrac /home/trac/trac/apache/trac.wsgi
>
> The service slowed down critically at one point (up to 7sec for new
> page to display), until I moved the database to a separate server. So
> now I have one apache server servicing the app, and one for mysql
> database.
>
> After reading your blog my next questions would be:
>
> 1. How do I find out if I have prefork or worker? When I do, what will
> be my next step? How will I know I need to switch? Is it my
> configuration or is it the app?
> 2. iostat -x -d 5 tells me my hdd utilization is below 10%
>
> Device: rrqm/s wrqm/s r/s w/s rsec/s wsec/s
> avgrq-sz avgqu-sz await svctm %util
> sda 0.00 30.25 0.25 10.75 2.00 328.00
> 30.00 0.06 5.00 0.55 0.60
> sda1 0.00 0.00 0.00 0.00 0.00 0.00
> 0.00 0.00 0.00 0.00 0.00
> sda2 0.00 30.25 0.25 10.75 2.00 328.00
> 30.00 0.06 5.00 0.55 0.60
> dm-0 0.00 0.00 0.00 41.00 0.00 328.00
> 8.00 0.17 4.17 0.10 0.40
> dm-1 0.00 0.00 0.00 0.00 0.00 0.00
> 0.00 0.00 0.00 0.00 0.00
> dm-2 0.00 0.00 0.25 0.00 2.00 0.00
> 8.00 0.00 8.00 8.00 0.20
>
>
> 3. munin tells me that cpu utilization is somewhat high, around
> 10apache processes (not sure what does that mean for me). I was
> wondering if you could look at the pdf attached and tell me (something
> that jumps to your eye) and maybe tells you ..."this is a problem"?
> What would be a problem in my case?
>
> 4. The next step after this? Is the utilization normal/ abnromal? more
> cpu? more ram? switch to worker? and what tells you that?
I'd suspect more that the CPU being hit is because of Trac itself
and/or database. Have seen a number of discussions on Trac lists in
the past with heavy CPU usage issues.
How much traffic does site get?
What is typical and worst case request time?
Having 30 threads per process is possibly excessive and on a multi
core system with processor intensive Python code could start trigger
performance issues around the Python GIL due to Python thread
scheduling issues.
As asked in another post, can determine whether worker or preform MPM
by running:
httpd -V
When you work that out, post the appropriate snippets from Apache
configuration showing MPM settings. For example:
# prefork MPM
# StartServers: number of server processes to start
# MinSpareServers: minimum number of server processes which are kept spare
# MaxSpareServers: maximum number of server processes which are kept spare
# MaxClients: maximum number of server processes allowed to start
# MaxRequestsPerChild: maximum number of requests a server process serves
<IfModule mpm_prefork_module>
StartServers 1
MinSpareServers 1
MaxSpareServers 10
MaxClients 150
MaxRequestsPerChild 0
</IfModule>
# worker MPM
# StartServers: initial number of server processes to start
# MaxClients: maximum number of simultaneous client connections
# MinSpareThreads: minimum number of worker threads which are kept spare
# MaxSpareThreads: maximum number of worker threads which are kept spare
# ThreadsPerChild: constant number of worker threads in each server process
# MaxRequestsPerChild: maximum number of requests a server process serves
<IfModule mpm_worker_module>
StartServers 2
MaxClients 150
MinSpareThreads 25
MaxSpareThreads 75
ThreadsPerChild 25
MaxRequestsPerChild 0
</IfModule>
Graham
--
You received this message because you are subscribed to the Google Groups
"modwsgi" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/modwsgi?hl=en.
