KEYS 대신 SCAN, 큰 키 쪼개기, 지우기는 UNLINK(백그라운드 삭제), 같은 초에 몰리는 만료 시각 분산.
인프라팀 할 일
느린 명령 기록(SLOWLOG) 감시, KEYS 같은 위험 명령은 운영 서버에서 막기, 큰 키 정기 점검, THP 끄고 fork할 메모리 여유 확보, RDB·AOF 저장은 복제본에서.
수치 감각
보통 명령은 1ms 미만. 원소 수백만 개를 한 번에 다루면 수백 ms에서 수 초까지 걸리기도 합니다.
그래프에서는
가끔 무작위로 튐 · Redis 응답 지연, 느린 명령 수
확인할 곳
SLOWLOG GET으로 slowlog-log-slower-than을 넘긴 명령을 보고, CONFIG SET latency-monitor-threshold로 지연 모니터(기본 꺼짐)를 켠 뒤 LATENCY LATEST·LATENCY DOCTOR로 fork·expire-cycle 같은 이벤트별 지연을 봄. INFO의 latest_fork_usec와 redis-cli --bigkeys로 fork 시간과 큰 키도 확인함
이러면 맞음
멈춘 시각에 SLOWLOG에 KEYS나 큰 키를 통째로 다루는 명령이 남아 있거나, LATENCY에 같은 시각 fork·expire-cycle 이벤트가 수십 ms 이상으로 기록됨
이러면 아님
SLOWLOG·LATENCY가 비어 있는데 게임 서버 쪽에서만 느리면 네트워크나 게임 서버 안의 대기(SLOWLOG는 명령 실행 시간만 재고 클라이언트와 주고받는 시간은 넣지 않음)
확인 수단
인프라 도구로 확인(게임 코드 불필요)
더 알아보기
저장 파일(RDB 스냅샷)을 만들거나 AOF를 다시 쓰려고 프로세스를 복제(fork)하는 순간에도 멈춥니다. 요즘 서버에서 메모리 1GB당 약 10ms라, 30GB면 300ms쯤입니다. 큰 페이지(THP)를 켜 두면 fork 뒤 쓰기마다 큰 페이지를 통째로 복사해(copy-on-write) 멈춤과 메모리 사용이 크게 늘어서, 보통 THP를 끄고 메모리 여유를 넉넉히 둡니다. 같은 초에 만료되는 키가 아주 많을 때도 Redis가 지우느라 잠깐 멈춥니다.
출처
Diagnosing latency issuesRedis 요청을 한 스레드가 차례로 처리해 느린 명령이 뒤를 모두 막음, KEYS 대신 SCAN, fork는 물리 서버·최신 VM 실측 1GB당 약 9~13ms, THP는 fork 뒤 복사로 지연·메모리 급증, 같은 초에 대량 만료되면 멈춤
KEYSRedis 운영 환경에서는 극히 조심해서 쓸 것, 큰 DB에서 성능을 망가뜨릴 수 있음(보급형 노트북에서 키 100만 개에 40ms)
UNLINKRedis 키를 즉시 떼어 내고 메모리 회수는 다른 스레드에서 하는 비동기 삭제
SLOWLOGRedis slowlog-log-slower-than을 넘긴 명령을 기록하는 느린 명령 로그, 실행 시간에는 클라이언트와 주고받는 I/O가 빠짐
Redis latency monitoringRedis latency-monitor-threshold 기본 0(꺼짐), LATENCY LATEST·LATENCY DOCTOR, fork·expire-cycle 같은 이벤트별 지연 기록
INFORedis latest_fork_usec: 마지막 fork에 걸린 시간(마이크로초)