On Wed, 8 Feb 2012, David Carter wrote:
> One small curiosity is that the memory use per IMAP session seems
> to have increased dramatically. I'm looking at the output of the
> Linux "free" command after buffer cache has been subtracted:
>
> 2.3.14: 2572296 KBytes with 2909 IMAP sessions: 884 KBytes/session
> 2.4.13: 3426388 KBytes with 1247 IMAP sessions: 2747 KBytes/session
>
> This is moving from 32-bit SLES 10 to 64-bit SLES 11. I was expecting a
> modest increase as pointers and "unsigned long" double in size.
>
> A 3.1 times increase is rather more than I was expecting. (I'm going to
> try running 32bit binaries on a 64 bit system to see if that makes a
> significant difference).
Two quick experiments reveal:
2.4.13 (32bit binaries, imapd -U 250):
1969752 KBytes with 1484 IMAP sessions: 1327 KBytes/session:
So it looks like x86_64 binaries really are quite expensive.
2.4.13 (64bit binaries, imapd -U 1):
1743176 KBytes with 1182 IMAP sessions: 1474 KBytes/session
"imapd -U 1" stops master from recycling existing imap processes for new
logins. (thanks to Wes Craig for the suggestion here).
The problem with this is that Linux doesn't pass memory which has been
free()ed back to the operating system: it just goes into the pool used by
malloc() in the current process. So once an imapd process opens a large
mailbox, it hangs onto all of the memory which has been allocated there.
All slightly academic as my boss said "yes, just spend the money". But I
thought that the 32bit/64bit experiment might be of interest to others.
--
David Carter Email: David.Carter@xxxxxxxxxxxxx
University Computing Service, Phone: (01223) 334502
New Museums Site, Pembroke Street, Fax: (01223) 334679
Cambridge UK. CB2 3QH.
----
Cyrus Home Page: http://www.cyrusimap.org/
List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
