MongoErrors: Topology was destroyed (Nodebb unresponsive)


  • GNU/Linux

    Forum has suddenly started throwing following errors randomly. Stackoverflow suggests either mongo is trying to write when connection is not active or the reconnectInterval needs to be set. @PitaJ and @Julian-H-Lam anything you recommend?

    Nodebb version 1.6.1 on a 8GB droplet

        at nextFunction (/var/www/nodebb/node_modules/mongodb-core/lib/cursor.js:540:25)
        at Cursor.next [as _next] (/var/www/nodebb/node_modules/mongodb-core/lib/cursor.js:692:3)
        at fetchDocs (/var/www/nodebb/node_modules/mongodb/lib/cursor.js:856:10)
        at toArray (/var/www/nodebb/node_modules/mongodb/lib/cursor.js:883:3)
        at Cursor.toArray (/var/www/nodebb/node_modules/mongodb/lib/cursor.js:836:44)
        at Object.module.getObjects (/var/www/nodebb/src/database/mongo/hash.js:41:70)
        at async.waterfall.returnData (/var/www/nodebb/src/widgets/index.js:117:7)
        at nextTask (/var/www/nodebb/node_modules/async/dist/async.js:5297:14)
        at Object.waterfall (/var/www/nodebb/node_modules/async/dist/async.js:5307:5)
        at Object.widgets.getWidgetDataForTemplates (/var/www/nodebb/src/widgets/index.js:115:8)
        at async.waterfall.widgetsByLocation (/var/www/nodebb/src/widgets/index.js:22:12)
        at nextTask (/var/www/nodebb/node_modules/async/dist/async.js:5297:14)
        at Object.waterfall (/var/www/nodebb/node_modules/async/dist/async.js:5307:5)
        at Object.widgets.render (/var/www/nodebb/src/widgets/index.js:20:8)
        at async.waterfall.options.widgets (/var/www/nodebb/src/middleware/render.js:53:14)
        at nextTask (/var/www/nodebb/node_modules/async/dist/async.js:5297:14)
    MongoError: server instance pool was destroyed
        at Function.MongoError.create (/var/www/nodebb/node_modules/mongodb-core/lib/error.js:29:11)
        at basicWriteValidations (/var/www/nodebb/node_modules/mongodb-core/lib/topologies/server.js:462:51)
        at Server.update (/var/www/nodebb/node_modules/mongodb-core/lib/topologies/server.js:581:16)
        at Server.update (/var/www/nodebb/node_modules/mongodb/lib/server.js:397:17)
        at updateDocuments (/var/www/nodebb/node_modules/mongodb/lib/collection.js:1055:19)
        at Collection.update (/var/www/nodebb/node_modules/mongodb/lib/collection.js:1094:44)
        at Collection.tryCatcher (/var/www/nodebb/node_modules/bluebird/js/release/util.js:16:23)
        at Collection.ret [as updateAsync] (eval at makeNodePromisifiedEval (/var/www/nodebb/node_modules/bluebird/js/release/promisify.js:184:12), <anonymous>:13:39)
        at collectionReady.then.collection (/var/www/nodebb/node_modules/connect-mongo/src/index.js:248:48)
        at tryCatcher (/var/www/nodebb/node_modules/bluebird/js/release/util.js:16:23)
        at Promise._settlePromiseFromHandler (/var/www/nodebb/node_modules/bluebird/js/release/promise.js:512:31)
        at Promise._settlePromise (/var/www/nodebb/node_modules/bluebird/js/release/promise.js:569:18)
        at Promise._settlePromiseCtx (/var/www/nodebb/node_modules/bluebird/js/release/promise.js:606:10)
        at Async._drainQueue (/var/www/nodebb/node_modules/bluebird/js/release/async.js:138:12)
        at Async._drainQueues (/var/www/nodebb/node_modules/bluebird/js/release/async.js:143:10)
        at Immediate.Async.drainQueues (/var/www/nodebb/node_modules/bluebird/js/release/async.js:17:14) ```

  • GNU/Linux

    0_1517816300458_Screen Shot 2018-02-05 at 12.25.24 PM.png


  • Gamers

    What can cause high RAM usage of server ?



  • Is it possible that we have same problem?
    https://community.nodebb.org/topic/11856/problem-with-admin-statistics-graph/12
    Same "gap" in that graph until i reset nodebb.

    Is it mongodb eating too much RAM?


  • GNU/Linux

    @sosojni No, i don't think so. The gap in my graph is because nothing was served to the user as mongo was crashing. On further debugging and monitoring logs of DO droplet, it seems the RAM is the issue here. We saw heavy traffic during the weekend. I've bumped up the specs to 16GB to see if it will be sufficient. However i'm still looking for a solution that will make sure we catch/handle this so that mongo doesn't crash.


  • Global Moderator

    You might try updating mongo. There's also a mongo config setting that can easily in the database using too much memory and being killed by the kernel, you might check that out. @baris can probably help you more there though.


  • Admin

    @fais3000 What version of mongodb? Unless you have alot of data 8gb should be more than enough. Check out this section https://docs.mongodb.com/manual/core/wiredtiger/#memory-use.


  • GNU/Linux

    @baris Mongo v3.2.13 and DB is using about 5gb


  • Admin

    If you are not using wiredtiger already I suggest switching to it since it has compression and reduces index sizes quite a bit.


  • GNU/Linux

    @baris Nope, we're not. I'll check it out.


 

| |