WiredTiger memory cache size configuration

[Joe Waller]

Hi folks,

Some questions on wiredtiger configuratiion

1. I have a dedicated server running mongodb with wired tiger. Is the recommended config to use the default of 50% of my memory for wired tiger or should I move it up to 80% (because I want all the memory to be used by mongodb) ? Can the mongodb team share some documentation on what uses this cache and what allocates memory outside this cache so we can make more informed decisions.

2. Is there a way to tell what % of the cache is being used by a particular collection? I looked at db.collection.stats() and it provides some data on the pages that were read into cache 

3. Is there a recommended replacement for fsync? We currently use disk snapshots for backup and want to make sure we capture all the latest changes. With wiredtiger I am noticing that the disk snapshots don't capture the latest change. Here is an example workflow

a. Insert new document into a collection

b. wait 5 secs and then snapshot the disk.

c. when you restore from this disk snapshot I notice a lot of times the inserted document is not present.

With journalling enabled should this document have been journalled within 100ms? 

thanks,

Joe

[Joe Waller]

One more question :)

4. What is the relevance of compact and repair operations with Wiredtiger? Does WT based storage get fragmented which is fixed by compact/repair?

[Joe Waller]

Can someone from the MongoDB/wiredtiger team help clarify the wiredtiger questions I have below?

On Sunday, May 3, 2015 at 12:25:59 PM UTC-7, Joe Waller wrote:

[Asya Kamsky]

Joe:

If you run mongostat you will see what percentage of the cache is being used - the dirty %'s shows how much data there will be to write out to disk during checkpoints.   This means that you might not want to raise the cache - if your cache is really big and you usually dirty most of it by the time checkpoints come around, the checkpoints would take longer, and then when they write, they may end up waiting for disk IO since memory not used for cache will end up being used by the OS for file system cache.

The less file system cache the more synchronous the IO during checkpoints.  This may manifest in slowdown in throughput during latter part of the checkpoint.  We're working on improving that, but I wouldn't go crazy taking all the RAM for mongod at this point.

I'm not aware of a way to tell how many pages are being used for a particular collection.

Can you clarify what exactly you are snapshotting?  It doesn't seem like you are talking about backups, are you?   If you are, then you should be doing snapshots on the secondary, and best thing would be to shut down mongod, take the file system snapshot and start up mongod again.   That's the safest way, as it makes sure there is nothing changing in the file at the time of the snapshot.

Compact in WT will rewrite the collection contiguously - it shouldn't be necessary as WT reuses pages as it frees them up.  If you notice that you shrank the space usage a lot by running compact, it's a false saving, unless you are never going to update any documents in that collection again.  Otherwise as soon as you do update them, new pages will be allocated to rewrite the changed pages, and old pages will be reused.

Asya

--
You received this message because you are subscribed to the Google Groups "mongodb-user"
group.
 
For other MongoDB technical support options, see: http://www.mongodb.org/about/support/.
---
You received this message because you are subscribed to the Google Groups "mongodb-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mongodb-user...@googlegroups.com.
To post to this group, send email to mongod...@googlegroups.com.
Visit this group at http://groups.google.com/group/mongodb-user.
To view this discussion on the web visit https://groups.google.com/d/msgid/mongodb-user/01bb766a-60a6-4175-be24-36001ab3097a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

MongoDB World is back! June 1-2 in NYC. Use code ASYA for 25% off!

[Joe Waller]

Thanks Asya. 

Is the default checkpoint interval in WT 60 seconds like in the MMAP engine? If we have a read heavy workload would it make sense to allocate more memory to the cache? Also are indexes stored in the memory cache or outside?

On Sunday, May 3, 2015 at 12:25:59 PM UTC-7, Joe Waller wrote:

[Asya Kamsky]

Indexes are in the cache, just like everything else that WT needs to read/write, however, indexes are stored in the cache compressed, same as on disk (prefix compression) so they are much smaller than in previous versions.

You can certainly try larger cache and see how/if it affects the performance.   You don't even need to restart the server, you can change the cache size with an admin command:

> db.adminCommand( { "setParameter": 1, "wiredTigerEngineRuntimeConfig": "cache_size=50G"})

The above would set cache size to 50Gbs.   Just fill in your own number and watch it go up (or down).

Be careful, though - mongod may use more memory than just the cache (remember, the cache is for WT storage engine, mongod itself may need RAM for things like in memory sorts, aggregations, connection overhead).   if you set the cache size too large and it gets filled and mongod needs some extra RAM, most likely your mongod process will get killed by OOM killer when there's not enough RAM to go on.

Asya

--
You received this message because you are subscribed to the Google Groups "mongodb-user"
group.
 
For other MongoDB technical support options, see: http://www.mongodb.org/about/support/.
---
You received this message because you are subscribed to the Google Groups "mongodb-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mongodb-user...@googlegroups.com.
To post to this group, send email to mongod...@googlegroups.com.
Visit this group at http://groups.google.com/group/mongodb-user.

To view this discussion on the web visit https://groups.google.com/d/msgid/mongodb-user/f1e23de7-c660-4e0e-8e23-86736447c74a%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.