@angela, @Asya, merci beaucoup de m'avoir aidé. Il s'est avéré que la cause principale de la latence était mongodb GLOBAL LOCK lui-même. Nous avions un pourcentage de verrouillage qui était en moyenne de 5% et atteignait parfois 30 à 50%, ce qui entraîne des requêtes lentes. Si vous rencontrez ce problème, la première chose à faire est d'activer le service MMS de mongodb (mms.10gen.com), qui vous donnera beaucoup d'informations sur ce qui se passe exactement dans votre serveur db.
Dans notre cas, le pourcentage de VERROUILLAGE était vraiment élevé et il y avait plusieurs raisons à cela. La première chose que vous devez faire est de lire la documentation mongodb sur la concurrence, http://docs.mongodb.org/manual/faq/concurrency/
La raison du verrouillage peut être au niveau de l'application, mongodb ou du matériel.
1) Notre application faisait beaucoup de updates et chaque mise à jour (plus de 100 ops/sec) détient un global lock en mongodb. Le problème était que lorsqu'une mise à jour se produit pour une entrée qui n'est pas en mémoire, mongo devra d'abord charger les données dans la mémoire, puis les mettre à jour (en mémoire) et tout le processus se passe à l'intérieur du global lock. Si le tout prend 1 sec à compléter (0.75sec pour charger les données du disque et 0.25sec pour mettre à jour dans la mémoire), le reste des appels de mise à jour attend (pour l'ensemble 1 sec) et de telles mises à jour commence à se mettre en file d'attente ... vous remarquerez que les demandes ralentissent de plus en plus dans votre serveur d'applications.
La solution pour cela (bien que cela puisse paraître idiot) est de query pour les mêmes données avant de faire un update. Ce qu'il fait effectivement déplace les « données de charge à la mémoire » (0.75sec) part de l'global lock ce qui réduit considérablement votre lock percentage
2) L'autre cause principale de verrouillage global est les données de MongoDB flush sur le disque. Fondamentalement dans tous les 60sec (ou moins) mongodb (ou le système d'exploitation) écrit les données sur le disque et un global lock est tenue au cours de ce processus. (Ce genre explique les requêtes lentes aléatoires). Dans vos statistiques MMS, voir le graphique pour background flush avg ...Si c'est élevé, cela signifie que vous devez obtenir des disques plus rapides.
Dans notre cas, nous sommes passés à une nouvelle EBS optimized exemple dans EC2 et aussi cogné notre provisionné IOPS de 100 à 500 qui a presque réduit de moitié le background flush avg et les serveurs sont beaucoup plus heureux maintenant.
Pourrait-il y avoir d'autres opérations que vous effectuez sur le même processus mongod qui provoquent une lenteur globale? Il serait utile d'en voir plus dans votre fichier journal si cela est possible. En outre, vous devriez essayer Dex. Dex est un outil open-source qui examine vos requêtes lentes et recommande les index (http://mongolab.org/#view=dex). – angela
En outre, vous devriez regarder les documents de notes de production pour MongoDB à http://docs.mongodb.org/manual/administration/production-notes/. Par exemple, vous devez monter votre volume en utilisant ext4 ou xfs et vous assurer que vous éteignez atime. – angela
il ne fait aucun doute que cette requête utilise un index, donc Dex est peu susceptible d'aider. Cependant, la question de savoir ce que fait votre instance MongoDB est pertinente. Par exemple, faites-vous beaucoup d'écritures? Des requêtes lentes occasionnelles peuvent coïncider avec des bouffées de vaisselle. Vous pourriez obtenir une meilleure réponse avec (a) plus d'informations (b) en demandant cela sur les utilisateurs de MongoDB google group. –