우리는 redis를 실행하고 정렬 된 집합에서 초당 수백 개의 증분을 수행하고 매초마다 정렬 된 집합에서 수천 회의 읽기를 수행합니다.정렬 된 집합에 Redis CPU 성능
이것은 잘 작동하는 것처럼 보이지만 최대 부하시 CPU 사용량은 단일 코어의 80 %에 이릅니다. 정렬 된 세트 자체는 수천 개의 키가 들어있는 작은 메모리 공간입니다.
은 초당 수백 개의 증가 또는 수천 번의 읽기로 인해 CPU 사용량이 증가 할 가능성이 있습니까? 두 가지 충격 성능을 모두 이해하지만 큰 영향을 미칩니 까?
이러한 병목 현상을 검토하기 위해 프로덕션 인스턴스에서 모니터링 할 수있는 최상의 측정 항목은 무엇입니까?
확인해야 할 점은 정렬 된 집합이 Redis에 의해 직렬화 될 수있을만큼 작은 지 여부입니다. 예를 들어 "디버그 객체"는 ziplist로 인코딩되었는지 여부를 확인하기 위해 정렬 된 샘플의 샘플에 적용될 수 있습니다.
ziplist 사용량은 CPU와 비교하여 특히 소트 된 세트의 크기가 임계 값에 근접한 경우 (구성 파일의 zset-max-ziplist-entries, zset-max-ziplist-value).
정렬 된 세트가 ziplist로 인코딩되지 않는다고 가정하면 CPU 사용량이 초당 수백 번의 업데이트가 아니라 초당 수천 번의 읽기 때문일 가능성이 높습니다. zset의 업데이트는 log (n) 연산입니다. 그것은 매우 빠르며 Redis와 관련된 잠복 관련 대기 시간이 없습니다. zset 항목을 읽는 것은 O (n) 작업이므로 클라이언트를 빌드하여 클라이언트로 반환하기 위해 커다란 버퍼가 필요할 수 있습니다.
읽기 전용 트래픽을 생성하고 CPU를 확인한 다음 중지하고 업데이트 트래픽을 생성하고 CPU를 다시 확인하여 비교할 수 있습니다.
zset 읽기 작업 성능은 Redis benchmark에서 찾을 수있는 LRANGE 성능에 가깝습니다. 수천 개의 항목이있는 수천 개의 TPS for zsets가 전형적인 Redis 성능과 일치하는 것으로 보입니다.