28 May
2003
28 May
'03
12:22 p.m.
On May 28, 2003 at 08:46, Jamin W. Collins <jcollins(a)asgardsrealm.net> wrote:
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).
thanks
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
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(a)asgardsrealm.net> wrote:
[...]
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(a)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.