Cyrus 2.4.13 memory use

[Bron Gondwana]

On Wed, Feb 08, 2012 at 04:19:42PM +0000, David Carter wrote:
> We are currently in the process of migrating from 2.3.14 (with lots
> of local patches) to a fairly vanilla 2.4.13.
> 
> 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:
> 
>               total       used       free  shared  buffers   cached
> Mem:       8239436    7206520    1032916       0  426276    4207948
> -/+ buffers/cache:    2572296    5667140
>                        ^^^^^^^
> 
>   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).
> 
> pmap and /proc/[pid]/smaps suggests that most of the increase is in the 
> heap segment which is used by malloc() and the brk() system call.
> 
> It looks like 3000 IMAP sessions are going to take around 8 GBytes of RAM 
> just to run, and we will need to buy additional RAM for buffer cache. This 
> isn't the end of the world: memory is cheap. I'm just curious if anyone 
> else saw a similar increase when upgrading from 2.3 to 2.4.

I played a bit fast and loose with memory in 2.4.  You'll find that large
mailboxes take quite a bit more memory when selected.  It was a tradeoff
against extra locking.  We could save quite a lot by requiring changing
how index state is stored, and just store the mutable flags (modseq,
system_flags, user_flags and is_seen/is_recent) for each record rather
than the entire 'struct index_record'.  At the cost of some code complexity.

Bron.