Aktualizacja:wydaje się być problemem 2.0.x...
Właśnie uruchomiłem dokładnie to samo zapytanie z 2.0.xi 1.4.x. Gdy Limit =1, oba działają szybko ~1ms. Gdy Limit =2, wersja 1.4.x pozostaje około 1ms, ale wersja 2.0.x skacze do 25ms. Tak więc nie jest to tylko problem z wyjściem wyjaśniania — to tylko symptom problemu.
W czwartek, 8 stycznia 2015 r. 9:04:05 UTC-8, Joshua Abrams napisał:Interesting... dokładnie to samo zapytanie używające 1.4.x daje właściwe wyjaśnienie, gdzie n =2 (i tak dalej). Czy może to mieć wpływ na wydajność? Kiedy uruchamiam zapytanie, w którym Limit =1 jest szybki (zgodnie z oczekiwaniami), ale gdy Limit =2 jest 100x wolniejszy...
W czwartek, 8 stycznia 2015 r. 8:52:28 UTC-8, christkv napisał:niezupełnie. Proponuję stworzyć minimalnie odtwarzalny przypadek testowy (kod i dane) i otworzyć zgłoszenie na jira.mongodb.com. trochę trudno wiedzieć, co się może dziać. to mało prawdopodobne, aby był kierowcą, ale nigdy nie wiadomo. spróbuj również z gałęzią 1.4.x, aby przynajmniej wykluczyć, że jest to problem z gałęzią 2.0.x.
W czwartek 8 stycznia 2015 17:47:45 UTC+1 Joshua Abrams napisał:Właśnie sprawdziłem i używam sterownika 2.0.12. Masz inne myśli?
W czwartek 8 stycznia 2015 08:23:16 UTC-8, christkv napisał:explain to po prostu przestrojenie wszystkich wyników w sterowniku zamiast wyników częściowych. w ten sposób otrzymujesz plan. Jedną rzeczą, która przychodzi na myśl, może być to, że korzystasz ze sterownika wcześniejszego niż 1.4.19, w którym wystąpił błąd, w którym batchSize był ustawiony na 1.
W czwartek, 8 stycznia 2015 r. o 17:01:42 UTC+1, Joshua Abrams napisał:Ostatnio miałem szereg problemów z wydajnością sterownika.Limit =1 =1 ms, Limit> 1 =150 ms (mongo-melt-down)
Nie jestem pewien, co to powoduje – i nie można debugować, gdy nie mogę uzyskać odpowiedniego wyjaśnienia:Natywny sterownik węzła MongoDB:Wyjaśnienie jest zepsute?
