info 명령을 사용하여 redis-cli을 사용할 때 정보를 출력 할 수 없을 정도로 Redis에서 응답 대기 시간이 매우 깁니다.Redis가 응답하는 데 너무 오래 걸림
이 서버는 약 200 개의 동시 프로세스로부터의 요청을 처리하지만 너무 많은 정보를 저장하지는 않습니다. 서버가 응답 할 때 info 명령은 약 20 - 30MB의 메모리 사용량을보고합니다.
응답 대기 시간이 긴 서버에서 top을 실행하면 CPU 사용률이 95 - 100 %가됩니다.
이러한 종류의 동작에는 몇 가지 원인이있을 수 있습니까?
제공된 데이터를 기반으로 설명을하기는 어렵지만 여기서는 제 추측입니다. 명백한 대기 시간 소스 (퍼시스턴스에 링크 된 것들)를 이미 확인하고, Redis 명령이 slow log에서 CPU를 호깅하지 않으며 파이썬 -rq에 의해 절인 된 작업 데이터의 크기가 크지 않다고 가정합니다.
문서에 따르면 Python-rq는 작업을 Redis에 해시 객체로 삽입하고 Redis가 관련된 키 (500 초가 기본값 인 것처럼 보임)를 만료시켜 작업을 제거하도록합니다. 심각한 처리량이있는 경우 Redis의 많은 항목이 만료되기를 기다리고 있습니다. 그들의 숫자는 보류중인 직업에 비해 높을 것입니다.
INFO 명령의 결과에서 만료 될 항목 수를보고이 지점을 확인할 수 있습니다.
유효 기간 만료는 키가 액세스 될 때 적용되는 지연 메커니즘과 이벤트 루프 (의사 모드에서 100ms마다)에서 실행되는 키 샘플링을 기반으로하는 활성 메커니즘을 기반으로합니다. 활성 만료 메커니즘이 실행 중일 때 Redis 명령을 처리 할 수 없습니다.
클라이언트 응용 프로그램의 성능에 영향을주지 않으려면 활성 메커니즘이 트리거 될 때마다 (기본적으로 10 개 키) 제한된 수의 키만 처리됩니다. 그러나 25 %가 넘는 키가 만료 된 것으로 밝혀지면 더 많은 키와 루프가 만료됩니다. 이것은 확률 론적 알고리즘이 Redis가 만료해야하는 키의 수에 자동으로 그 활동을 적용하는 방법입니다.
많은 키가 만료 될 때이 적응 형 알고리즘은 Redis의 성능에 큰 영향을 줄 수 있습니다. 자세한 내용은 here을 참조하십시오.
내 제안은 Python-rq가 만료를 설정하여 항목 정리를 Redis에 위임하지 못하도록하려고하는 것입니다. 이것은 어쨌든 대기열 시스템에 대한 열악한 설계입니다.
이것은 훌륭한 솔루션처럼 들립니다. 그런 정교한 대답에 감사드립니다. 나는 그것을 시험해보고 그것이 어떻게 작동하는지 보게 될 것이다. 다시 한 번 감사드립니다! –
그래,'Job' ttl을 줄이면 CPU 사용량이 줄어 듭니다. 매우 감사합니다! –
Redis가 만료 키를 사용하면 CPU 사용을 피하기 위해 ttl을 줄이는 것이 좋지 않습니다.
디디에는 키 - 만료 기능을 사용하여 클리닝 작업을 Redis에 위임한다는 Python-rq의 현재 아키텍처를 지적합니다. 그리고 확실히 디디에 (Didier)가 말했듯이 그것은 최선의 방법이 아닙니다. (이것은 result_ttl이 0보다 큰 경우에만 사용됨)
그런 다음 만료 날짜가 다른 키/작업 세트가있을 때 문제가 발생해야하며 버스트가있을 때 문제가 발생해야합니다 일자리 창출.작업이 하나의 작업자에 완료되었을 때 키가이 문제를 피하기 위해 그들 사이에 충분한 시간과 시간의 주위에 전파해야하기 때문에
그러나 파이썬 RQ 세트, 그리고 너무 감각이없는,
을 키 만료 상황
사용량은 어떻게됩니까? 큰'SORT'가 진행되고 있습니까? 프로덕션 코드에서'KEYS '를 사용합니까? 어디에서도 MONITOR를 운영하고 있습니까? 당신의 지속성 전략은 무엇입니까? –
이 인스턴스에서 지속성을 사용 중지했습니다. 현재 어디서나'KEYS' 또는'MONITOR' 명령을 사용하지 않습니다. 우리는 적어도 내 지식의 범위 내에서'정렬 '을하지 않습니다. 이 인스턴스는'rq' (www.python-rq.org) 전용입니다. –