MongoDB Curseur Timeouts pendant un grand nombre d'écritures

Nous avons un groupe de 2 ensembles de répliques, avec 3 serveurs par ensemble. Avec une seule collection étant partagée. Nous avons également plusieurs autres collections (8+) que nous utilisons quotidiennement. Avec la majorité des données dans la collection fragmentée avec près de 100 millions d'enregistrements.MongoDB Curseur Timeouts pendant un grand nombre d'écritures

Récemment, nous avons ajouté l'exigence d'obtenir 100x les données que nous recevions précédemment, et nous devons écrire cela à mongodb. Un démon a été mis en place pour effectuer les écritures nécessaires pour maintenir la base de données à jour. Le script fonctionne à plus de 200 écritures par seconde, la majorité allant à toutes les collections séparées.

Avec cette quantité d'écritures, nous n'avons pas été en mesure d'effectuer des lectures importantes à des fins d'analyse. Réception d'une combinaison de Cursor Timeouts côté client et côté serveur ("Cursor Not Found").

Nous avons tenté d'effectuer des schémas limit/skip sur les lectures, mais le problème persiste. Quel est le meilleur plan d'action pour remédier à cela, car nous avons besoin à la fois d'une grande quantité d'écritures, avec peu, mais de grandes lectures?

Source

2011-05-09 Bryan

Typiquement, dans un cas comme celui-ci, vous voulez commencer à regarder les requêtes provoquant l'heure. Ensuite, vous voulez regarder le matériel pour voir ce qui est stressé.

Ces requêtes sont-elles correctement indexées?
Quelle est la taille des index? Est-ce qu'ils tiennent dans la RAM?
Pouvez-vous fournir des détails sur l'emplacement des goulots d'étranglement?
Êtes-vous verrouillé sur IO?
Vos processeurs fonctionnent-ils à pleine vitesse?

Y a-t-il quelque chose d'inhabituel dans les journaux?

Fondamentalement, nous devons veiller à ce que vous avez: 1. correctement construit le système pour gérer la requête 2. configuré correctement le système pour gérer les volumes de données

Source

2011-05-09 19:14:07

1. Nous n'Interrogation notre lit avec cette _id champ. 2. Nos index ne sont que légèrement plus grands que la taille de la mémoire, avec nos instances EC2 avec 7,5 Go, et nos index par replSet à 9,5 Go. Nous sommes actuellement en train de passer à des masters de 32 Go. 3. Je ne vois aucun goulot d'étranglement, juste les problèmes lisent complètement les données. 4. Nous sommes généralement écris sur la collection qui prend le plus d'écriture, mais sinon nous allons bien. 5. Nos processeurs ne sont pas vraiment trop stressés du tout. – Bryan

À quoi ressemblent iostat et mongostat? Courez-vous sur des disques EBS? RAIDED? Comment est leur performance? –

mongostat montre% verrouillé flottant autour de 90%, avec des mises à jour dominant les cartes. Nous courons actuellement éphémères sur les maîtres et EBS sur les secondaires. iostat montre des lectures/s à 622 et 365 pour les écritures/s, les lectures sont probablement élevées parce que nous sommes en train de récupérer 2 serveurs de 32 Go. – Bryan

MongoDB Curseur Timeouts pendant un grand nombre d'écritures

Répondre

Questions connexes