Yahoo Groups archive

Milter-greylist

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

Message

Memory leaks in 3.0rc6?

2006-11-22 by Matt Kettler

I know, 3.0 final is out and I should upgrade to it, it's on my todo.

However, this morning I came in to find my milter-greylist running with a vsize
of 975MB. That's substantially larger than I've ever seen it grow to before.
Upon reducing my timeout from 5d to 3d and restarting, it shrank to 8mb. Right
now, 4 hours later, it's up to 17mb.

Looking at the "dumping records" in my maillog, the largest number of records
all week is 40,445. That was at 2:30 this morning.

Right before reload it dumped 34007 records. After reloading due to the shorter
timeout it reduced itself to 23,280 records.

Currently it's got 23,253 records. Which is almost half of what the peak was,
but the memory usage is a factor of 65 smaller than it was earlier. This leads
me to suspect the size problem is something more than just a lot of records.

2:30am	40445 records, unknown size
11am	34007 records, 975m process size (according to top)
11:15am 23280 records 8m process size
3pm	23253 records  17m process size

Currently (3pm) ps reports a vsz of 44692 and a RSS of 5280
		top reports a size 17460, rss of 5264  and share of 3224
I don't have ps info for the other points in time.


Looking at the ChangeLog, I don't see anything that would suggest any leaking or
memory overflows was fixed in 3.0.

3.0
        Fix crashes during dump reloads (AIDA Shinra)
        Fix DoS in MX sync protocol (AIDA Shinra)

Neither of those sounds like they'd cause my excessive memory use problem.

Anyone else seeing similar problems?

FWIW I am using the new DNSBL code, and am using 14 DNSBLs, but those are
actually boiled down to 3 unique lists. (so milter-greylist makes 14 queries,
but 11 of them will be cached because the query is redundant. The difference
being what result-code the test checks for.)

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.