Uploaded image for project: 'Core Server'
  1. Core Server
  2. SERVER-24384

Extremely slow writes on OSX with WiredTiger and constant collection/index creation+drop

    Details

    • Type: Bug
    • Status: Closed
    • Priority: Major - P3
    • Resolution: Duplicate
    • Affects Version/s: 3.2.6
    • Fix Version/s: None
    • Component/s: WiredTiger
    • Labels:
      None
    • Environment:
    • Operating System:
      ALL

      Description

      Default installation of MongoDB 3.2.6 via brew.

      Basic commands like creating an index or dropping a collection take a long time.

      2016-04-13T11:02:19.970-0400 I COMMAND  [conn30] command mongoid_collection_snapshot_test.custom_connection_snapshots command: insert { insert: "custom_connection_snapshots", documents: [ { _id: ObjectId('570e5f789b0b5842f3b5e516'), workspace_basename: "snapshot", _slugs: [ "snapshot" ], max_collection_snapshot_instances: 2, created_at: new Date(1460559739398) } ], ordered: true } ninserted:1 keyUpdates:0 writeConflicts:0 numYields:0 reslen:40 locks:{ Global: { acquireCount: { r: 2, w: 2 } }, Database: { acquireCount: { w: 1, W: 1 } }, Collection: { acquireCount: { w: 1, W: 1 } } } protocol:op_query 1128ms
      2016-04-13T11:04:37.898-0400 I COMMAND  [conn39] command gravity_test_imports.artist_similarity_indices.output.snapshot command: drop { drop: "artist_similarity_indices.output.snapshot" } keyUpdates:0 writeConflicts:0 numYields:0 reslen:125 locks:{ Global: { acquireCount: { r: 1, w: 1 } }, Database: { acquireCount: { W: 1 } } } protocol:op_query 1077ms
      

      Switching storage to mmapv1 resolves the problem.

      Disabling journaling doesn't help.

      Attached a log where there're a few restarts switching between different configurations and some test queries.

      1. mongo.log
        2.07 MB
        Daniel Doubrovkine

        Issue Links

          Activity

          Hide
          dblock Daniel Doubrovkine added a comment -

          This is a vanilla installation, no data, and clearing /usr/local/var/mongodb every time.

          Show
          dblock Daniel Doubrovkine added a comment - This is a vanilla installation, no data, and clearing /usr/local/var/mongodb every time.
          Hide
          ramon.fernandez Ramon Fernandez added a comment -

          Daniel Doubrovkine, what the log shows is the following in a loop:

          • lots of index creations
          • lots of collection drops

          WiredTiger uses one file per collection and one file per index, so in this workload your system is very busy creating and removing files, which would explain the timings you're seeing.

          MMAPv1 uses a file per database and all your collections and indexes seem to be on the same database, so file allocation and deletion is not an issue.

          I'm going to close this ticket as a duplicate of SERVER-17675, which you may want to vote for and follow for updates. If your testing represents your actual workload (i.e.: constant collection/index creation followed by drops) then I'd recommend you use MMAPv1.

          Regards,
          Ramón.

          Show
          ramon.fernandez Ramon Fernandez added a comment - Daniel Doubrovkine , what the log shows is the following in a loop: lots of index creations lots of collection drops WiredTiger uses one file per collection and one file per index, so in this workload your system is very busy creating and removing files, which would explain the timings you're seeing. MMAPv1 uses a file per database and all your collections and indexes seem to be on the same database, so file allocation and deletion is not an issue. I'm going to close this ticket as a duplicate of SERVER-17675 , which you may want to vote for and follow for updates. If your testing represents your actual workload (i.e.: constant collection/index creation followed by drops) then I'd recommend you use MMAPv1. Regards, Ramón.
          Hide
          dblock Daniel Doubrovkine added a comment -

          FWIW the big advantage of MongoDB is that it is (was) really cheap to bring up and tear down a database for every test, and that is what most Ruby developers using MongoDB do via libraries like database_cleaner. It's literally the default setup I've seen in just about any project.

          Show
          dblock Daniel Doubrovkine added a comment - FWIW the big advantage of MongoDB is that it is (was) really cheap to bring up and tear down a database for every test, and that is what most Ruby developers using MongoDB do via libraries like database_cleaner. It's literally the default setup I've seen in just about any project.
          Hide
          dblock Daniel Doubrovkine added a comment -

          Just to be clear, we don't always have control in development over configuration options of a database, for example in Travis-CI.

          Show
          dblock Daniel Doubrovkine added a comment - Just to be clear, we don't always have control in development over configuration options of a database, for example in Travis-CI.
          Hide
          pasette Dan Pasette added a comment -

          Daniel, have you tried using the ephemeralForTest storage engine? I wasn't sure if in your last comment you meant that you don't have control over the storage engine setting or not, but for local unit-testing against a standalone mongod server, this could be a good approach for you.

          Show
          pasette Dan Pasette added a comment - Daniel, have you tried using the ephemeralForTest storage engine? I wasn't sure if in your last comment you meant that you don't have control over the storage engine setting or not, but for local unit-testing against a standalone mongod server, this could be a good approach for you.

            People

            • Votes:
              0 Vote for this issue
              Watchers:
              8 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: