Hi, in looking at our working set, it seems that our oplog is using 
quite a bit of memory. I'm using a tool called vmtouch to report how 
much virtual memory a given group of files are using, and the local.* 
collections are reported to use 25G of 75G of total memory on the 
machine. 
https://gist.github.com/1078669
Looking at our slow query log, I see a lot of slow oplog queries as well (interspersed with a bunch of other slow queries):
Tue Jul 12 14:50:44 [conn33191] getmore local.oplog.rs cid: 8663878456695398892 getMore: { ts: { $gte: new Date(5627045896706326720) } }  bytes:729155 nreturned:1696 11259ms
Is it normal to see this much memory usage? Also, in looking at the local.oplog.rs collection, I don't see an index on the "ts" key. I'm assuming this is intentional, but I'm wondering how that affects overall performance for such a large collection.
tmountain's gravatar image asked Jul 12 2011 at 12:00 in Mongodb-User by tmountain

5 Answers

What version are you using?
Scott Hernandez's gravatar image answered Jul 12 2011 at 21:51 by Scott Hernandez
1.8.2
On Jul 13, 12:44 am, Scott Hernandez wrote: > What version are you using? > > > > > > > > >
tmountain's gravatar image answered Jul 13 2011 at 07:11 by tmountain
When the secondaries send queries to read the oplog they send a special option (oplogReplay) which does a more efficient search (than doing a linear scan) for a capped collection with a ts (Date/Timestamp) field, specifically designed for the oplog use. If the date is very old it is reading from then it could still touch more data (in terms of files) but it will be much faster.
Scott Hernandez's gravatar image answered Jul 13 2011 at 07:30 by Scott Hernandez
25GB is vm size,not Physical memory
On Jul 13, 10:23 pm, Scott Hernandez wrote: > When the secondaries send queries to read the oplog they send a > special option (oplogReplay) which does a more efficient search (than > doing a linear scan) for a capped collection with a ts > (Date/Timestamp) field, specifically designed for the oplog use. If > the date is very old it is reading from then it could still touch more > data (in terms of files) but it will be much faster. > > > > > > >
axlfu's gravatar image answered Jul 13 2011 at 18:02 by axlfu
questions: - what is the oplog size in db.oplog.rs.stats(). It should use 5% of your total disk space. If you believe it is too large, you can try reducing it on command line (but requires special care once created). The bottom line is to be able to have a server down for a few days and still be able to catch up.
- based on the oplog size, it will reported as is in virtual size, but it does not mean it takes that much ram. The slow query you show is very slow indeed, is it always that bad? How often does it happen? If secondaries are close in time, they should only hit recent oplog pages which should be in RAM, hence fast.
AG
Antoine Girbal's gravatar image answered Aug 14 2011 at 21:47 by Antoine Girbal

Related Discussions