Mongoose: 4.7.1 => 4.7.2 : Zeitüberschreitung bei MongoError-Verbindung

Erstellt am 9. Dez. 2016  ·  44Kommentare  ·  Quelle: Automattic/mongoose

Beim Testen von [email protected] / [email protected] bekomme ich:

MongoError: Zeitüberschreitung bei Verbindung 2 zu XXXXXX
bei Function.MongoError.create (/node_modules/mongodb-core/lib/error.js:29:11)
bei Steckdose.(/node_modules/mongodb-core/lib/connection/connection.js:186:20)
bei Socket.g (events.js:286:16)
bei emitNone (events.js:86:13)
bei Socket.emit (events.js:185:7)
bei Socket._onTimeout (net.js:333:8)
bei tryOnTimeout (timers.js:224:11)
bei Timer.listOnTimeout (timers.js:198:5)' } 'Zeitüberschreitung bei Verbindung 2 zu XXXXXX

das passiert nicht mit [email protected] / [email protected].

Mehr Details:

  • Abfrage: aggregieren mit allowDiskUse(true).read('secondaryPreferred').cursor()
  • Timing: Der Fehler tritt etwa 35 Sekunden nach dem Senden der Abfrage auf (bevor erste Ergebnisse empfangen werden).
  • Knotenversion: v6.3.0
  • npm-Version: 3.10.9
  • Verbindungsoptionen:
{
 "socketOptions": {
    "socketTimeoutMS": 240000,
    "keepAlive": 10000,
    "connectTimeoutMS" : 30000
} 
  • Anfrage:
[
    { $match: {
            _id: { $lt: oid },
            signature: { $exists: true }
        }
    },
    { $group: { 
            _id: { myid: '$myid', signature: '$signature' },
            count: { $sum:  1 },
            myid: { $first: '$myid' },
            docs: { $push: { _id: '$_id', name: '$name' } }
        }
    },
    { $match: {
            count: { $gt : 1 }
        }
    }
]
docs

Hilfreichster Kommentar

Das Problem ist seit einiger Zeit ungelöst.
Was sollten wir tun, um dies zu beheben?
Irgendwann würde ich gerne auf die neuere Version updaten, aber das geht erst, wenn das behoben ist.

Alle 44 Kommentare

Ich habe das gleiche Problem, [email protected] , [email protected]

  • Das Setzen von socketTimeoutMS auf höhere Werte oder 0 macht keinen Unterschied
  • Das Setzen von connectTimeoutMS auf höhere Werte oder 0 macht keinen Unterschied
  • es wird kein „close“- oder „reconnected“-Ereignis ausgelöst, sondern nur ein „timeout“, das zu einem Mongoose-Fehler im Callback führt

Ein Rollback auf [email protected] / [email protected] löst das Problem, dh es verursacht keine Zeitüberschreitungen

Von [email protected] bis 2.2.12 hat sich der Timeout-Event-Listener von "once" auf "on" geändert, vielleicht hat das etwas damit zu tun?

Oder sollten wir dies als Problem im nativen Mongodb-Treiber posten?

@silentjohnny Bekomme das gleiche Problem mit [email protected]

Ich würde ein Problem im nativen Mongodb-Treiber posten, Mongoose tut nicht viel bei der Erstverbindung.

Seltsam. Ich habe das gleiche Problem, aber mit [email protected] und höher, die [email protected] verwenden
Mit [email protected] und [email protected] funktioniert es! .
Meine aggregierte Abfrage ist ohne Optionen, also weiß ich nicht, vielleicht ist das der Unterschied zwischen mir und dem ursprünglichen Problem @dcolens .

Hat jemand ein Problem mit dem nativen Treiber geöffnet? damit ich dem folgen kann...
Im Moment bleibe ich bei [email protected]

[email protected] aktualisiert auf [email protected] , das einen Fix für das Überwachen von Zeitüberschreitungen bei Operationen und das Generieren eines Zeitüberschreitungsereignisses bei laufenden Operationen @1284917 enthält

Bald wird Mongoose auf [email protected] aktualisiert, ich werde es versuchen.

Dasselbe Problem für mich, und ich bin mir nicht einmal sicher, ob es nur lange laufende Aggregate sind, die eine Zeitüberschreitung haben, oder ob es zufällig und überhaupt keine echte Zeitüberschreitung ist. Es scheint, als würde es manchmal fast sofort ablaufen, aber manchmal läuft es etwa 30 Sekunden lang. In diesem speziellen Fall habe ich vier aggregat.execs gleichzeitig ausgeführt.

Das Zurücksetzen auf [email protected] und [email protected] behebt das Problem, also mache ich das vorerst.

Dies sollte hoffentlich in der nächsten Version behoben werden, da Mongoose 4.7.7 [email protected] verwendet . Wie auch immer, das ist nicht wirklich ein Mungo-Problem, wie @vkarpov15 sagte, sondern mehr mit Mongodb zu tun. Ich werde dies vorerst schließen, aber wenn Sie nach der nächsten Veröffentlichung immer noch dasselbe Problem erhalten, sollten Sie ein Ticket oder eine PR auf der Seite von Mongodb eröffnen.

Ich denke, dass an diesem Problem mehr dran sein könnte, als man denkt. Ich musste zu 4.4.20 zurückkehren, um diese aggregierten Zeitüberschreitungen unter allen Umständen vollständig zu stoppen. 4.7.x und 4.6.x hatten beide unter bestimmten Umständen bei mehreren gleichzeitigen Ausführungen falsche sehr schnelle Zeitüberschreitungen. Ich habe 4.5 übersprungen und bin direkt zu einer bekanntermaßen guten Version (4.4.20) zurückgekehrt, die wir in der Produktion verwenden, und das hat das Problem vollständig gelöst, aber ehrlich gesagt bin ich immer noch verwirrt über das, was passiert. Es tut mir leid, dass ich keine weiteren Daten hinzuzufügen habe, aber ich bin mir nicht sicher, ob es sich nur um ein Problem mit der Version des nativen Mongodb-Treibers handelt, den Mungo verwendet, oder ob mehr als ein beitragender Faktor am Werk ist .

Habe das gleiche Problem mit [email protected] und [email protected]. Timeouts sind wirklich komisch. Dieser ist ziemlich kurz (ungefähr 5 s) und sehr reproduzierbar, aber andere Abfragen dauern länger als 5 s und haben keine Zeitüberschreitung

Ich bin mir sicher, dass die Timeouts oft falsch sind. In einem Szenario, das ich mir angesehen habe, habe ich vier gleichzeitige Aggregat.exec-Vorgänge gestartet, die etwa 30 Sekunden dauern. Bei einem wurde das Timeout in 8 Sekunden überschritten, bei einem das Timeout in 20 Sekunden, aber die anderen beiden wurden normal in 30 Sekunden abgeschlossen. Das Wiederholen verursachte eine andere Timeout-Reihenfolge, aber immer ein ähnliches Ergebnis. Ich vermute, dass Timeouts fälschlicherweise für die falschen Verbindungen festgelegt oder nach Abschluss einer Operation nicht entfernt werden, sodass sie bei einer nachfolgenden Ausführung unerwartet ausgelöst werden. So etwas jedenfalls. Leider habe ich im Moment keine Zeit, dem nachzugehen.

[email protected] scheint die Timeouts für mich gelöst zu haben. @steve-p-com wie Sie vorschlagen, waren die Zeitüberschreitungen in 4.7.2 tatsächlich falsch und führten dazu, dass Fehlerereignisse auf der falschen Verbindung ausgegeben wurden, dies wurde von [email protected] gelöst und so sollte [email protected] funktionieren in deinem Fall einwandfrei. Hast du einen Test mit dieser Version gemacht?

Habe 4.7.9 oder 4.8.0 noch nicht getestet, vielleicht hat [email protected] eine Regression eingeführt, die das Problem erklären würde, das @flosky hat. Tritt diese Zeitüberschreitung auch bei [email protected] auf ?

Ich habe heute mit 4.8.1 erneut getestet und hatte keine Probleme mit unerwarteten Zeitüberschreitungen. Ich habe zuerst alle npm-Caches und Garn-Caches entfernt, dann node_modules gezapped und dann alles neu installiert. So weit, ist es gut.

Passiert bei mir auch mit 4.8.1. Ich habe viele Versionen von Mongoose und MongoDB zurückgesetzt und bekomme das Problem ständig.

@thenitai hast du mehr Kontext / können wir sehen, wie du deine MongoDB-Verbindung eingerichtet hast?

@varunjayaraman Ich habe festgestellt, dass unser Domain-Fehlercode den Fehler abfängt und somit unsere App neu startet. Das Problem ist jedoch immer noch da.

Nicht ganz sicher, was Sie bei der Einrichtung unserer Verbindung sehen müssen. Meinst du die Anschlussmöglichkeiten? Wenn ja, sind sie:

var dbOptions = {
            db: { native_parser: true },
            server: {
                auto_reconnect: true,
                socketOptions: {
                    keepAlive: 1, 
                    connectTimeoutMS: 300000,
                    socketTimeoutMS: 300000
                }
            }
        };

Ich habe auch das gleiche Problem. auch mit der neuesten Version v4.8.4

hab gerade das prob gefunden. In meinem Fall liegt es daran, dass die Speicherauslastung des Servers zu hoch ist (immer 95% ~ 99%), nach Erhöhung des Speichers kein Problem mehr.

Ich sehe dieses Problem auch auf meinem Server mit Mongoose 4.7.7 , MongoDB 3.4.1 und Node 4.7.2 . Wenn die Speicherauslastung auf meinem Server hoch ist, scheinen Zeitüberschreitungen zufällig in Reihe aufzutreten:

CosWebsite-27 MongoError: connection 42 to 127.0.0.1:27017 timed out
CosWebsite-27     at Function.MongoError.create (/home/cos/cos/node_modules/mongodb/node_modules/mongodb-core/lib/error.js:29:11)
CosWebsite-27     at Socket.<anonymous> (/home/cos/cos/node_modules/mongodb/node_modules/mongodb-core/lib/connection/connection.js:186:20)
CosWebsite-27     at Socket.g (events.js:260:16)
CosWebsite-27     at emitNone (events.js:67:13)
CosWebsite-27     at Socket.emit (events.js:166:7)
CosWebsite-27     at Socket.wrapped (/home/cos/cos/node_modules/newrelic/lib/transaction/tracer/index.js:183:28)
CosWebsite-27     at Socket.wrappedEmit [as emit] (/home/cos/cos/node_modules/newrelic/lib/transaction/tracer/index.js:220:46)
CosWebsite-27     at Socket._onTimeout (net.js:333:8)
CosWebsite-27     at _runOnTimeout (timers.js:537:11)
CosWebsite-27     at _makeTimerTimeout (timers.js:528:3)
CosWebsite-27     at Timer.unrefTimeout (timers.js:597:5)
... times 6
CosWebsite-27 GET /clans/compas-c-r-98QP9J2G/members 500 10569.300 ms - 9893
CosWebsite-27 GET /players/1000-99JQVQ9VU 500 12388.484 ms - 9849
CosWebsite-27 GET /players/R0YUPPRR/profile 500 8204.622 ms - 9857
CosWebsite-27 GET /players/UG8YJUJY/profile 500 4622.819 ms - 9857
CosWebsite-27 GET /clans/next-state-P8RYGQYV 500 11526.859 ms - 9861
CosWebsite-27 GET /clans/YY2CCUVV 500 6755.380 ms - 9817

Wie Sie den Anfragen entnehmen können, dauerte keine der Anfragen länger als 12 Sekunden. Mein Mungo-Connector ist folgendermaßen eingerichtet:

const mongoDB = {
    uri: "mongodb://127.0.0.1:27017/XXX",
    options: {
        host: '127.0.0.1',
        port: '27017',
        database: "XXX",
        compression: false,
        server: {
            poolSize: 5,
            auto_reconnect: true,
            socketOptions: {
                socketTimeoutMS: 0,
                connectTimeoutMS: 0
            }
        },
        promiseLibrary: Promise
    }
};

Irgendeine Idee, was falsch laufen könnte?

@adrienbaron Ich auch!!!
bitte helft mir jemand.

Hat jemand einen Fehlerbericht an die Entwickler des nativen Mongo-Treibers gesendet?

besteht dieses Problem in 4.9.1 noch?

Ja, Problem besteht weiterhin in 4.9.1....

[email protected]
[email protected]
[email protected]

Hatte heute nach dem Update auf die neueste Mungo-Version das gleiche Problem, als ich auf 4.7.1 zurückgestuft habe und alles funktioniert perfekt!

Das Problem ist seit einiger Zeit ungelöst.
Was sollten wir tun, um dies zu beheben?
Irgendwann würde ich gerne auf die neuere Version updaten, aber das geht erst, wenn das behoben ist.

Ich habe Mongoose vor etwa einem Monat von 4.4.17 auf 4.7.9 aktualisiert. Seitdem ist ein täglicher Cronjob jetzt dreimal fehlgeschlagen, immer mit einem Mongo-Connect-Timeout-Fehler.

Ich werde zu Mongoose 4.7.1 wechseln und sehen, ob dies hilft.

edit: die fehlermeldung

2017-04-19 03:09:23: You have triggered an unhandledRejection, you may have forgotten to catch a Promise rejection:
MongoError: connection 261 to localhost:27017 timed out
    at Function.MongoError.create (/var/www/someproject/node_modules/mongodb-core/lib/error.js:29:11)
    at Socket.<anonymous> (/var/www/someproject/node_modules/mongodb-core/lib/connection/connection.js:186:20)
    at Socket.g (events.js:286:16)
    at emitNone (events.js:86:13)
    at Socket.emit (events.js:185:7)
    at Socket._onTimeout (net.js:333:8)
    at tryOnTimeout (timers.js:224:11)
    at Timer.listOnTimeout (timers.js:198:5)

@centigrade-thomas-becker Ich hatte das gleiche Problem für mehr als einen Monat in der Produktion, ich bin gestern auf 4.7.1 zurückgekehrt, keine Probleme mehr!

Das gleiche Problem tritt bei 4.7.7 auf

Mit Mongo 4.7.1 gibt es weniger Probleme als mit 4.7.9, aber ich bekomme immer noch die gelegentliche Fehlermeldung beim Speichern in die MongoDB:

2017-04-30 03:09:32: Error: connection timeout
    at .<anonymous> (/var/www/someproject/node_modules/mongoose/lib/drivers/node-mongodb-native/connection.js:168:17)
    at emitTwo (events.js:106:13)
    at emit (events.js:191:7)
    at listener (/var/www/someproject/node_modules/mongodb/lib/db.js:1791:14)
    at emitOne (events.js:96:13)
    at emit (events.js:188:7)
    at .<anonymous> (/var/www/someproject/node_modules/mongodb/lib/server.js:270:14)
    at g (events.js:286:16)
    at emitOne (events.js:96:13)
    at emit (events.js:188:7)
    at .<anonymous> (/var/www/someproject/node_modules/mongodb-core/lib/topologies/server.js:322:12)
    at emitOne (events.js:96:13)
    at emit (events.js:188:7)
    at .<anonymous> (/var/www/someproject/node_modules/mongodb-core/lib/connection/pool.js:271:12)
    at g (events.js:286:16)
    at emitTwo (events.js:106:13)
    at emit (events.js:191:7)
    at Socket.<anonymous> (/var/www/someproject/node_modules/mongodb-core/lib/connection/connection.js:175:10)
    at Socket.g (events.js:286:16)
    at emitNone (events.js:86:13)
    at Socket.emit (events.js:185:7)
    at Socket._onTimeout (net.js:333:8)
    at tryOnTimeout (timers.js:224:11)
    at Timer.listOnTimeout (timers.js:198:5)

Der Fehler tritt auf einer Linux-VM auf, auf der Ubuntu 15.04 ausgeführt wird

Auch hier mit:

├─┬ [email protected]
│ ├─┬ [email protected]
│ │ ├── [email protected]

Mongo-Version @ 3.2.11

auf AWS EC2.

Irgendwelche Updates/Workarounds? Hätte keepAlive: true einen positiven Effekt?

Ich bin mir nicht sicher, ob dies jemandem hilft, aber in unserem Fall haben wir festgestellt, dass wir unsere Timeout-Parameter ( socketTimeoutMS usw.) über options.server übergeben haben. Das war _falsch_! Wir verwenden ein Replikat-Set und als solches sollten unsere Optionen wie folgt sein:

In unserem Fall benötigte die Anwendung tatsächlich die Möglichkeit, sich entweder mit einem Replikat oder einem normalen Server zu verbinden, also haben wir Folgendes getan:

const serverOptions = {
  poolSize: 100,
  socketOptions: {
    socketTimeoutMS: 60000
  }
};

mongoose.createConnection(dbpath, {
  server: serverOptions,
  replset: serverOptions
});

Hoffe das hilft jemandem!

Hallo, alle miteinander,
Ich verwende mlab, um meine Datenbank zu hosten. Ich bekomme diesen Fehler
Mongo DB-Verbindungsfehler: {[MongoError: Verbindung 0 zu ds155841.mlab. com:xxxxx Zeitüberschreitung '}

@RemeAjayi Ich denke, das hat nichts mit diesem Ticket zu tun.
Sie sollten es versuchen / erstellen, nachdem Sie sich mit dem Problem befasst haben.

@ht2 du hast meinen Tag gerettet ❤️

Gibt es eine praktikable Lösung für das ursprüngliche Problem?

Falls es jemandem hilft, habe ich dieses Problem bei der Parallelisierung von 2 brutalen find() -Abfragen (unter Verwendung des Promise-Musters) festgestellt.

Drehen

Promise.all([
  col1.find({longQuery: true}),
  col2.find({longQuery: true})
])
.spread(function(result1, result2) {
  //stuff
});

in ein sequentielles Vorgehen

col1.find({longQuery: true})
.then(function(result1) {
  return Promise.all([
    result1,
    col2.find({longQuery: true})
  ]);
})
.spread(function(result1, result2) {
  //stuff
});

Hat funktioniert

@cyrilchapon dachte, es würde für mich funktionieren, aber Ihr sequentieller Ansatz hat mein Problem nicht gelöst :/

es ist intermittierend.. manchmal funktioniert es, manchmal geht es aus..

Warum diese stille Nähe?

Eine Fortsetzung meines vorherigen Kommentars https://github.com/Automattic/mongoose/issues/4789#issuecomment -298849907

Ich habe die problematische Datenbank von einer virtuellen Maschine in einen Docker-Container mit brandneuem Linux, nodeJS und mongoDB verschoben. Ich habe einen Stresstest erstellt, der nichts anderes tut, als die Datenbank den ganzen Tag zu kürzen und neu zu füllen. Ich habe festgestellt, dass etwa 1 von 6000 Testläufen zu einem Timeout-Fehler führt.

Ich hatte, glaube ich, die gleiche Erfahrung nach meinem letzten Kommentar, vergessen zu erwähnen.

Aber das Aktualisieren von node auf eine seiner neuesten Versionen zusammen mit all den anderen Deps hat anscheinend den Zweck erfüllt.

Jetzt, mit dem obigen Kommentar, glaube ich, dass es sich um einen Legacy-Fehler handelt

Ich hatte auch das gleiche Problem mit mongo 3.6.2 und mongoose 4.9.2
Ich habe es behoben, indem ich zusätzliche Verbindungsparameter übergeben habe

MONGO_URI=mongodb://user:[email protected]:27017/dbname?keepAlive=true&poolSize=30&autoReconnect=true&socketTimeoutMS=360000&connectTimeoutMS=360000

@mzahidriaz Vielen Dank, dass Ihre Lösungen für mich funktionieren, aber können Sie erklären oder auf einen Link verweisen, wie Sie diese Parameter ausgewählt haben, um dieses Problem zu lösen?

@MinhNguyen41092 Im Moment sind die einzigen Dokumente die MongoDB-Treiberdokumente http://mongodb.github.io/node-mongodb-native/3.1/api/MongoClient.html#connect . wir werden Details dazu zu http://mongoosejs.com/docs/connections.html hinzufügen

Für diejenigen, bei denen die intermittierenden Fehler auftreten, hatte ich diese auch auf Mongoose-4.13.11 mit Mongodb-2.2.35 Mongodb-Core-2.1.19 in einer bestimmten Umgebung. Verschiedene Abfragen an verschiedenen Stellen in unserer Testsuite, obwohl wir hauptsächlich einen bestimmten Teil unserer App getestet haben, der schwerere Abfragen hat und Dinge parallel IIRC macht, haben alle diese Fehlermeldung erhalten. Und die gesamte Testsuite benötigt nicht einmal 15 Sekunden, um ausgeführt zu werden, also hätte ich auf keinen Fall die eingebauten Standard-Timeouts von 30 Sekunden treffen sollen:

     MongoError: connection 0 to localhost:27017 timed out
      at Function.MongoError.create (node_modules/mongoose/node_modules/mongodb-core/lib/error.js:29:11)
      at Socket.<anonymous> (node_modules/mongoose/node_modules/mongodb-core/lib/connection/connection.js:200:20)
      at Socket._onTimeout (net.js:448:8)

Dies geschah nur auf unserem CI-Test-Build-Server. Ich konnte es auf meinem Entwicklungscomputer nicht reproduzieren.

(In meinem eigenen System (privates Repo, dies ist für meine eigene Referenz, falls ich das jemals wieder ausgraben muss) tritt dieser Fehler zumindest in den Build-Nummern 358, 356, 355, 352 auf).

Nach dem Einschalten von useMongoClient: true scheinen die Tests im CI-Umfeld bisher zuverlässig zu bestehen. Ich hatte drei erfolgreiche Läufe mit genau dieser Änderung, während viele vorherige sequenzielle Läufe aufgrund des seltsamen Zeitüberschreitungsfehlers fehlschlagen.

Ich denke, @thenitai @steve-p-com @adrienbaron erlebten auch die seltsamen falschen Timeouts. Ich denke, der Fehler ist euch passiert, bevor 4.11 herauskam, was sogar useMongoClient: true als Option brachte. Können Sie sagen, ob dies den Unterschied für Ihre Workloads ausgemacht hat?

[email protected]
[email protected]
[email protected]
Habe seit ein paar Tagen das gleiche Problem, 1,5M Fehler im Überrollbügel, womit kann das zusammenhängen? Wie lösen?
screen shot 2019-02-25 at 2 53 37 pm
screen shot 2019-02-25 at 2 54 01 pm
screen shot 2019-02-25 at 2 55 27 pm

@SergeyVatz siehe Antwort auf Ihre Frage unter #5376

War diese Seite hilfreich?
0 / 5 - 0 Bewertungen