Memory usage

I was wondering if anyone has any recommendations.

I currently normally have around 500-1400 incoming connections at any given time.

That causes a combined usage of gps + spawn to use something around 2-3gigs of ram.

In order to trim ram usage, I looked at other options, tried gld in production, but it makes postfix go nuts, not sure exactly what is going on, other than postfix isn't servicing the connections as fast anymore (around 10k incoming connections). Switch back to gps and everything goes much faster.

gld was looking nice, cause it was only using about 1/4 of the memory gps uses.

I haven't dig into the code (maybe I should), but I would love to switch this over to some kind of select polling method, so all postfix could connect to one gps program, and gps can have 1 or more mysql connections open to use.

Or if anyone has any other tips (I already have a dynamic 600k entry blacklist/whitelist in in postfix before it hits gps)

Forums: 

Hi

thanks for this feedback. I wonder how you measure the memory usage of gps. When I was initially planning it I came to the conclusion that the server/client solution (e.g. used in gld) doesn't make much sense for a such a small program that really just parses some text and does one or two sql queries. Most of the code would actually be in shared libraries (stdc++, libmysqlclient, etc). That would hardly use any additional memory.
I now think that there is a flaw in the design of gps mainly because it keeps the sql connection during its entire lifetime. I am considering a configuration switch to open/closes the sql connection after each policy request from postfix.
But I am not totally sure whether that is going to improve anything so I'd be really thankful for your input.

Thanks,

mimo

Well, I was using two different ways to check memory usage, one was just adding up all the RSS values of all the different procs, the second was to compare memory stats using gps vs memory stats using something else. They seem to match pretty close.

The other issue, is normally had 3gigs of free memory, and when connections spiked up to around 1000+ smtp connections, those 3gigs of ram would be all gone, and it would start swapping. Now using policyd instead, going from 200 connections to 1000 connections only uses 1.5gigs of extra ram (just smtpd usage, instead of smtpd+spawn+gps)

The memory usage is probably mainly from mysql, loading in shared libs saves memory, until the shared lib requests a block of memory to save state infomation into, then that memory is locked to that process only.

I do like the policyd method, just sit it on a port, and let many threads all share the same one, since smtpd only needs to use it once per smtp connection, and sits idle for long (in computer realitive terms) time idle between.

The overhead of policyd does annoy me, but doesn't seem to be slowering me down personally.