2011-12-13 1 views
0

나는 mongomapper와 함께 delayed_jobs를 사용하고 있습니다. 그러나 delayed_jobs 레코드 (약 500k 레코드)를 가져 오는 것은 느립니다.mongomapper가있는 delayed_jobs가 느립니다.

{ locked_by: -1, priority: 1, run_at: 1 } 색인을 생성하기 위해 실행 중이지만 도움이되지 않습니다.

나는 정말 어떤 인덱스가 쿼리를 향상 시킬지 모르겠다. 각 인출에는 약 2 초가 소요됩니다.

Tue Dec 13 09:52:38 [conn497] query api_production.$cmd ntoreturn:1 command: { findandmodify: "delayed_jobs", query: { run_at: { $lte: new Date(1323769957289) }, failed_at: null, $or: [ { locked_by: "host:ip-10-128-145-246 pid:26157" }, { locked_at: null }, { locked_at: { $lt: new Date(1323769057289) } } ] }, sort: { locked_by: -1, priority: -1, run_at: 1 }, update: { $set: { locked_at: new Date(1323769957289), locked_by: "host:ip-10- 128-145-246 pid:26157" } } } reslen:699 1486ms

답변

0

귀하의 인덱스가 쿼리와 일치하지 않습니다 여기에

는 MongoDB의 로그입니다. 귀하의 질의는 먼저 run_at에 기초한 후보자를 없애기 때문에 첫 번째 색인이되어야하지만 그렇지 않습니다.

오히려 우아하지 않은 $or 절이옵니다. 두 가지 기준이 locked_at이고 하나가 locked_by이기 때문에 적절한 색인을 선택하기가 어려울 것입니다.

세 가지 정렬 기준이 있지만 문제는 쿼리 제약 조건의 방향과 정확히 반대입니다. 또한 오히려 긴 문자열을 정렬합니다.

기본적으로 쿼리가 잘 설계되지 않았으며 단일 쿼리에서 너무 많은 작업을 수행하려고합니다. delayed_jobs이 일종의 모듈인지는 모르겠지만 규칙이 더 간단하면 훨씬 쉬울 것입니다. 왜 노동자는 많은 일자리를 잠그고 있습니까? 실제로 현재 작업하고있는 작업을 잠그고 다른 작업자가 크기 조정을 위해 다른 작업 유형을 가져 오는 것이 가장 좋습니다. 작업자는 IP 주소와 PID (엔트로피가없고 선택도가없는 접두사)를 사용하는 대신 uuids를 사용하려고 할 수 있습니다.