hoher Hintergrund Flush Avg Mongodb

7

ähnliche Frage: High Global Lock% auf Mongodb

Überblick

Wir haben ein Replikat für die Produktionskonfiguration in Version 2.4.8 Mongodb, das auf fünf 4-Core-VMs mit 28 GB RAM und Standard-Azure-Datadisk-Festplatten unter 64-Bit-CentOS 6 ausgeführt wird. Die CPU-Auslastung beträgt ca. 15% pro Sekundärteil. Die CPU-Auslastung beträgt ~ 5-10% auf der Primärseite. Wir haben derzeit Probleme mit der hohen globalen Schreibsperre und dem Hintergrund-Flush-Durchschnitt auf unserer Primärseite. Unsere globale Schreibsperre liegt bei unserer primären Schreibsperre zwischen 30 und 40%, obwohl wir nur ~ 200 Einfügen / Aktualisieren / Löschen pro Sekunde haben (siehe MMS-Ausgabe unten). Wir haben auch festgestellt, dass unser Hintergrund-Flush-Durchschnitt zwischen 2 und 15 Sekunden liegt. Leider verursacht dies eine ernsthafte Anzahl langsamer Abfragen (bis zu 50 Aktualisierungen / Einfügungen> 100 ms pro Sekunde). Wir haben über Sharding nachgedacht, sind jedoch der Meinung, dass Mongodb eine bessere Leistung erbringen sollte.

Testen

Dies sagt mir, dass wir Probleme beim Schreiben auf unsere Festplatten haben, aber das Ausführen eines einfachen iostat zeigt, dass unsere Auslastung auf SDC (der Festplatte, auf die wir schreiben) NICHT maximal ist und zwischen 20 und 40% liegt:

$ iostat -x 1

Das Ergebnis für 4 Sekunden:

Linux 2.6.32-279.14.1.el6.openlogic.x86_64 (mongodb3-wus)   05/08/2014  _x86_64_    (4 CPU)

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           5.28    0.00    1.82    5.50    0.00   87.40

Device:         rrqm/s   wrqm/s     r/s     w/s   rsec/s   wsec/s avgrq-sz avgqu-sz   await  svctm  %util
sda               0.05     0.04    0.06    0.11     3.25     1.23    26.13     0.00   18.07  14.87   0.25
sdc               0.02   216.57    1.70   95.83   216.22  3106.45    34.07     9.27   95.07   4.32  42.11
sdb               0.00    11.35    0.01    0.56     0.05    95.25   169.44     0.01   18.44   0.11   0.01

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           2.56    0.00    2.05    0.00    0.00   95.38

Device:         rrqm/s   wrqm/s     r/s     w/s   rsec/s   wsec/s avgrq-sz avgqu-sz   await  svctm  %util
sda               0.00     0.00    0.00    0.00     0.00     0.00     0.00     0.00    0.00   0.00   0.00
sdc               0.00     0.00    0.00   15.00     0.00   624.00    41.60     0.20   11.80  13.47  20.20
sdb               0.00     0.00    0.00    0.00     0.00     0.00     0.00     0.00    0.00   0.00   0.00

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           3.07    0.00    3.07    0.26    0.00   93.61

Device:         rrqm/s   wrqm/s     r/s     w/s   rsec/s   wsec/s avgrq-sz avgqu-sz   await  svctm  %util
sda               0.00     0.00    0.00    0.00     0.00     0.00     0.00     0.00    0.00   0.00   0.00
sdc               0.00     0.00    3.00   15.00    24.00   352.00    20.89     0.25   15.17  13.44  24.20
sdb               0.00     0.00    0.00    0.00     0.00     0.00     0.00     0.00    0.00   0.00   0.00

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           3.33    0.00    1.79    0.77    0.00   94.10

Device:         rrqm/s   wrqm/s     r/s     w/s   rsec/s   wsec/s avgrq-sz avgqu-sz   await  svctm  %util
sda               0.00     0.00    0.00    0.00     0.00     0.00     0.00     0.00    0.00   0.00   0.00
sdc               0.00    11.00    0.00   17.00     0.00   768.00    45.18     0.26   15.18  14.35  24.40
sdb               0.00     0.00    0.00    0.00     0.00     0.00     0.00     0.00    0.00   0.00   0.00

Ich habe auch einen einfachen Lasttest mit dd durchgeführt:

dd if=/dev/zero of=/dev/sdc1 count=512 bs=1024k

Das Ergebnis dieses Tests zeigte, dass die Schreibgeschwindigkeit ~ 840 MB / s beträgt:

512+0 records in
512+0 records out
536870912 bytes (537 MB) copied, 0.638451 s, 841 MB/s

Ulimit-Ergebnisse für Mongodb:

