Yes, I prototyped exactly that, and it worked, and yield only a 4x
slowdown in database fetch time, rather than the 18x slowdown that
the RPC mechanism yielded. However, I probably won't initially use
that technique, as I first want to see where the bloat problem is.
Uh, if you use nsproxy to push the BDB access out to a proxy pool,
it'll
help you isolate the problem, won't it? nsproxy pools are pools of
separate processes. If you push your BDB accesses out to a nsproxy
pool, but your nsd memory footprint still grows, then you know the
issue
is elsewhere in your code that's still running in your main nsd.
Right, good catch, I forgot that nxproxy pools run as separate
processes, so yes, that would help catch it.
However nsd exits hard, then the nsproxy pools exit hard too, risking
database corruption.
Is there a way to run an nsproxy pool started by a separate process
from nsd, so that if nsd crashes the nsproxy pool keeps running.
-john
--
AOLserver - http://www.aolserver.com/
To Remove yourself from this list, simply send an email to <[EMAIL PROTECTED]>
with the
body of "SIGNOFF AOLSERVER" in the email message. You can leave the Subject:
field of your email blank.
