Váš pozorovaný problém s výkonem při počátečním dotazu je pravděpodobně jedním z následujících problémů (v hrubém pořadí pravděpodobnosti):
1) Vaše aplikace / webová služba má určitou režii na inicializaci při prvním požadavku (tj. přidělení paměti, nastavení fondů připojení, vyřešení DNS, ...).
2) Indexy nebo data, která jste požadovali, ještě nejsou v paměti, takže je třeba je načíst.
3) Optimalizátor dotazů Spuštění prvního požadavku může trvat o něco déle, protože porovnává provedení plánu pro váš vzor dotazu.
Bylo by velmi užitečné otestovat dotaz pomocí mongo shell a izolujte, zda režie souvisí s MongoDB nebo vaší webovou službou (spíše než načasování obojího, jak jste to udělali vy).
Následuje několik poznámek souvisejících s MongoDB.
Ukládání do mezipaměti
MongoDB nemá „caching“ čas pro dokumenty v paměti. Používá soubory mapované v paměti pro diskový I/O a dokumenty v paměti jsou založeny na vašich aktivních dotazech (dokumenty/indexy, které jste nedávno načetli) a také na dostupné paměti. Správce virtuální paměti operačního systému má na starosti ukládání do mezipaměti a obvykle se bude řídit algoritmem LRU (Least-Recently Used), aby rozhodl, které stránky vyměníte z paměti.
Využití paměti
Očekávané chování je takové, že se MongoDB časem rozroste a využije veškerou volnou paměť k uložení vaší aktivní pracovní sady dat.
Podívejte se na vámi poskytnutý db.stats() čísla (a za předpokladu, že je to vaše jediné databáze), vypadá to, že velikost vaší databáze je aktuálně asi 1 Gb, takže byste měli být schopni ponechat vše v rámci vaší celkové 10 Gb RAM, pokud:
- o paměť soutěží další procesy
- restartovali jste svůj
mongodserver a tyto dokumenty/indexy ještě nebyly vyžádány
V MongoDB 2.2 je nový touch
příkaz, který můžete použít k načtení indexů nebo dokumentů do paměti po restartu serveru. Toto by se mělo používat pouze při prvním spuštění k "zahřátí" serveru, protože jinak byste mohli zbytečně vynutit aktuální "aktivní" data z paměti.
Na linuxovém systému můžete například použít top příkaz a mělo by se zobrazit toto:
- virtuální bajty/VSIZE budou mít tendenci odpovídat velikosti celé databáze
- Pokud na serveru nejsou spuštěny jiné procesy, bude rezidentní bajty/RSIZE představovat celkovou paměť počítače (včetně obsahu mezipaměti systému souborů)
mongodby neměl používat swap (protože soubory jsou mapovány z paměti)
Můžete použít mongostat
nástroj k rychlému zobrazení vašeho mongod aktivitu .. nebo užitečněji použijte službu jako MMS
sledovat metriky v průběhu času.
Optimalizátor dotazů
MongoDB Optimalizátor dotazů
porovná provedení plánu pro vzor dotazu každých ~1 000 operací zápisu a poté uloží „vítězný“ plán dotazů do mezipaměti, dokud příště optimalizátor nespustí .. nebo explicitně zavoláte explain()
na tento dotaz.
Toto by mělo být jednoduché otestovat:spusťte svůj dotaz v mongo shell s .explain() a podívejte se na časování ms a také na počet položek rejstříku a naskenovaných dokumentů. Načasování pro explain() není skutečný čas, který bude trvat spuštění dotazů, protože zahrnuje náklady na porovnání plánů. Typické provádění bude mnohem rychlejší .. a pomalé dotazy můžete hledat ve svém mongod log.
Ve výchozím nastavení bude MongoDB protokolovat všechny dotazy pomaleji než 100 ms, takže to poskytuje dobrý výchozí bod pro hledání dotazů k optimalizaci. Hodnotu pomalé ms můžete upravit pomocí --slowms
možnost konfigurace nebo pomocí Database Profiler
příkazy.
Další informace v dokumentaci MongoDB:
- Ukládání do mezipaměti
- Kontrola využití paměti serveru
- Profilování databáze
- Vysvětlete
- Monitorování a diagnostika