[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: spamass-milter - solaris vs redhat
From: |
Dan Nelson |
Subject: |
Re: spamass-milter - solaris vs redhat |
Date: |
Mon, 16 Jun 2003 14:42:50 -0500 |
User-agent: |
Mutt/1.5.4i |
In the last episode (Jun 16), Chuck Yerkes said:
> I've been having these problems with S.A.M. at a solaris 8 site
> (compiled with gcc 2.95.3).
>
> I've been debugging a bit on and off. We've had problems. 500 users
> (for now), 8000 as a goal. But we're having these problems.
>
> With the watchmalloc stuff, the load on a 4x4 E450 (CPU x RAM) shoots
> up.
>
> I've got some logging from Dan to try, but watchmalloc stuff seems to
> be cleaning up (hiding?) the problem. But the load is too high.
Watchmalloc with MALLOC_DEBUG unset should only be slightly slower than
regular malloc. You can also try linking with dmalloc
( http://www.dmalloc.com ), which can be configured to report memory
leaks at program exit.
> We're likely going to TRY a linux box (over some objections cause
> Solaris as very strong support available here right now where linux
> might, later).
>
> There's some string leak, I'm sure. I'm stopping 8 bit mail from
> passing through (just in case). I just don't know/trust the gcc++
> string routines well enough. What happens when a body has a \0 in
> it? Does free() do the right thing?
Free works on malloc blocks, not strings, so it should do fine. the
C++ string type has a length element so nulls won't affect it. I'm
pretty sure that none of spamass-milter's string <-> char* conversions
leak memory.
> Hannu Liljemark wrote:
> > Anyways, there seems to be discussion about message corruption
> > in Solaris and other weird situations. I don't think we've
> > had that problem - at least users haven't reported anything
> > - but another problem seems to be spamass-milter process
> > crashing, and getting bloated over time:
> >
> > % ps -eo user,pid,rss,vsz,nice,nlwp,etime,args|grep spamass-milter
> > spamd 25796 57112 68560 20 6 1-02:07:14
> > /opt/spamass-milter/sbin/spamass-milter -p
> > /var/spool/spamassassin/spamass.sock
> >
> > That had been running for a days (spamass-milter 0.1.3a).
That's definitely huge. What version of sendmail are you running?
libmilter could be the source for your leaks. 8.12.2 fixed a
"theoretical memory leak", at least. dmalloc would be good to try
here, since it should help narrow down what kind of data is leaking.
--
Dan Nelson
address@hidden