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. ---- Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
