On May 12, 2009, at 1:23 PM, Gustaf Neumann wrote:
Janine Sisk schrieb:
When I first started working on this problem, the settings were
ns_param maxconnections 5
ns_param maxthreads 5
ns_param minthreads 5
maxconnections of 5 is for most applications to small. The term
"maxconnections" is misleading since it does not mean "maximum
number of incoming connections", but is a counter per thread, when
it will shut down. With the value above, every thread will exit
and be recreated after 5 requests. If the application is well written,
no garbage should be left after the request, therefore the value can
be set to e.g. 1000.
Interesting - I did not know that. I don't have much faith in this
application to be well written so I haven't made this change yet, but
I will try it next.
I changed minthreads to 0, which dramatically sped up server
restart time, and increased connections/threads first to 50/10 and
then 100/20. I didn't see much of an increase in the last change
so I left it there.
when start with minthreads 5 takes long, you seem to have quite a
slow machine.
Do you have some usage figures, how many concurrent users you have
to serve?
By concurrent, i mean running requests at the same time.
Unfortunately I have no idea; they process their own stats and so far
have not shared (I have asked but they keep forgetting).
The system is not the best, but it shouldn't be this bad. I've
watched the error log as the site comes up and there is a lot of added
"stuff" going on in the CMS, looks like it's loading in something from
the database. It shouldn't be this slow, but I'm leaving delving into
the code as a last resort because it looks like quicksand.
You can as well increase the threadtimeout to reduce the number of
thread restarts
....
ns_param threadtimeout 120
I commented out the maxopen/maxidle and dropped the connections to 20
each. I didn't notice the 300 - that was clearly out of whack.
With just those changes I'm still seeing the nsd process consume 50%+
of the CPU from time to time but it looks like it's happening for a
shorter period of time most of the time, so that is at least an
improvement.
Thanks!
janine
....
regarding the pools:
I would recommend to comment out the "maxidle" and "maxopen"
values (were needed for old aolserver versions) and - more important -
to reduce the number of connections. When you have maxthreads
at a low value (e.g. 20), you should not need more than e.g. 20
connections for the first two pools.
ns_section ns/db/pool/pool1
ns_param maxidle 1000000000
ns_param maxopen 1000000000
ns_param connections 300
ns_param verbose $debug
maybe the 600+ connections you have makes things slower than
needed.
best regards
-gustaf neumann
--
AOLserver - http://www.aolserver.com/
To Remove yourself from this list, simply send an email to <lists...@listserv.aol.com
> with the
body of "SIGNOFF AOLSERVER" in the email message. You can leave the
Subject: field of your email blank.
---
Janine Sisk
President/CEO of furfly, LLC
503-693-6407
--
AOLserver - http://www.aolserver.com/
To Remove yourself from this list, simply send an email to
<lists...@listserv.aol.com> with the
body of "SIGNOFF AOLSERVER" in the email message. You can leave the Subject:
field of your email blank.
