Defragger improvements around large bins

[sundb]

Implement #12963

Changes

1. large bins don't have external fragmentation or are at least non-defraggable, so we should ignore the effect of
   large bins when measuring fragmentation, and only measure fragmentation of small bins. this affects both the allocator_frag* metrics and also the active-defrag trigger
2. Adding INFO metrics for allocator_muzzy memory, which is memory returned to the OS but still shows as RSS until the OS reclaims it.
3. Adding a similar allocator.muzzy to MEMORY STATS

[sundb]

@oranagra The implementation is now already going in the new direction(#12963 (comment)), and the different formula results in a lower fragmentation percent now than before, so the defrag test fails.

EDIT: fotget *100 to calculate percentage.

[oranagra]

p.s. i edited the top comment a bit since it seemed outdated.
PTAL

[oranagra]

@redis/core-team please approve

[madolson]

Adding INFO metrics for muzzy memory, which is memory returned to the OS but still shows as RSS until the OS reclaims it.

What is the point of showing muzzy to end users? Maybe after merging this we can improve the documentation around memory. It's something that people ask me about at AWS, since it's confusing.

[sundb]

@madolson AFAIK, muzzy is very similar to retained, but muzzy is no longer reused but retained is.

[oranagra]

AFAIK, muzzy is very similar to retained, but muzzy is no longer reused but retained is.

from my understanding that's wrong.

• retained isn't part of RSS, only part of VMSIZE (which no one should care about).
• muzzy is temporarily part of RSS (looks alarming), but the OS can reclaim that on it's own when it needs to (so we're not really holding that memory).

we should surely improve documentation.
the question here is if we wanna keep the jemalloc terminology, or try to create one of our own that we think could be clearer.
i have a feeling that creating new terminology can increase confusion.

[oranagra]

approved in a core-team meeting.
@sundb can you create a redis-doc PR?

[sundb]

Redis-doc PR: redis/redis-doc#2672