Redis SERVER Main Memory 사용량 계산

<< RDB Loading Copy-on-Write >>

Redis SERVER Memory 사용량 계산

레디스 서버(인스턴스)가 데이터를 저장할 때 사용하는 메모리(RAM)량을 계산하는 방법이다.   다른 모든 데이터베이스 관리 시스템과 마찬가지로 레디스도 관리 메모리(overhead)가 필요 하다.   실 데이터 크기를 기반으로 어느 정도 메모리가 더 필요한지 계산한다.   계산 방법은 각 데이터 타입별로 값 하나 입력할 때 오버헤드를 크기(바이트)를 제시했다.   계산 결과와 실 사용량을 비교해 보면 1.7%에서 8.4% 차이가 난다.   서버(머신) 사양(spec)을 정하는 용도로 충분히 사용할 수 있다고 본다.

키의 관리 메모리(overhead)는 50 바이트이다.   이는 키 하나에 할당되는 dictEntry, redisObject, sdshdr과 메모리 할당 단위 그리고 해시 테이블(buckets)이 사용하는 메모리를 고려해서 산출한 것이다.   아래 표(Case)에서는 키 길이를 10바이트로 했다.   다섯 가지 데이터 타입의 값의 관리 메모리는 아래 리스트에 있다.
여기서는 값의 개수가 적을 때 사용되는 Ziplist, Intset 같은 내부 데이터 타입은 고려하지 않았다.   왜냐하면 여기 계산한 사용량보다 적기 때문이다.
리스트는 레디스 3.2 기준으로 퀵 리스트로 테스트했고, 압축을 사용하지 않았다.   압축했을 때 비교는 맨 마지막에 있다.

해시 테이블을 사용하는 키, Sets, Hashes, ZSets은 키 또는 값의 개수에 따라 사용하는 메모리가 다르지만, 여기서는 계산을 간편하게 하기 위해 관리 메모리로 사용하는 바이트(overhead)를 일정한 값으로 정했다.

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

각 데이터 타입별 관리 메모리(overhead)

  • Key: 50 bytes
  • Strings: 30 bytes
  • Lists: 15 bytes
  • Sets: 75 bytes
  • ZSets: 120 bytes
  • Hashes: 100 bytes

계산 방법 예시

  • Strings 일 때 계산 방법
    • 키 크기 10바이트, 키 개수 10만 개, 값 크기(평균) 100바이트일 때
    • ((키 overhead 50 바이트 + 키 크기 10 바이트) * 키 개수 10만 개) +
      ((Strings 값 overhead 30 바이트 + 값 크기 100 바이트) * 값 개수 10만 개)
    • ((50 + 10) * 100000) + (30 + 100) * 100000) = 19,000,000 바이트
  • Lists 일 때 계산 방법
    • 키 크기 10바이트, 키 개수 100개, 키 당 값 개수(평균) 1,000개, 값 크기(평균) 100바이트일 때
    • ((키 overhead 50 바이트 + 키 크기 10 바이트) * 키 개수 100개) +
      ((Lists 값 overhead 15 바이트 + 값 크기 100 바이트) * 값 개수 10만 개(키 당 값 1000개)
    • ((50 + 10) * 100) + (15 + 100) * 100000) = 11,506,000 바이트
  • Sets 일 때 계산 방법
    • 키 크기 10바이트, 키 개수 100개, 키 당 값 개수(평균) 1,000개, 값 크기(평균) 100바이트일 때
    • ((키 overhead 50 바이트 + 키 크기 10 바이트) * 키 개수 100개) +
      ((Lists 값 overhead 75 바이트 + 값 크기 100 바이트) * 값 개수 10만 개(키 당 값 1000개)
    • ((50 + 10) * 100) + (75 + 100) * 100000) = 17,506,000 바이트
  • ZSets, Hashes도 Lists 나 Sets과 같은 계산 방법으로 하면된다.   단, Hashes 일 때는 값의 크기에 필드 크기도 같이 계산해서 넣으면 된다.   필드 크기 10 바이트, 값 크기 100 바이트이면 값 크기를 110 바이트로 계산한다.
  • 계산 결과는 표 Case 1과 비교해보면 사용 메모리(계산)과 일치함을 알 수 있다.

Case 1

키의 길이는 10바이트, 값의 길이는 100바이트이고, 컬렉션 타입 키 각 100개.

Data Type키 개수키 당 값 개수사용 메모리(계산)실 사용 메모리
Strings100,000119,000,00018,705,032
Lists1001,00011,506,00010,290,400
Sets1001,00017,506,00016,034,400
ZSets1001,00022,006,00020,681,624
Hashes1001,00021,006,00019,234,712
합계91,024,00084,946,168

