Bitte erläutern Sie diese Mongo-Statistiken

504
sivann

Mein Setup: Ich habe 2 Hosts und jeweils 2 Shards.

  • Host1 verfügt über 2 Shards und ist der Master der Repliken
  • host2 hat die sekundäre der 2 shards.

.

  • host1: shard1 (repset1), shard2 (repset2)
  • host2: shard1 (repset1), shard2 (repset2)

Es gibt auch einen dritten Host, der als Schiedsrichter fungiert.

Ich habe 50 Threads, die über Mongos mit REPLICA_SAFE WriteConcern auf jedem Insert zufällig auf beide Shards (über einen Hash) schreiben.

Die Fragen:

  1. mongostat zeigt ungefähr 90% gesperrt für beide Shards in host1 und ungefähr 1% für host2 an. Da ich REPLICA_SAFE verwende, das angeblich auf beide Server schreibt, sollten die Sperren nicht gleich sein?
  2. mongostat meldet qr = 30 für beide Shards von host1 und qw = 0 immer. Da ich nur Schreibvorgänge mache, wie ist das möglich? Darüber hinaus werden auf Host2 alle Warteschlangen gemeldet. 0. Die Fehler sind in allen Shards / Hosts gleich (ungefähr 80).
  3. netIn / netOut auf den Secondaries (Host2) beträgt immer etwa 200 Byte / Sek. Zu niedrig.
  4. mongos hat 53 Verbindungen, die Shards von host1 haben 71 und 71 und die Shards von host2 haben 9 und 8. Wie ist das?
0
Welche Version von Mongo laufen Sie? Wenn> = 2.2.X sind diese Sperrstatistiken für die betreffende Sammlung global oder aggregiert? daveh vor 11 Jahren 0

2 Antworten auf die Frage

1
Marc

Seien Sie vorsichtig, wenn Sie mehrere Instanzen von Mongod auf einem Host ausführen. Sie konkurrieren bei der Systemintegration:

Oder führen Sie VMs mit dediziertem RAM und CPU aus (so könnten Sie diese 24Core-Systeme mit MongoDB effizienter nutzen;)

1
daveh

Sivann,

Es sieht so aus, als würden Sie Mongo <2.0 verwenden, wenn Sie das nicht tun, was die Dinge ändern kann. Sie sagen, Sie verwenden REPLICA_SAFE. Welches W-Level verwenden Sie? Wenn es w: 1 ist, bestätigen Sie einfach, dass die Schreibvorgänge an Ihre Primärdatenbank erfolgreich waren, und Sie sollten w: 2 verwenden, um zu bestätigen, dass die Schreibvorgänge Ihre Sekundärdatenliste erreicht haben.

  1. Die Replikation berücksichtigt dies. Ihre Einfügungen setzen eine Schreibsperre ein, wenn sie eingefügt werden. Dadurch wird verhindert, dass die Replikation die zu replizierenden Daten liest.

  2. Verstärkt Punkt 1. Ihre Replikationslesevorgänge befinden sich hinter den Schreibvorgängen der Einfügungen in einer Warteschlange. Fehler sind hier wahrscheinlich das Problem, da Ihr System Dinge in den RAM-Speicher blättern muss, die für die Replikation eingelesen werden müssen, was seine Sperre nachgibt. Sie werden wahrscheinlich auch einen Konflikt zwischen Ihren beiden Vorwahlen um RAM sehen, aus den Gründen, die Marc genannt hat.

  3. Scheint niedrig, kann aber nicht sicher sein. Wahrscheinlich warten Ihre Systeme darauf, Daten im RAM zu speichern oder auf eine Schreibsperre, um sie zu replizieren.

  4. In den Logfiles können Sie sehen, welche Verbindungen wohin gehen. Ohne zu wissen, wo es ist, konnte ich Ihnen nicht sagen warum. Allerdings ist die Anzahl der Verbindungen hier nicht unvernünftig.

Ich verwende Mongo 2.2 sivann vor 11 Jahren 0

Verwandte Probleme