Redis 시간 초과 문제 해결의 분석 예

며칠 전 작업 중에 갑자기 Redis가 충돌했다는 경고를 받았고 많은 사람들이 특정 Redis 연결 시간 초과에 대해 논의하고 있었습니다. 처음에는 큰 문제가 있는 줄 알았는데, 시간이 좀 지나면 회복될 줄 누가 알았겠어요. 그때 서버에 로그인해서 모니터링을 확인했어요. 처음으로 QPS를 살펴보세요:

QPS가 높지 않은 것을 볼 수 있는데 왜 한동안 데이터를 얻지 못하셨나요? 그런 다음 계속해서 Redis의 CPU 사용량을 살펴보세요.

CPU가 포화된 것을 볼 수 있는데, 이는 Redis가 단일 스레드이기 때문에 CPU를 100% 사용한 후에는 다른 명령을 처리할 수 없으며, zabbix는 그래프가 깨지는 정보 명령을 실행할 수 없습니다. qps. 그럼 우리는 이미 CPU 포화로 인해 문제가 발생한다는 것을 알고 있는데, 그 이유는 무엇일까요? 그런 다음 CPU 사용량이 높은 기간 동안 느린 로그가 있는지 계속 확인하세요.

이것은 높은 CPU 사용량의 원인은 아닌 것 같아 문제 해결이 어렵습니다. 이 예는 마스터 노드와 슬레이브 노드입니다. 그런 다음 슬레이브 라이브러리의 CPU 사용량을 살펴보겠습니다.

맙소사, 무슨 일이야? 라이브러리에서 CPU의 74%가 사용되지 않는 이유는 무엇입니까? 이것은 과학적이지 않습니까? 어쨌든 슬레이브 라이브러리에 느린 로그가 있는지 확인하세요.

맙소사, 무슨 일이야? 아무도 슬레이브 라이브러리를 사용하지 않습니다. 읽기 전용인지 확인:

127.0.0.1:6103> CONFIG GET "slave-read-only"
1) "slave-read-only"
2) "yes"
127.0.0.1:6103> 

읽기 전용인 것 같아서 혼란스럽습니다. 마지막으로, 이 시점에서 메인 라이브러리에 만료된 큰 키가 있고 메인 라이브러리에서 만료된 키의 느린 작업으로 인해 슬레이브 라이브러리의 키 만료가 삭제되지 않는다는 생각이 문득 떠올랐습니다. DEL 명령어를 시작하는 메인 라이브러리. 이때 슬레이브 라이브러리는 느린 로그를 기록합니다. 위의 느린 로그를 보면 최대 DEL 작업이 335ms라는 것을 알 수 있습니다.

info commandstats 명령을 다시 사용하여 다음을 확인하세요.

위 내용은 Redis 시간 초과 문제 해결의 분석 예의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!