강연자 - 강대명 전 NHN
charsyam@naver.com
사용한 Redis Version
구축 환경
사용한 언어.
======================================================
Redis Tips
주의할 명령어
- keys * patterns
- 짦은 시간안에 빠르게 처리해야 하는게 목적이기 때문에, 길게 처리하는 명령어는
쓰지 않는 것이 좋으므로 주의 할 것
전체 키를 다 들고 오지 말고 필요한 키만 들고 올것
- FlushAll
데이터가 많아 질수록 느려질 수밖에 없다. 왜 그 순간에 다 지우기 때문이다.
레디스 메모리 정책
- lru가 돌게되면 성능이 20~30% 정도 떨어진다.
- 최대한 메모리를 적게 사용하고 싶으시다면 , 32Bit 에서 사용하시는걸 추천
- vm.overcommt_memory property : 64Bit 에서 활용.
스왑 영역 이후의 메모리까지 쓰려 할 경우 점검
- 마스터와 슬레이브의 메모리 정책이 다를 경우 , 마스터 모르게 슬레이브가
Data 를 지울 수 있다.
Replication
- 마스터 및에 슬레이브 슬레이브 슬레이브 붙일 수 있음.
- 마스터와 슬레이브 간에 연결을 끊고 , 마스터를 Reset 할 경우
슬레이브는 replication 을 할때 자신의 Data를 Reset 하고 마스터의 Data를
받으려고 하기 때문에 , Data가 전부 지워지는 경우가 발생한다.
- 따라서 , Master를 교체하거나 Reset하는 경우 Slave 에 Slave no one 명령어를
넣어줄 것
AOF 기능(이건 나중에) 및 디스크 저장 기능 (RDB)
- RDB - 안좋은 점
> Redis 자체가 디스크 덤프를 계속 할 경우 처리속도 무지하게 지연.
> fork를 만약에 하게 될 경우는 메모리를 2개 먹을 수 있음
> RDB가 Fail 났을 경우 Redis 는 정책상 더이상 Write 를 받지 않는다.
> 캐시메모리로 쓰고 , 간단하게 쓸 경우 AOF / RDB는 당연히 비추
- RDB - 커다란 메모리의 경우
> 덤프를 떠야 하는 경우 Slave에서 덤프를 뜨는 방법
> RDB를 차라리 끄세요...캐시 솔루션으로만 쓰고자 한다면 ..
> 단..장비가 2대 있어야 대므로...돈을 더 쓰셈...
RDB - 메모리 2개 쓰는 경우
> 쓰기가 많아질 경우 메모리를 최대 2개까지 먹을 수 있다.. 뻥....
실 사례..
배경
- Redis가 정기적으로 죽는다.
원인
- RDB가 실패할 경우 Write를 더이상 안하므로 , 이건 정책적으로 가져 갈 것
해결 방안
- 1. 2.6.12 버전 전에는 config-set stop-writes-on-bgsave-error no
- 2. Turn off RDB setting
Select Command
- Select 명령어 쓰지 말 것
- Redis 클러스터는 Select 명령어는 받지 않으므로 . 정리하기에 불편하다.
- Redis Proxy 는 문제를 야기할 수 있다.
Reponse Time
memcache | Redis
memached 가 응답은 균일하다. Redis는 알고리즘을 쉽게 쓸 수 있다. 그러므로 개발은 편하다.
memcached는 메모리의 제한이 없고 썻던 것을 재활용 할 수있다.
Redis는 malloc()만 쓰므로 , 메모리 할당 영역이 계속 늘어난다.
memcache는 기능이 Redis에 비해 API가 적어서 잘 죽지도 않는다.
Redis도 RDB를 끄면 잘 죽지 않지만. memcache는 정말 안죽는다.
Sentinel
- 마스터와 슬레이브를 감시하고 있다가 Slave를 마스터로 승격시켜주는 역할
- 정기적으로 Master를 모니터링
- Slave가 여러대일 경우 , 장애가 안나고 가장 최근의 Data를 갖고있는 Slave 를 뽑는다.
- Client에게 바뀐 정보를 알려준다.
Sharding or clustering
댓글 없음:
댓글 쓰기