The reason ours got killed is that we're running quipu 8.0 which seems
to have really bad memory leaks. Our dsa, while processing that edb
update, hit the sbrk maximum and couldn't get any more memory. It
tried to restart, but the new EDB causes it to grow beyond the 20MB
limit at startup time!! The dsa spent about 30 hours restarting until
we noticed, that is, it would start, try to read c=US/EDB, which now
has the huge edbinfo from Long Bud, and then sbrk would fail and next
it would try to restart, and repeat the loop.
At this point, we have several options: a) increase the max sbrk value
per user in the kernel (the quick, dirty, fix), b) fix the edb related
memory leaks. If there are any other options, pls tell me so.
The reason I'm posting this is b). I've noticed that the quipu's
memory leak appear to be really bad at edb processing time. Before
going into the debugger and studying all the edb code, I thought it to
be wise to ask around here for any bug fixes. Am I lucky? :)
I have to confess that I don't have much hope of getting anything,
judging from experience in these X.500 mailing lists, but who knows,
perhaps some merciful soul out there might send me some pointers as to
what or where to look.
X500'ly yours
----------------------------------------------------------------
Luis P. Caamano (LC2385) | lpc@sware.com
SecureWare, Inc. Atlanta, GA, USA | (404) 315-6296
E-mail privacy by SecureMail, see http://www.secureware.com/