Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

We have large multi-gigabyte data sets on which we run very complex queries, for example

{ $or: [ { id: 30000001, ... }, { id: 30000005, ... }, ..., { id: 30001005, ... } ] }

It seems that CPU is actually a bottleneck at this point, so I'd be advantageous to be able to run multiple mongod instances on the same set of database files.

We've considered using replica sets to this end, but would prefer to not require the extra disk space simply for CPU reasons.

share|improve this question
That query looks like it came straight out of . It's almost certainly time to rethink your design, if you're coming up with things like that. – Michael Hampton Dec 9 '12 at 18:09
The example query is part of a complex join operation over a number of sets (It's not even the worst one, some involve $lt/$gt operations within the $or !). This might appear to be a slightly OTT way of doing that, but this seems to be the only way to do it correctly with our system. – 9point6 Dec 9 '12 at 18:30
up vote 0 down vote accepted

No, this is not possible, you cannot run multiple instances using the same files at present - the key piece of functionality you would need (managing which instance has the ability to write to a file) does not exist. I don't think this is on the list of feature requests either (I could not find it), and given the number of potential issues I can think of allowing this to be done, it would seem like a long shot in terms of a request, but you are welcome to request it.

The $or query example you list (and you suggest you have more complicated ones) is going to run multiple queries in parallel, and by the looks of it you then have essentially nested logical $ors by listing multiple _id in each clause. With multiple scans for each of the clauses in the $or, even with a covered index query that is still going to be a large number of scans of the index when that array is large.

If you are not using covered indexes (look for indexOnly to be true in your explains), then that would mean a lot of document scanning as well and unless your entire data set fits into memory, that is going to mean a lot page faulting.

Since you already state that this is the "only way" to do this on your system (I think a schema review would also be a good idea), then currently, if you are running into CPU issues on a single host, then replication or sharding are your two options to scale out horizontally. I would also make sure that the CPU is in user land, not system (the easiest way to do this is install MMS with munin-node and track user (usually mongod if its a dedicated system) versus system CPU over time.

Before you do that though, make sure you are running on 2.2 - one of the major improvements in 2.2 was the switch to TCMalloc - I cannot be certain, because malloc issues can be hard to diagnose/define at the best of times, but if you are running 2.0, TCMalloc may help you here.

share|improve this answer
Thanks for the useful insights. I'll accept this as the answer. – 9point6 Dec 10 '12 at 16:02

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.