redis server commands memory

Redis MEMORY

Redis Server 教育 Redis Server Course	Redis 定期点検/技術支援 Redis Technical Support	Redis エンタープライズサーバ Redis Enterprise Server

Redis MEMORY

키가 사용중인 메모리량, 레디스 서버의 메모리 현황 정보를 볼 수 있습니다.

이 문서는 버전 4.0.0을 기준으로 만들었습니다.

서브커맨드 리스트

• help: 도움말을 보여준다.
• usage: 키의 메모리 사용량 정보를 보여준다.
• stats: 레디스 서버 메모리 사용량 정보를 보여준다.
• doctor: 메모리 사용 정보를 체크해서 권고사항을 문자으로 보여준다.
• malloc-stats: 메모리 정보를 자세하게 보여준다.
• purge: 사용하지 않는 메모리를 해제한다.

MEMORY HELP

원래 help에서 doctor를 추가했고 순서를 약간 바꾸었습니다. 127.0.0.1:6000> memory help 1) "MEMORY USAGE <key> [SAMPLES <count>] - Estimate memory usage of key" 2) "MEMORY STATS - Show memory usage details" 3) "MEMORY DOCTOR" 4) "MEMORY MALLOC-STATS - Show allocator internal stats" - jemalloc only 5) "MEMORY PURGE - Ask the allocator to release memory" - jemalloc only

MEMORY USAGE KEY [samples 5]

각 키와 값이 메모리를 얼마나 사용하고 있는지 알 수 있는 명령입니다.   여기서 제공하는 메모리 사용량은 순수 키와 값의 메모리 사용량에 관리에 필요한 추가 메모리 사용량을 더해서 보여줍니다.
옵션인 samples은 키 하나가 여러개의 멤버를 가질 수 있는 Lists, Sets, SortedSets, Hashes에서 사용합니다. 샘플링할 멤버의 수를 지정하는 것이고, 기본은 5입니다. 예를 들어 Set 키에 값이 10개일 때 기본 5로 하면 5개 멤버의 메모리 사용량을 구해서 평균을 계산한 후 10을 곱해서 구합니다.   모든 멤버의 사용량을 구하려면 samples 0을 입력합니다. 그러므로 Strings에는 필요없습니다.
아래는 각 데이터 타입별로 메모리 사용량을 구한 예입니다.

Strings

127.0.0.1:6000> set key value OK 127.0.0.1:6000> memory usage key (integer) 56 127.0.0.1:6000> set key1 AAAAAAAAAABBBBBBBBBB OK 127.0.0.1:6000> memory usage key1 (integer) 71

Lists

1000개의 값을 넣고 메모리 사용량을 알아보았습니다.   값이 평균 13바이트이고 1000개이므로 13kb이다. 50바이트로 계산해도 50kb인데, 7.4mb가 나왔다.
List는 메모리 사용량이 잘못 계산됩니다. -> 이 버그는 2018년 1월 24일 발표된 버전 4.0.7에서 개선되었습니다. $ for i in {0..999}; do src/redis-cli -p 6000 lpush mylist AAAAAAAAAA$i; done 127.0.0.1:6000> memory usage mylist samples 0 (integer) 7488081 <- 잘못 나오는 경우. 버전 4.0.6까지 (integer) 15066 <- 올바로 나오는 경우. 버전 4.0.7부터

Sets

메모리 사용량이 잘 됨. $ for i in {0..999}; do src/redis-cli -p 6000 sadd myset AAAAAAAAAA$i; done 127.0.0.1:6000> memory usage myset samples 0 (integer) 47227

SortedSets

메모리 사용량이 잘 됨. $ for i in {0..999}; do src/redis-cli -p 6000 zadd myzset $i AAAAAAAAAA$i; done 127.0.0.1:6000> memory usage myzset samples 0 (integer) 92891

Hashes

메모리 사용량이 잘 됨. for i in {0..999}; do src/redis-cli -p 6000 hset myhash field$i AAAAAAAAAA$i; done 127.0.0.1:6000> memory usage myhash samples 0 (integer) 57117

메모리 사용량이 일정하게 증가하지 않는 이유

