Documentation Changes
Explain that "Best config server performance can be achieved when they are placed on dedicated servers with enough RAM to hold their data files fully in memory and with dedicated storage". Likely belongs on Production Notes.
Description
Config servers are the central point for metadata storage and retrieval in sharded clusters. Performance of the cluster (e.g. system operations and user queries) might be negatively affected if config servers are not able to provide timely responses.
First, mongoS services frequently query config servers to retrieve sharded collection metadata and/or its changes. Config servers are queried in order, starting with the first one in the configdb string. If the first one doesn't respond within a fixed time interval (30 seconds, I think), the second one will be queried, etc. Thus all three config servers should have their data available in RAM for fast responses. Config databases rarely reach more than few GBs, but if your config server shares RAM with other memory-greedy processes (e.g. an active shard node), config data might still be paged out.
Internally, as part of many metadata change operations, (e.g. splits) mongoS executes the fsync call on all three config servers to confirm that they are up and functional. Since the fsync call instructs the server to flush all data to disk and waits for the flush to complete, its latency fully depend on disk IO that backs up the config server dbpath. If your config servers are sharing disk(s) with other services, their IO might be starved.
Best config server performance can be achieved when they are placed on dedicated servers with enough RAM to hold their data files fully in memory and with dedicated storage.
|