[입 개발] Redis Swap, Redis는 메모리를 두배로 먹어요.

해당 블로그는 KT UCloud의 지원을 받고 있습니다.

Redis 는 현재 가장 인기있는 오픈 소스 캐시 솔루션 중의 하나입니다. 수 많은 기업에서 Redis를 사용하고 있거나 사용할려고 합니다. 이렇게 Redis가 있는 이유가 무엇일까요? 무엇보다도 안정적이고 속도가 빨라서 그렇습니다. 그리고 이 빠른 속도를 보장해주는 가장 큰 부분은 Redis 메모리 기반 솔루션이라는 것입니다.

Redis는 Single Thread 기반의 어플리케이션입니다. 그런데, Single Thread 임에도 불구하고, 백그라운드 Snapshot을 만들 수 있는 기능을 제공합니다. 우와, 어떻게 이것이 가능할까요? 그러면서 데이터에 대한 변경도 가능합니다. 보통의 솔루션들이 Snapshot을 뜨는 시점에는 변경 사항을 만들지 않기 위해서 안전하게 freeze 시켜두는 것과 다르게 말입니다.

그렇다면 어떻게 이런 기능을 제공할까요? 예전에 한번 언급했듯이, “BGSAVE”를 통한 백그라운드 스냅샷 기능은 Redis 가 차일드 프로세스를 생성하고, 여기서 작업을 진행하게 됩니다.

 

그런데 여기서 문제가 발생할 수 있습니다. fork 가 되면 기본적으로 자식 프로세스는 부몬 프로세스의 메모리를 복사하게 됩니다. 산술적으로 Redis 가 2GB 의 메모리를 쓰고 있다면 자식 프로세스도 2GB를 사용하게 된다는 것이죠.  OS가 COW(Copy On Write) 라는 것을 지원해서 해당 페이지에 Write가 와야만 실제로 메모리를 할당하므로 그 때는 큰 문제가 없겠지만, Redis에 write가 많을 경우 최대 2배가 되는 문제가 발생할 수 있습니다.

 

 fork 하면 처음에 자식 프로세서는 부모 메모리 페이지를 그대로 사용하게 됩니다.

write 가 생길 수록 복사되는 페이지가 늘어납니다. 만약 전체 페이지에 모두 write 가 생기면 최대 2배의 메모리를 사용하게 됩니다.

 그러므로 만약 해당 장비에서 RDB를 통한 스냅샷을 남길 때에는 Write 가 빈번한 서버의 경우에 주의해야 성능 저하를 줄일 수 있습니다. 그래서 실제 스냅샷은 슬레이브에서 남기는 것을 추천드립니다.