Redis MEMORY

<< MONITOR Persistence Introduction >>

Redis MEMORY

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

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

서브커맨드 리스트

MEMORY HELP

원래 help에서 doctor를 추가했고 순서를 약간 바꾸었습니다.

MEMORY USAGE KEY [samples 5]

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

Strings

Lists

1000개의 값을 넣고 메모리 사용량을 알아보았습니다.   값이 평균 13바이트이고 1000개이므로 13kb이다. 50바이트로 계산해도 50kb인데, 7.4mb가 나왔다.
List는 메모리 사용량이 잘못 계산됩니다. -> 이 버그는 2018년 1월 24일 발표된 버전 4.0.7에서 개선되었습니다.

Sets

메모리 사용량이 잘 됨.

SortedSets

메모리 사용량이 잘 됨.

Hashes

메모리 사용량이 잘 됨.

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

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로 나오는 항목과 비교 또는 간단한 설명입니다.
명령 결과를 보기 좋게 약간 편집했습니다.
overhead.total는 이렇게 계산합니다.
    = startup.allocated(server.initial_memory_usage) +
       replication.backlog +
       clients.slaves +
       clients.normal +
       aof_buffer +
       db.size

다음은 리눅스 status로 볼 수 있는 메모리 정보입니다. 마지막 항목에서 레디스 서버 4.0의 경우 쓰레드가 총 4개임을 확인할 수 있습니다. 메인 쓰레드 1개, 1초 마다 AOF를 쓰는 쓰레드 2개, 4.0 이전까지는 3개 였고, 4.0에서 unlink(del)용 쓰레드 1개가 새로 생겼다.

아래는 리눅스 statm으로 확인하는 메모리 정보입니다. 단위는 page(4096바이트)입니다.

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과 유사한 것으로 메모리 페이지 정보를 보여줍니다.

MEMORY PURGE

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

명령문

MEMORY

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



<< MONITOR MEMORY Persistence Introduction >>

질문하거나 댓글을 보려면 클릭하세요.  댓글수 :    조회수 :

Email 답글이 올라오면 이메일로 알려드리겠습니다.