Uploaded image for project: 'Documentation'
  1. Documentation
  2. DOCS-3207

MMS Sizing Documentation Misleading

    • Type: Icon: Task Task
    • Resolution: Done
    • Priority: Icon: Critical - P2 Critical - P2
    • v1.3.4, mms-1.4
    • Affects Version/s: v1.3.4, mms-1.4
    • Component/s: Cloud Manager
    • Labels:
      None

      http://mms.mongodb.com/help-hosted/v1.4/management/tutorial/prepare-backing-mongodb-instances/

      The section describing blockstore sizing seems to be omitting key factors such as garbage collection and de-duplication. Also, the example seems to be assuming an insert only workload which is that if you are adding 8GB of oplog a day you are adding ~8GB of data.

      In particular the section that sparks the most confusion below is where the formula is introduced.

      "Using the four shard, 200GB per shard cluster example from above, also add 2GB/day of oplogs generated per shard or 8GB/day total across the cluster.

      If the longest stored snapshot has a one year retention period, the approximate amount of data in the blockstore will be 800GB + (8GB * 365 days) or 3720GB. If the data gets a 4:1 compression ratio, which is an average seen in the hosted MMS, the blockstore space required will actually be 930GB."

      This is calculating the approximate size of one snapshot, which is a somewhat useless metric because depending on deduplication values/number of snapshots this will vary. The statement below it that is correct seems to directly contradict it and doesn't tie in with the example or information provided above.

      "Based on looking at the MMS hosted service, a good rule of thumb is a replica set will take up 2x - 3x its size in the Blockstore."

      Can this section be clarified?

            Assignee:
            sam.kleinman Sam Kleinman (Inactive)
            Reporter:
            osmar.olivo Osmar Olivo
            Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

              Created:
              Updated:
              Resolved:
              9 years, 34 weeks, 6 days ago