MongoDB setup on NUMA machine

The plus sides:

• you would be able to have concurrent writes, provided that the data was hashed to different shards. MongoDB locks the entire database on that instance when doing a write, so even a non-sharded replica set can only write one thing at a time
• it's a good way of learning sharding/replica sets/admin, but if you just want to do that you can achieve this with less instances
• replication would be very quick :)

The downsides:

• you would need a powerful machine (multiple CPUs but also as much memory as possible, and quick disks) to really benefit from the performance - Mongo craves RAM! For optimal performance your total index size should fit into RAM, which means if you have 2 gigs of index per shard, you would need 5 * 3 * 2 = 30 gigs of ram, plus the memory for the OS etc as well
• you may not benefit much from the slaveOK query option
• you would have no protection against hardware failure - if the box goes, all your shards and your replica sets go

dmesg | grep -i numa

This will tell you if your server is numa enabled.

numactl -s will tell you if numa is enabled on a per process basis.

If production nodes shouldn't use numa, then you probably shouldn't. I would suggest rather than relying on turning it off via numactl, you can and probably should usually turn numa off completely via BIOS.

I've seen numa completely crap up server performance before with other Java applications when I was doing some performance tests. To see it screw up a C/C++ app like Mongo is surprising!

I'd like to disclose that your original issue, is different from your question. Changing the numa settings might not solve your 100% cpu issue. You might find after eliminating the numa card, you still have 100% cpu usage, which will require more diagnostics to get to the root of the problem (separate thread maybe).