Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Memory fragmentation rate is abnormal #7422

Open
heepy opened this issue Jun 22, 2020 · 3 comments
Open

Memory fragmentation rate is abnormal #7422

heepy opened this issue Jun 22, 2020 · 3 comments

Comments

@heepy
Copy link

heepy commented Jun 22, 2020


We have a problem that the memory fragmentation rate of redis instance is lower than 1, but the system resources are enough and there is no swap。


System:Red Hat Enterprise 7.4
Redis Server:Redis 3.2.9
model:Redis Cluster

info memory
#Memory
used_memeory_human:11.57M
used_memeory_rss_human:7.56M
used_memeory_peak_human:24.39M
used_memeory_lua_human:37.00k
maxmemory_human:1.00G
mem_fragmentation_ratio:0.66
mem_allocator:jemalloc-4.0.3

#free -g

  total used free shared buff/cache available
mem 251 2 246 1 3 246
swap 3 0 3      
@oranagra
Copy link
Member

this can easily happen when allocating a chunk of memory and not actually writing to it. in that case the OS doesn't actually maps any pages for that allocation.
most of the actual allocations in redis (data types) don't do that, but in this case i see redis is nearly empty, so that might be some startup memory allocations.

bottom line, not a lot of memory, not a problem, and not unexpected.
i.e. if you would have shown me that RSS 2GB smaller than used_memory that would make me curious. (although still not really a problem)

btw, what version of redis is it?
if you really want to look into fragmentation, i'd advise to look at:

allocator_frag_ratio
allocator_frag_bytes
allocator_rss_ratio
allocator_rss_bytes
rss_overhead_ratio
rss_overhead_bytes

@heepy
Copy link
Author

heepy commented Jun 22, 2020

this can easily happen when allocating a chunk of memory and not actually writing to it. in that case the OS doesn't actually maps any pages for that allocation.
most of the actual allocations in redis (data types) don't do that, but in this case i see redis is nearly empty, so that might be some startup memory allocations.

bottom line, not a lot of memory, not a problem, and not unexpected.
i.e. if you would have shown me that RSS 2GB smaller than used_memory that would make me curious. (although still not really a problem)

btw, what version of redis is it?
if you really want to look into fragmentation, i'd advise to look at:

allocator_frag_ratio
allocator_frag_bytes
allocator_rss_ratio
allocator_rss_bytes
rss_overhead_ratio
rss_overhead_bytes

redis server version 3.2.9

@oranagra
Copy link
Member

so you don't have these fields in that version.
if you feel adventurous, you can get that info manually by running DEBUG jemalloc info

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants