Yahoo Groups archive

Milter-greylist

Index last updated: 2026-04-28 23:32 UTC

Message

Re: [milter-greylist] DOes SPF cause memory leak?

2008-10-23 by Petar Bogdanovic

On Thu, Oct 23, 2008 at 10:07:32AM +0000, Emmanuel Dreyfus wrote:
> On Thu, Oct 23, 2008 at 11:53:10AM +0200, Petar Bogdanovic wrote:
> > On Thu, Oct 23, 2008 at 09:46:35AM +0000, Emmanuel Dreyfus wrote:
> > > On Thu, Oct 23, 2008 at 11:17:15AM +0200, Petar Bogdanovic wrote:
> > > [SPF may be the culprit for memory leaks]
> > > 
> > > Which libspf do you use? We support 3 of them.
> > 
> > libspf_alt
> > I will try mail/libspf2 from pkgsrc but which one is the third one?
> 
> libspf (neither alt, nor 2)
> 
> Reading the documentation, it seems that for libspf, SPF_close does not
> free memory,and free() must be called on the peer_info_t obtained from
> SPF_init(). Anyone can confirm?

It apparently has nothing to do with libspf since I get similar results
with libspf_alt and libspf2 (1.2.8). The situation even got worse with
libspf2 from another point of view -- milter-greylist using libspf_alt
claimed about 15% of the CPU when it had to deal with 900 simultaneous
connections while the same situation ate every second of the available
CPU-time when linked against libspf2. That's why I wasn't able to drop
the same amounth of mails through milter-greylist+libspf2: the CPU was
the bottleneck.


      milter-greylist + libspf2

   3008K 1248K sigwait    0:00  0.00%  0.00%  <-- mg started
   3404K 3272K RUN        0:07 65.73% 27.83%  <-- 900 sim. connections
   3520K 3388K RUN        0:21 191.17% 63.09%
   3624K 3492K RUN        0:35 96.25% 80.37%
   3736K 3604K RUN        0:49 103.25% 89.31%
   3848K 3716K RUN        1:03 99.97% 93.60%
   3964K 3832K RUN        1:17 98.97% 95.51%
   4072K 3940K RUN        1:31 97.95% 96.34%
   4188K 4056K RUN        1:45 98.26% 97.12%
   4304K 4172K RUN        1:59 97.56% 97.12%
   4400K 4268K RUN        2:13 97.41% 96.97%
   4520K 4388K RUN        2:27 97.54% 97.12%
   4620K 4488K RUN        2:41 97.28% 97.12%
   4728K 4596K RUN        2:56 97.58% 97.31%
   4840K 4708K RUN        3:10 96.79% 96.73%
   4936K 4804K RUN        3:24 96.84% 96.73%
   5056K 4924K RUN        3:38 96.48% 96.44%
   5188K 5052K RUN        3:52 95.69% 95.65%
   5288K 5156K RUN        4:06 94.99% 94.97%
   5416K 5284K RUN        4:20 94.83% 94.82%
   5520K 5388K RUN        4:35 95.27% 95.26%
   5652K 5520K RUN        4:49 114.61% 95.70%
   5768K 5636K RUN        5:03 96.19% 96.19%
   5872K 5744K RUN        5:17 103.06% 97.12%


      milter-greylist + libspf_alt

   3008K 1248K sigwait    0:00  0.00%  0.00% <-- mg started
   3584K 3648K sigwait    0:03 29.87% 15.77% <-- 900 sim. connections
   4008K 4100K sigwait    0:04 15.45% 12.01%
   4568K 4676K sigwait    0:06 14.30% 12.79%
   5112K 5220K sigwait    0:08 14.95% 14.21%
   5656K 5764K sigwait    0:09 14.00% 13.67%
   6180K 6296K sigwait    0:11 14.96% 14.79%
   6704K 6824K sigwait    0:12 14.14% 14.06%
   7272K 7392K RUN        0:14 14.63% 14.50%
   7752K 7872K sigwait    0:16 13.59% 13.57%
   8308K 8428K sigwait    0:17 14.17% 14.16%
   8876K 8996K sigwait    0:19 14.90% 14.89%
   9408K 9528K sigwait    0:21 15.87% 15.87%
   9960K   10M sigwait    0:22 15.63% 15.62%
     10M   10M sigwait    0:24 16.16% 16.16%

Attachments

Move to quarantaine

This moves the raw source file on disk only. The archive index is not changed automatically, so you still need to run a manual refresh afterward.