Sidekiq 워커의 데이터베이스 풀링에 대해 명확한 설명을 주실 수 있는 분 계신가요?
현재 DISCOURSE_DB_POOL을 15로 설정해 두었고, Sidekiq 워커 2개 각각의 동시성(concurrency)은 10으로 설정되어 있습니다. Sidekiq 문서를 읽어본 결과, Sidekiq 스레드가 데이터베이스 풀을 공유하는 것으로 보이므로, Sidekiq 워커에서 발생하는 데이터베이스 연결의 최대치는 15 * 2 = 30개일 것으로 예상하고 있습니다. 그러나 이러한 이해에도 불구하고, 예상 최대치인 30개를 초과하는 데이터베이스 연결 스파이크가 관찰되고 있습니다.
이러한 스파이크는 대략 15분마다 발생하며, 주로 PeriodicalUpdates 예약 작업과 관련이 있는 것으로 보입니다.
이러한 스파이크를 피하는 데 도움이 될 통찰을 공유해 주실 수 있을까요?
@david 이 분야에서 정말 놀라운 성과를 이루셨네요. 몇 가지 통찰을 공유해 주실 수 있을까요?
정확한 세부 사항은 바로 알기 어렵습니다.
UNICORN_SIDEKIQS 환경 변수를 커스터마이징했는지 확인해 보시는 것이 좋습니다. 이 변수는 시작되는 Sidekiq 프로세스 수를 나타내며, 각 프로세스에는 여러 스레드가 포함됩니다.
그래프에 정확히 어떤 내용이 표시되고 있나요? '동시 연결 수’인가요? 아니면 '생성된 연결 수’인가요? 후자라면 일부 연결이 매우 빠르게 생성되고 폐기되고 있을 수 있습니다.
마지막으로 한 가지 더 질문드립니다: 여기서 해결하려는 문제는 무엇인가요? 연결 수 때문에 문제가 발생하고 있는 건가요?
답변 주셔서 감사합니다.
현재 설정된 관련 항목은 다음과 같습니다.
이는 2개의 Sidekiq 프로세스가 각각 10개의 스레드를 가지고 있음을 의미합니다.
해당 그래프는 현재 클라이언트 연결 수를 나타냅니다.
우리는 연결 풀의 크기(PostgreSQL 앞에 있는 RDS 프록시)를 올바르게 설정하려고 합니다. 이를 위해 애플리케이션 측의 연결 풀링에 대한 더 나은 이해가 필요합니다. 왜 애플리케이션이 DISCOURSE_DB_POOL 설정을 예상대로 준수하지 않는 것일까요?
DISCOURSE_DB_POOL이 예상대로 작동하고 있다면, 왜 DB 연결에서这么大的 스파이크가 발생하는 것일까요? 이러한 스파이크는 PeriodicalUpdates 예약 작업 실행 시점에 일치하는 것으로 보입니다.
추가로 궁금한 점이 있으시면 말씀해 주세요. 이 수수께끼를 풀어내는 데 도움을 주셔서 감사합니다.
데이터베이스 풀링을 구성하려면 DISCOURSE_DB_POOL 환경 변수 외에도 설정 파일이 필요합니까?
프록시에 문제가 없는지 100% 확신하시나요?
네, 프록시 쪽 문제는 아닌 것 같습니다.
