Details
Blocker Description
Possible candidate for 2.5.1, given it's easy fix.
Based on MB-7887. And particularly on runs comparing older 2.2.0 builds and newer 2.2.0 builds (after 2.2.0 release, I guess those were purely for hotfixes or who knows what) we see tcmalloc memory fragmentation regression. I.e. here: https://www.couchbase.com/issues/secure/attachment/19549/10KB-1MB_250Items_10KB_delta.log
We see 2.2.0-821 (GA) is having:
2014-02-11 03:57:31 | INFO | MainProcess | MainThread | [remote_util.log_command_output] detailed: NOTE: SMALL MEMORY MODEL IS IN USE, PERFORMANCE MAY SUFFER.
2014-02-11 03:57:31 | INFO | MainProcess | MainThread | [remote_util.log_command_output] ------------------------------------------------
2014-02-11 03:57:31 | INFO | MainProcess | MainThread | [remote_util.log_command_output] MALLOC: 645831408 ( 615.9 MiB) Bytes in use by application
2014-02-11 03:57:31 | INFO | MainProcess | MainThread | [remote_util.log_command_output] MALLOC: + 120201216 ( 114.6 MiB) Bytes in page heap freelist
2014-02-11 03:57:31 | INFO | MainProcess | MainThread | [remote_util.log_command_output] MALLOC: + 10568336 ( 10.1 MiB) Bytes in central cache freelist
2014-02-11 03:57:31 | INFO | MainProcess | MainThread | [remote_util.log_command_output] MALLOC: + 0 ( 0.0 MiB) Bytes in transfer cache freelist
2014-02-11 03:57:31 | INFO | MainProcess | MainThread | [remote_util.log_command_output] MALLOC: + 2810496 ( 2.7 MiB) Bytes in thread cache freelists
2014-02-11 03:57:31 | INFO | MainProcess | MainThread | [remote_util.log_command_output] MALLOC: + 1831064 ( 1.7 MiB) Bytes in malloc metadata
2014-02-11 03:57:31 | INFO | MainProcess | MainThread | [remote_util.log_command_output] MALLOC: ------------
2014-02-11 03:57:31 | INFO | MainProcess | MainThread | [remote_util.log_command_output] MALLOC: = 781242520 ( 745.1 MiB) Actual memory used (physical + swap)
2014-02-11 03:57:31 | INFO | MainProcess | MainThread | [remote_util.log_command_output] MALLOC: + 26411008 ( 25.2 MiB) Bytes released to OS (aka unmapped)
2014-02-11 03:57:31 | INFO | MainProcess | MainThread | [remote_util.log_command_output] MALLOC: ------------
2014-02-11 03:57:31 | INFO | MainProcess | MainThread | [remote_util.log_command_output] MALLOC: = 807653528 ( 770.2 MiB) Virtual address space used
2014-02-11 03:57:31 | INFO | MainProcess | MainThread | [remote_util.log_command_output] MALLOC:
2014-02-11 03:57:31 | INFO | MainProcess | MainThread | [remote_util.log_command_output] MALLOC: 6848 Spans in use
2014-02-11 03:57:31 | INFO | MainProcess | MainThread | [remote_util.log_command_output] MALLOC: 18 Thread heaps in use
2014-02-11 03:57:31 | INFO | MainProcess | MainThread | [remote_util.log_command_output] MALLOC: 8192 Tcmalloc page size
2014-02-11 03:57:31 | INFO | MainProcess | MainThread | [remote_util.log_command_output] ------------------------------------------------
2014-02-11 03:57:31 | INFO | MainProcess | MainThread | [remote_util.log_command_output] Call ReleaseFreeMemory() to release freelist memory to the OS (via madvise()).
2014-02-11 03:57:31 | INFO | MainProcess | MainThread | [remote_util.log_command_output] Bytes released to the OS take up virtual address space but no physical memory.
I.e. about 750 megs of ram is used
and on 2.2.0-840 (that later build I referred to above) eats 820 megs. And there's similar situation with 2.5.0 GA.
Only regression of 2.2.0-840 vs. 2.2.0-821 that's apparent here is lack of -DTCMALLOC_SMALL_BUT_SLOW in build (which is seen by lack of warning like this " NOTE: SMALL MEMORY MODEL IS IN USE, PERFORMANCE MAY SUFFER." in later builds).
Therefore we should restore that define that's known to be passed in earlier builds and which was somehow dropped in later builds. It's possible that it was intentional for some specific reason, but I'm not aware of that. Looks like simple regression instead.