Collection 데이터 타입의 경우 데이터를 하나씩 넣으면서 메모리 사용량을 확인해보면 일정하게(선형) 증가하지 않는 경우를 볼 수 있습니다. 그것은 같은 데이터 타입이라도 내부적으로 멤버의 수 또는 멤버의 길이에 따라 내부구조가 다르기 때문입니다. 예를 들어 Hash에서 필드수가 512개 까지는 ziplist에 저장되므로 메모리를 적게 사용하다가 513개 부터 내부구조가 Hash table로 변경되면서 메모리를 많이 사용하게 됩니다. 아래에 관련 파라미터가 있으니 참고하세요.

• list-max-ziplist-size -2 : 8k
• list-compress-depth 0 : no compression
• set-max-intset-entries 512
• zset-max-ziplist-entries 128
• zset-max-ziplist-value 64
• hash-max-ziplist-entries 512
• hash-max-ziplist-value 64

MEMORY STATS

레디스 서버의 메모리 현황을 볼 수 있는 명령으로 메모리 오버헤드, 순수 데이터 사이즈, 각 키별 평균 데이터 사이즈 등이 제공됩니다.
화살표 다음에는 info memory로 나오는 항목과 비교 또는 간단한 설명입니다.
명령 결과를 보기 좋게 약간 편집했습니다. 127.0.0.1:6000> memory stats peak.allocated: 38700320 -> used_memory_peak(server.stat_peak_memory) total.allocated: 38659432 -> used_memory(현재 사용중인 메모리) startup.allocated: 765616 -> used_memory_startup(server.initial_memory_usage) replication.backlog: 10485760 -> repl-backlog-size clients.slaves: 33716 -> clone clients memory size clients.normal: 66488 -> normal clients memory size aof.buffer: 0 -> aof memory size db.0 overhead.hashtable.main: 1062344 -> dict hash table size and dict slots size overhead.hashtable.expires: 0 -> dict hash table size and dict slots size overhead.total: 12413924 -> used_memory_overhead keys.count: 20005 -> total keys count keys.bytes-per-key: 1894 -> net_usage(total.allocated - startup.allocated)/keys.count dataset.bytes: 26245508 -> total.allocated - overhead.total dataset.percentage: 69.26 -> dataset.bytes / net_usage peak.percentage: 99.89 -> total.allocated / peak.allocated fragmentation: 0.71 -> mem_fragmentation_ratio
overhead.total는 이렇게 계산합니다.
    = startup.allocated(server.initial_memory_usage) +
       replication.backlog +
       clients.slaves +
       clients.normal +
       aof_buffer +
       db.size

다음은 리눅스 status로 볼 수 있는 메모리 정보입니다. # cat /proc/<pid>/status VmPeak: 190300 kB -> Peak virtual memory size VmSize: 190296 kB -> virtual memory size VmHWM: 26960 kB -> Peak RSS(High Water Mark) VmRSS: 26960 kB -> Resident Set Size(used_memory_rss) VmData: 74036 kB -> Size of data(global and static variables) VmStk: 136 kB -> Size of stack VmExe: 1268 kB -> Size of text(executable code) VmLib: 3012 kB -> Shared library code size VmPTE: 136 kB -> Page table entries size (since Linux 2.6.10) VmSwap: 0 kB -> Swapped-out virtual memory size (since Linux 2.6.34) Threads: 4 -> Number of threads in process 마지막 항목에서 레디스 서버 4.0의 경우 쓰레드가 총 4개임을 확인할 수 있습니다. 메인 쓰레드 1개, 1초 마다 AOF를 쓰는 쓰레드 2개, 4.0 이전까지는 3개 였고, 4.0에서 unlink(del)용 쓰레드 1개가 새로 생겼다.

아래는 리눅스 statm으로 확인하는 메모리 정보입니다. 단위는 page(4096바이트)입니다. # cat /proc/<pid>/statm 47574 6740 333 317 0 18543 0 1) The total program size -> VmSize 2) The size of the process resident in physical memory -> VmRSS: 6740 * 4096 / 1024 = 26960kB 3) The memory shared with other processes—that is, memory mapped both by this process and at least one other(such as shared libraries or untouched copy-on-write pages) 4) text(executable code) -> VmExe 5) The size of shared libraries mapped into this process: unused since Linux 2.6 6) The memory used by this process for its stack -> VmData + VmStk 7) The number of dirty pages: unused since Linux 2.6

MEMORY DOCTOR

