Your problem is most likely the Tcl memory allocator, and
fragmentation that can occur within the pools. There have been some
posts detailing these issues a few months ago I think.
Ah, ok.
One thing to try is building Tcl so that it doesn't use the
threaded-allocator, and to instead try something like Hoard or
Google's tcmalloc. Now all that aside, is it really a big deal to
do rolling restarts?
Right restarting is not something I like to doing, because most of
the time when I ctrl-c aolserver, it exists uncleanly with one of
these errors:
21597 aborted
or
called TclFindHashEntry on deleted table
or
open database file handle at exit: (db name)
and side-effects of this unclean exit are:
1) incomplete database operations (and I don't use transactions, so I
get dangling records) that need to get cleaned up (ie, referential
integrity is broken)
2) the possibility of database corruption (since I'm using
berkeleydb) if I shut down hard in the middle of a database write,
which has occurred a few times, and required an export to text/
reimport to fix.
3) anxiety
All these things *may* be caused by bugs in the berkeleydb/aolserver
driver, I realize this. So, I'm going to a simple Tcl RPC mechanism,
which will be slower (18x, by my benchmarking), but safer and then
I'll know if the bloat & stability problems are due to berkeley or
aolserver/tcl. Also, I'll be able to do scheduled restarts if I
separate aolserver from the database server, rather than having them
both be in process.
-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.