[mongod #8066 -- limits]
Limit                     Soft Limit           Hard Limit           Units     
Max cpu time              unlimited            unlimited            seconds   
Max file size             unlimited            unlimited            bytes     
Max data size             unlimited            unlimited            bytes     
Max stack size            10485760             unlimited            bytes     
Max core file size        0                    unlimited            bytes     
Max resident set          unlimited            unlimited            bytes     
Max processes             224341               224341               processes 
Max open files            20000                20000                files     
Max locked memory         65536                65536                bytes     
Max address space         unlimited            unlimited            bytes     
Max file locks            unlimited            unlimited            locks     
Max pending signals       224341               224341               signals   
Max msgqueue size         819200               819200               bytes     
Max nice priority         0                    0                    
Max realtime priority     0                    0                    
Max realtime timeout      unlimited            unlimited            us   

MMS, Mongostat, Mongotop für die Grundschule

Ich habe auch unsere MMS-Ausgabe-, Mongostat- und Mongotop-Ausgaben unten angegeben:

! MMS: MMS-Ausgabe hier klicken

Mongostat:

connected to: 127.0.0.1:27019
    insert  query update delete getmore command flushes mapped  vsize    res faults      locked db idx miss %     qr|qw   ar|aw  netIn netOut  conn set repl       time 
        26     41     95     *0     294   178|0       0  52.4g   107g  25.1g      0  chronicle:5.6%          0      65|2     1|4    45k   136k   486 rs0  PRI   23:15:18 
        96    158    524     *0    1266   783|0       0  52.4g   107g  25.1g      1 chronicle:82.9%          0       0|0     0|0   235k   759k   486 rs0  PRI   23:15:19 
        33     62    109     *0     637   253|0       0  52.4g   107g  25.1g      0      local:7.2%          0       0|0     0|0    78k   208k   486 rs0  PRI   23:15:20 
        58     89    153     *0     920   321|0       0  52.4g   107g  25.1g      0     local:16.1%          0       0|0     0|1   113k   569k   486 rs0  PRI   23:15:21 
        55     95    138     *0     887   322|0       0  52.4g   107g  25.1g      0 chronicle:20.3%          0       0|0     0|0   111k   297k   486 rs0  PRI   23:15:22 
        24     59     81     *0     217   174|0       0  52.4g   107g  25.1g      1         .:88.5%          0      23|0     0|1    46k   141k   486 rs0  PRI   23:15:23 
        51     64    136     *0     760   263|0       0  52.4g   107g  25.1g      0 chronicle:17.1%          0       0|0     0|0    93k   266k   486 rs0  PRI   23:15:24 
        42     60    129     *0     695   288|0       0  52.4g   107g  25.1g      0      local:7.3%          0       0|0     0|0    90k   253k   486 rs0  PRI   23:15:25 
        33     55     99     *0     693   215|0       0  52.4g   107g  25.1g      1      local:3.1%          0       0|0     0|0    76k   455k   486 rs0  PRI   23:15:26 
        45     70     95     *0     763   250|0       0  52.4g   107g  25.1g      1      local:9.0%          0       0|0     0|0    88k   225k   486 rs0  PRI   23:15:27 

Mongotop:

connected to: 127.0.0.1:27019

                                     ns       total        read       write     2014-05-07T23:09:17
                      chronicle.ledgers        93ms         0ms        93ms
                         local.oplog.rs        47ms        47ms         0ms
                         cliqueme.sites        13ms         0ms        13ms
                    chronicle.analytics         4ms         0ms         4ms
          chronicle_test.system.indexes         0ms         0ms         0ms
       chronicle_test.system.namespaces         0ms         0ms         0ms
            chronicle_test.system.users         0ms         0ms         0ms

                                     ns       total        read       write     2014-05-07T23:09:18
                      chronicle.ledgers       101ms         0ms       101ms
                         local.oplog.rs        66ms        66ms         0ms
                       cliqueme.cliques        19ms         0ms        19ms
                    chronicle.analytics         6ms         0ms         6ms
                         cliqueme.sites         4ms         0ms         4ms
                           local.slaves         1ms         0ms         1ms
                 cliqueme.notifications         0ms         0ms         0ms
                      cliqueme.messages         0ms         0ms         0ms

                                     ns       total        read       write     2014-05-07T23:09:19
                         local.oplog.rs        66ms        66ms         0ms
                      chronicle.ledgers        52ms         0ms        52ms
                    chronicle.analytics        24ms         0ms        24ms
                       cliqueme.cliques         7ms         0ms         7ms
                         cliqueme.sites         4ms         0ms         4ms
                           local.slaves         1ms         0ms         1ms
                 cliqueme.notifications         0ms         0ms         0ms
                      cliqueme.messages         0ms         0ms         0ms

                                     ns       total        read       write     2014-05-07T23:09:20
                      chronicle.ledgers      1842ms         0ms      1842ms
                         cliqueme.sites       885ms         0ms       885ms
                       cliqueme.cliques        70ms         0ms        70ms
                         local.oplog.rs        55ms        55ms         0ms
                    chronicle.analytics         5ms         0ms         5ms
                           local.slaves         1ms         0ms         1ms
                 cliqueme.notifications         0ms         0ms         0ms
                      cliqueme.messages         0ms         0ms         0ms

                                     ns       total        read       write     2014-05-07T23:09:21
                      chronicle.ledgers        84ms         0ms        84ms
                         local.oplog.rs        64ms        64ms         0ms
                         cliqueme.sites        41ms         0ms        41ms
                       cliqueme.cliques        11ms         0ms        11ms
                    chronicle.analytics         4ms         0ms         4ms
          chronicle_test.system.indexes         0ms         0ms         0ms
       chronicle_test.system.namespaces         0ms         0ms         0ms
            chronicle_test.system.users         0ms         0ms         0ms

                                     ns       total        read       write     2014-05-07T23:09:22
                      chronicle.ledgers       276ms         0ms       276ms
                         local.oplog.rs        90ms        90ms         0ms
                       cliqueme.cliques        16ms         0ms        16ms
                    chronicle.analytics         6ms         0ms         6ms
                         cliqueme.sites         4ms         0ms         4ms
                           local.slaves         1ms         0ms         1ms
                 cliqueme.notifications         0ms         0ms         0ms
                      cliqueme.messages         0ms         0ms         0ms

Hat jemand Vorschläge, wie wir diese Leistung optimieren können? Wir haben gehört, dass einige Leute im Standalone-Modus bis zu 2K-Schreibvorgänge pro Sekunde ausführen können. Würde ein Wechsel von HDD zu RAID oder SSD dies möglicherweise lösen?

Wir möchten Sharding als letzten Ausweg verwenden.

UPDATE: Wir konnten dieses Problem immer noch nicht lösen, aber weil wir eine Lösung brauchten, sind wir schnell in einen Sharded-Cluster umgezogen. Wir möchten das Problem immer noch herausfinden, da es uns im Sharded-Cluster immer noch betrifft.

Nick Swenson
quelle
@Nyxynyx hätten Sie Ratschläge basierend auf: dba.stackexchange.com/questions/55922/… . Vielen Dank!
Nick Swenson

Antworten:

4

Ihre Mongo-Statistik zeigt eine höhere Anzahl von Updates als Einfügungen. Eine Sache, die zu Problemen mit hoher Schreibsperre führen kann, ist, wenn Ihre Aktualisierungen normalerweise die Dokumentgröße erhöhen und das Dokument in die Datendatei verschieben. Wir sind selbst darauf gestoßen, aber wir haben zu der Zeit mit Mongo-Unterstützung zusammengearbeitet, um herauszufinden, sodass ich mich nicht erinnere, welche Metrik oder Statistik Ihnen sagen würde, dass dies der Fall ist. Dies wäre wahrscheinlich nur dann ein Problem, wenn Ihre Dokumentgrößen sehr groß wären. Am Ende haben wir ein Sub-Array aufgeteilt, das immer zu einer eigenen Sammlung hinzugefügt wurde, sodass wir nur neue Dokumente hinzugefügt haben, anstatt ein vorhandenes zu ändern.

Das usePowerOf2Sizes-Flag in der Sammlung kann ebenfalls dazu beitragen, dies zu verringern, indem den Dokumenten Raum für Wachstum gegeben wird. Dies ist anscheinend die Standardeinstellung für 2.6, aber Sie müssten sie aktivieren, wenn Sie noch nicht für 2.6 sind. Die hier beschriebene Einstellung: http://docs.mongodb.org/manual/reference/command/collMod/

Ted Elliott
quelle
1
Sie haben gerade einen erwachsenen Mann zum Weinen gebracht. Sie wissen nicht, wie lange ich versucht habe, dieses Problem zu beheben (tatsächlich Hunderte von Stunden). Ich habe tatsächlich einige Male in diese zunehmende Dokumentgröße eingecheckt, aber völlig vergessen, dass eines unserer Legacy-Modelle auch Sub-Arrays verwendet. Sobald ich auf das PowerOf2Sizes-Flag umgestiegen bin, ist die Schreibsperre sofort auf unter 10% gefallen, die Hintergrundspülung liegt nahe 1 Sek. Unsere Antwortzeit von unseren Servern ist kürzer als je zuvor. Vielen Dank für das Teilen Ihrer Erfahrungen. Ernsthaft. Kann ich Ihnen einen Geschenkkorb oder einen Welpen schicken?
Nick Swenson
Ich will einen Welpen!!!
Asya Kamsky