경우에 따라 다음과 같은 권고사항이 나옵니다.

• 사용 메모리가 5MB 미만이면:
  Hi Sam, this instance is empty or is using very little memory, my issues detector can't be used in these conditions. Please, leave for your mission on Earth and fill it with some data. The new Sam and I will be back to our programming as soon as I finished rebooting.
  사용 메모리가 5MB 미만이면 권고사항이 없습니다.
• Peak is > 150% of current used memory? : mh->peak_allocated / mh->total_allocated) > 1.5
  * Peak memory: In the past this instance used more than 150% the memory that is currently using. The allocator is normally not able to release memory after a peak, so you can expect to see a big fragmentation ratio, however this is actually harmless and is only due to the memory peak, and if the Redis instance Resident Set Size (RSS) is currently bigger than expected, the memory will be used as soon as you fill the Redis instance with more data. If the memory peak was only occasional and you want to try to reclaim memory, please try the MEMORY PURGE command, otherwise the only other option is to shutdown and restart the instance.
• Fragmentation is higher than 1.4? : mh->fragmentation > 1.4
  * High fragmentation: This instance has a memory fragmentation greater than 1.4 (this means that the Resident Set Size of the Redis process is much larger than the sum of the logical allocations Redis performed). This problem is usually due either to a large peak memory (check if there is a peak memory entry above in the report) or may result from a workload that causes the allocator to fragment memory a lot. If the problem is a large peak memory, then there is no issue. Otherwise, make sure you are using the Jemalloc allocator and not the default libc malloc. Note: The currently used allocator is malloc size.
• Slaves using more than 10 MB each? : mh->clients_slaves / numslaves > (1024*1024*10)
  * Big slave buffers: The slave output buffers in this instance are greater than 10MB for each slave (on average). This likely means that there is some slave instance that is struggling receiving data, either because it is too slow or because of networking issues. As a result, data piles on the master output buffers. Please try to identify what slave is not receiving data correctly and why. You can use the INFO output in order to check the slaves delays and the CLIENT LIST command to check the output buffers of each slave.
