[Serusers] Memory leak?

[Jamin W. Collins]

On Wed, May 28, 2003 at 01:31:45PM +0200, Andrei Pelinescu-Onciul wrote:
> On May 27, 2003 at 13:41, Jamin W. Collins <jcollins at asgardsrealm.net> wrote:
>
> > Nothing like that in the syslog or any other log that I can find.  There
> > are errors in the logs from SER right up to just prior to the reboot:
> > 
> > May 27 09:41:02 hillcrest /usr/sbin/ser[8258]: process_ins_list(): Error
> > while deleting from database
> > May 27 09:41:02 hillcrest ntpd[269]: ntpd exiting on signal 15
> > May 27 09:41:04 hillcrest kernel: Kernel logging (proc) stopped.
> > May 27 09:41:04 hillcrest kernel: Kernel log daemon terminating.
> > May 27 09:41:04 hillcrest exiting on signal 15
> > May 27 09:41:51 hillcrest syslogd 1.4.1#10: restart.
> 
> Probably your debug level is < 4 (4 generates lots of debugging
> messages).

Yea, it's at the default of 3.

> Could you send us the whole log, (or  grep ser syslog), the cfg. file
> and the packet dumps you mentioned? Use serhelp at lists.iptel.org (no limits and
> not public, only ser developers on it). Maybe we can figure out where
> the mem. leak is.

Sent them in to serhelp.

> You could try to start ser with maximum debuging (e.g debug=9) let it
> run a few days under your expected load, then stop it /send SIGUSR1 and
> look in the log for the lines:
> qm_status  
> heap size= ...
> used= ..., used+overhead=..., free
> max used (+overhead)= ...
> 
> for each process.
> 
> max used will be very interesting.

How much (if any) would this impact the performance of the proxy?
Trying to limit the impact to the customer.

> If you do this and max used is close to 1Mb for some processes, then
> please send us the whole log, it would be much easier to catch the
> memory leak.
> 
> BTW: is your ser compiled with DBG_QM_MALLOC?
> (try ser -V, it should be unless you edited the Makefile)

Yes, it has the DBG_QM_MALLOC flag.

-- 
Jamin W. Collins

This is the typical unix way of doing things: you string together lots
of very specific tools to accomplish larger tasks. -- Vineet Kumar