MONGO DEPLOYMENT

MONGO DEPLOYMENT

 SrinivasMaddali

Mongo performance depends on
RAM
Mongo requires to be able to read from RAM the data. The RAM provision should be able to satisfy this for better performance. Mongo requires lot of memory. Depending upon the concurrency and data set generally accessed, memory is to be decided for the mongo instances.

Storage
It is suggested to use Solid State Drive (SSD). Spinning Drive is not fast enough I/O of large data sets. CPU requires to spin and spin. Where SSD deployment is not preferred there Spinning Disks (may be used) RAID configurations suggested RAID10. Never use RAID 5 it slows down the and seek latency is more and more.

CPU
10000 queries per second push the CPU. As such mongo is light on CPU. When choosing between speed and number of cores, go with the speed. Mongo DB is better at taking advantage of more cycles on a single processor than increased parallelization.

Choosing the OS
64 bit Linux is the OS mongo DB runs64 bit windows is also well supported. Mongo DB works with little-endian architectures. Server must run on little-endian architecture. Drivers can work with little-endian and big-endian architectures.

Swap Space
Mongo processes should not be on swap space. If the application is managing to make use of swap space, then it is time to revisit application or reducing load on swapping server.

File system (FS)
For Linux the ext4 file system or XFS are recommended for the data volumes. It is nice to have a file system that can do FS snapshots for backups, but that is a matter of performance. Ext3 is not recommended. Ext3 takes long time to pre-allocate the data files. MongoDB has to regularly allocate 2 GB data files, and at that time it freezes. Windows NTFS and FAT are fine.

Virtualization - When VMs are used to setup MongoDB
then
01. Switch off Memory Overcommitting.
02. Mystery memory: when there is 100 GB memory available VM allows only 60GB to be used. Do not think that there is 100GB and try to get 100GB data sets
03. Handling Network Disk IO issues – not recommended – as performance is not consistent.
04. Using non-networked disks. This is part of Amazon vocabulary – ephemeral drives are to be used with care.
05. Turning off Non Uniform Memory Address (NUMA)
06. Setup readahead
07. Disable huge-pages
08. File descriptors should be set at 20000 or more
09. Network:
a. A client must be able to connect to MongoDB
b. Mongo must be able to connect to SHARDS and config servers
c. A SHARD must be able to connect to other SHARDS
10. Synchronizing Clocks
11. OOM Killer out of memory is a killer. This happens during index build when memory is put to strain.