실 사용 메모리 81mB, 계산한 것과 실 사용량이 7.2% 차이난다.


Case 2

키의 길이는 10바이트, 값의 길이는 100바이트이고, 컬렉션 타입 키 각 1,000개.

Data Type키 개수키 당 값 개수사용 메모리(계산)실 사용 메모리
Strings1,000,0001190,000,000177,241,648
Lists1,0001,000115,060,000102,904,000
Sets1,0001,000175,060,000160,344,000
ZSets1,0001,000220,060,000206,857,648
Hashes1,0001,000210,060,000192,344,000
합계910,240,000839,691,296

실 사용 메모리 800mB, 계산한 것과 실 사용량이 8.4% 차이난다.


Case 3

키의 길이는 10바이트, 값의 길이는 100바이트이고, 컬렉션 타입 키 당 값 5,000개.

Data Type키 개수키 당 값 개수사용 메모리(계산)실 사용 메모리
Strings5,000,0001950,000,000907,962,112
Lists1,0005,000575,060,000514,104,000
Sets1,0005,000875,060,000858,456,176
ZSets1,0005,0001,100,060,0001,088,324,984
Hashes1,0005,0001,050,060,0001,018,456,000
합계4,550,240,0004,387,303,272

실 사용 메모리 4.09gB, 계산한 것과 실 사용량이 3.7% 차이난다.


Case 4

키의 길이는 10바이트, 값의 길이는 100바이트이고, 컬렉션 타입 키 당 값 5,000개.

Data Type키 개수키 당 값 개수사용 메모리(계산)실 사용 메모리
Strings5,000,0001950,000,000907,962,080
Lists2,0005,0001,150,120,0001,028,208,312
Sets2,0005,0001,750,120,0001,716,912,000
ZSets2,0005,0002,200,120,0002,176,673,928
Hashes2,0005,0002,100,120,0002,036,914,184
합계8,150,480,0007,866,670,504

실 사용 메모리 7.33gB, 계산한 것과 실 사용량이 4.6% 차이난다.


Case 5

키의 길이는 10바이트, 값의 길이는 500바이트이고, 컬렉션 타입 키 당 값 1,000개.

Data Type키 개수키 당 값 개수사용 메모리(계산)실 사용 메모리
Strings100,000159,000,00058,747,840
Lists1001,00051,506,00051,410,400
Sets1001,00057,506,00056,034,400
ZSets1001,00062,006,00060,688,888
Hashes1001,00061,006,00059,234,400
합계 291,024,000286,115,928

실 사용 메모리 273mB, 계산한 것과 실 사용량이 1.7%차이난다.


Case 6

각 데이터 타입 당 1백만 개 값 입력

Data Type키 개수키 당 값 개수사용 메모리(계산)실 사용 메모리
Strings1,000,0001590,000,000577,286,704
Lists1,0001,000515,060,000514,105,272
Sets1,0001,000575,060,000560,342,728
ZSets1,0001,000620,060,000606,886,272
Hashes1,0001,000610,060,000592,345,272
합계

실 사용 메모리 2.66gB, 계산한 것과 실 사용량이 2.1%차이난다.


Lists: Quick List 압축을 사용할 때 메모리 사용량

레디스 서버 3.2.0 이상 버전에서는 퀵 리스트(Quick list)를 사용하며 압축을 할 수 있다.   압축 관련 파라미터 list-compress-depth는 2로 설정했다.   의미는 리스트에서 앞, 뒤 2개 노드씩 4개 노드는 압축을 하지 않고, 나머지 가운데 노드는 모두 압축하는 것이다.

값 길이
(바이트)
값 개수압축 전 사용 메모리압축 후 사용 메모리압축률
100100,00010,290,4004,049,77661%
1001,000,000102,904,00032,388,94469%
1005,000,000514,104,00046,789,04891%
10010,000,0001,028,208,312 92,635,60091%
500100,00051,410,4007,714,90485%
5001,000,000514,105,27269,404,57686%
5005,000,0002,570,104,000237,404,68091%

정리 整理 Summary

이 글에서는 키와 각 데이터 타입의 오버헤드를 고려한 메모리(RAM) 사용량을 계산해 보았습니다.
다음 페이지에서는 Copy-on-Write의 개념과 이로 인한 추가 메모리에 대해서 알아보겠습니다.

이 글을 보시고 질문이나 의문사항 있으면 댓글을 올려주세요.   더불어 잘못된 내용이 있으면 알려주시면 고맙겠습니다.




<< RDB Loading Server Main Memory Copy-on-Write >>

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

Email 返事がかかってなれば、メールでお知らせします。