Cela dépend également du type de requêtes que vous lancez, veuillez vérifier si les points mentionnés ci-dessous sont là -
- y a-t-il beaucoup de requêtes d'agrégation ? Quel type de structure de collection avez-vous, c'est-à-dire
- y a-t-il beaucoup de tableaux imbriqués ?
- S'agit-il d'une instance unique ou d'un ensemble d'instances dupliquées ? Essayez de placer un jeu de répliques avec lecture et écriture sur un nœud différent.
- Les requêtes renvoient-elles des données de plusieurs collections ?
- Vérifiez que votre instance présente des défauts de page pour combien de % d'opérations ?
- Vérifiez vos journaux pour les opérations avec nscanned ou scanAndOrder élevé pendant les périodes de verrouillage/file d'attente élevés, et indexez en conséquence.
- Vérifiez vos requêtes pour les opérateurs gourmands en CPU tels que $all, $push/$pop/$addToSet, ainsi que les mises à jour de documents volumineux, et en particulier les mises à jour de documents avec de grands tableaux (ou de grands tableaux de sous-documents).
- si votre base de données est lourde en écriture, gardez à l'esprit qu'un seul processeur par base de données peut écrire à la fois (en raison de ce thread qui détient le verrou en écriture). Envisagez de déplacer une partie de ces données dans sa propre base de données.
Ce sont quelques choses qui diminuent les performances au fil du temps. J'ai couvert les cas d'utilisation les plus courants ici, mais veuillez consulter ce message pour plus d'idées.
