On May 28, 2003 at 08:46, Jamin W. Collins jcollins@asgardsrealm.net wrote:
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@asgardsrealm.net wrote:
[...]
Probably your debug level is < 4 (4 generates lots of debugging messages).
Yea, it's at the default of 3.
I just changed the log level for the mem. status messages to 3 on cvs, for the new version. (I think it's better to get the mem. status on program exit and still be able to filter out the other dbg. messages).
Could you send us the whole log, (or grep ser syslog), the cfg. file and the packet dumps you mentioned? Use serhelp@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.
thanks
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.
It should work without any visible impact for 100-200 cps. It might be ok for more (depends also on syslog speed, disk a.s.o). It will also write huge logs (so if your /var partition is small ...). You might consider also setting log_stderr=yes and starting ser with ser 2>/tmp/ser_log.
BTW: if you want maximum speed from ser, change Makefile.defs: remove -DDBG_QM_MALLOC and add -DF_MALLOC -DNO_DEBUG. -DNO_DEBUG will kill most of the debug messages (but you don't see them anyway since you are running ser with debug=3). -DF_MALLOC will use a much faster malloc version, w/o any debugging code.
Andrei