• Clients using more than 200k each average? : (mh->clients_normal / numclients(normal.clients - slave.clients) > (1024*200)
  * Big client buffers: The clients output buffers in this instance are greater than 200K per client (on average). This may result from different causes, like Pub/Sub clients subscribed to channels bot not receiving data fast enough, so that data piles on the Redis instance output buffer, or clients sending commands with large replies or very large sequences of commands in the same pipeline. Please use the CLIENT LIST command in order to investigate the issue if it causes problems in your instance, or to understand better why certain clients are using a big amount of memory.

MEMORY MALLOC-STATS

이 명령은 3.2 버전의 DEBUG jemalloc info과 유사한 것으로 메모리 페이지 정보를 보여줍니다. 127.0.0.1:6000> memory malloc-stats ___ Begin jemalloc statistics ___ Version: 4.0.3-0-ge9192eacf8935e29fc62fddc2701f7942b1cc02c Assertions disabled Run-time option settings: opt.abort: false opt.lg_chunk: 21 opt.dss: "secondary" opt.narenas: 32 opt.lg_dirty_mult: 3 (arenas.lg_dirty_mult: 3) opt.stats_print: false opt.junk: "false" opt.quarantine: 0 opt.redzone: false opt.zero: false opt.tcache: true opt.lg_tcache_max: 15 CPUs: 8 Arenas: 32 Pointer size: 8 Quantum size: 8 Page size: 4096 Min active:dirty page ratio per arena: 8:1 Maximum thread-cached size class: 32768 Chunk size: 2097152 (2^21) Allocated: 1447808, active: 1789952, metadata: 1537536, resident: 4251648, mapped: 6291456 Current active ceiling: 2097152 arenas[0]: assigned threads: 1 dss allocation precedence: secondary min active:dirty page ratio: 8:1 dirty pages: 437:310 active:dirty, 2 sweeps, 2 madvises, 251 purged allocated nmalloc ndalloc nrequests small: 661376 105316 85612 866140 large: 786432 35093 35084 69797 huge: 0 0 0 0 total: 1447808 140409 120696 935937 active: 1789952 mapped: 4194304 metadata: mapped: 106496, allocated: 346240 bins: size ind allocated nmalloc ndalloc nrequests curregs curruns regs pgs util nfills nflushes newruns reruns 8 0 1976 645 398 118526 247 1 512 1 0.482 24 22 2 1 16 1 229168 54490 40167 89834 14323 56 256 1 0.999 827 416 204 14 24 2 88224 34613 30937 164360 3676 8 512 3 0.897 643 320 61 78 32 3 224 403 396 104269 7 1 128 1 0.054 79 80 1 0 40 4 30760 8463 7694 42256 769 2 512 5 0.750 500 97 15 5 48 5 1344 173 145 215154 28 1 256 3 0.109 53 54 1 0 56 6 11760 2884 2674 35408 210 1 512 7 0.410 102 55 5 3 64 7 1088 138 121 1003 17 1 64 1 0.265 48 18 1 0 80 8 6320 1277 1198 1297 79 1 256 5 0.308 77 52 4 3 96 9 14208 608 460 71049 148 2 128 3 0.578 118 45 3 5 112 10 5936 344 291 2373 53 1 256 7 0.207 143 33 3 0 128 11 3712 182 153 20210 29 1 32 1 0.906 116 26 6 0 160 12 2080 170 157 100 13 1 128 5 0.101 43 21 8 0 192 13 384 76 74 9 2 1 64 3 0.031 6 9 6 0 224 14 0 115 115 8 0 0 128 7 1 6 10 6 0 256 15 256 27 26 17 1 1 16 1 0.062 9 12 2 0 320 16 5120 114 98 25 16 1 64 5 0.250 7 11 1 0 384 17 384 40 39 7 1 1 32 3 0.031 5 8 1 0 448 18 896 76 74 8 2 1 64 7 0.031 6 9 6 0 512 19 512 20 19 16 1 1 8 1 0.125 10 12 2 1 640 20 640 42 41 13 1 1 32 5 0.031 6 11 2 0 768 21 0 23 23 6 0 0 16 3 1 5 8 5 0 896 22 31360 75 40 42 35 2 32 7 0.546 7 10 2 0 1024 23 2048 19 17 16 2 1 4 1 0.500 10 12 3 1 1280 24 1280 31 30 20 1 1 16 5 0.062 9 11 4 0 1536 25 0 18 18 5 0 0 8 3 1 5 6 6 0 1792 26 3584 26 24 7 2 1 16 7 0.125 6 7 6 0 2048 27 4096 21 19 13 2 1 2 1 1 10 12 14 0 2560 28 0 24 24 9 0 0 8 5 1 8 9 9 0 3072 29 0 14 14 3 0 0 4 3 1 3 4 5 0 3584 30 0 14 14 3 0 0 8 7 1 3 4 4 0 4096 31 4096 18 17 12 1 1 1 1 1 9 10 18 0 5120 32 168960 51 18 39 33 9 4 5 0.916 5 6 12 1 6144 33 0 13 13 3 0 0 2 3 1 3 5 7 1 7168 34 0 12 12 2 0 0 4 7 1 2 3 4 0 8192 35 40960 19 14 10 5 5 1 2 1 7 7 19 0 10240 36 0 14 14 4 0 0 2 5 1 3 4 7 0 12288 37 0 12 12 2 0 0 1 3 1 2 3 12 0 14336 38 0 12 12 2 0 0 2 7 1 2 3 6 0 large: size ind allocated nmalloc ndalloc nrequests curruns 16384 39 16384 6 5 7 1 20480 40 40960 7 5 34710 2 --- 32768 43 32768 4 3 4 1 40960 44 40960 35065 35064 35065 1 --- 65536 47 0 3 3 3 0 81920 48 81920 2 1 2 1 --- 114688 50 114688 1 0 1 1 131072 51 131072 4 3 4 1 --- 327680 56 327680 1 0 1 1 --- huge: size ind allocated nmalloc ndalloc nrequests curhchunks --- --- End jemalloc statistics ---

MEMORY PURGE

위 doctor에서 peak.allocated와 total.allocated가 150% 이상 차이날 경우 purge 옵션을 사용해서 메모리를 해제해 볼 수 있다는 권고가 있습니다.   보통의 경우 아무 효과가 없습니다. 127.0.0.1:6000> memory purge OK

명령문

MEMORY

• 이 명령은 version 4.0.0 부터 사용할 수 있다.
• source: object.c

조회수 :