- 메모리
Redis는 in-Memory Data Store 이다.
Physical Memory 이상을 사용하면 문제가 당연히 발생한다.
Swap이 있다면 Swap 사용으로 해당 메모리 Page접근시 마다 늦어진다.
(disk에 접근하기 시작하면 의미가없어짐)
//Swap이 없다면?
Maxmemory를 설정하더라도 이보다 더 사용할 가능성이 큼. 메모리 얼로케이터에 따라 성능 와따리가따리
제이말록 // 메모리파편화 등
메모리를 사용해서 Swap을 쓰고 있다는걸 모르는 경우 많음. 알고있는게 좋음.
큰메모리를 사용하는 인스턴스 하나보다는
적은 메모리를 사용하는 인스턴스 여러개가 안전함.
쓰기가 많은 레디스는 메로리를 두배까지 쓰게됨.
write 때 포크가 뭔가??
4.x 대 부터 메모리 파편화를 줄이도록 jemlloc에 힌트를 주는 기능이 들어감.
버전에 따라 다르게 동작함.
3.x대 버전의 경우 실제 used memory는 2gb보고가 되지만 11gb의 rss를 사용하는 경우가 자주 발생
다양한 사이즈를 가지는 데이터 보다는 유사한 크기의 데이터를 가지는 경우가 유리.
메모리가 부족할 떄는?
Cache is Cash!!!
좀 더 메모리 많은 장비로 마이그레이션
메모리가 너무 빡빡해도 마이그레이션 중에 문제 가능성 65~70 이상이면 고민해야함.
or
있는 데이터 줄이기.
메모리를 줄이기 위한 설정
hash => hashtable을 하나 더 사용
sortedset=>skiplist와 hashtable을 이용.
set=>hashtable 사용
해당 자료구조들은 메모리를 많이 사용함
ziplist
인메모리 특성상 적은 개수라면 선형 탐색을 하더라도 빠름
2.O(N)관련 명령어는 주의하자
redis는 single threaded.
레디스는 동시에 명령을 처리할수없다. 한번에 1개씩.
단순한 get/set의 경우 초당 10만 TPS 이상 가능.
그런데 1초가걸리는 명령어에 걸리면 그 뒤의 수만개의 모든 명령어가 다 걸려버림.
프로세스 인풋 버퍼 패킷 등 알아봐라.
대표적인 O(N) 명령들
KEYS, FLUSHALL, FLUSHDB
Delete Collections
Get All Collections
키가 백만개 이상인데 확인을 위해 키스 명령을 사용
처리되는 시간동안 암것도못함.
대체로는 scan을 사용할수있음.
Collection의 모든 item을 가져와야 할때?
Collection 의 일부만 가져오거나
큰 컬렉션을 작은 여러개의 컬렉션으로 나눠 저장
Redis Replication
A라는 서버에 B서버에 들고있을수있음.
어싱크 리플리케이션임
리플리케이션 lag이 발생할수있음.
전체 장애의 90% 이상이 keys와 save설정을 사용해서발생함.
Maxclient 설정 50000이상
RDB/AOF 끄는걸 추천
데이터분산방법
어플리케이션
컨시스턴트 해싱
해싱값으로 서버증설이나 축소시에 데이터들의 리벨런싱 비율을 낮춤으로써 효율성을 증가시킴
샤딩
Range설정이 가장 보편적이고 쉬움
1~1000
1001~2000
2001~3000
서버의 상황에따라 노는서버와 안노는서버가 극심하게 나뉨
데이터를 분배해서 재할당 불가능함.
확장은 편한데 서버별로 상황이 극명하다는 단점이 레인지샤딩의 단점.
Redis Cluster
twemproxy
-- 내용을 채우는 중입니다. --
