================================
The present version of the MDS is single-threaded and CPU-bound for most
-activities, including responding to client requests. Even so, an MDS under the
-most aggressive client loads still uses about 2 to 3 CPU cores. This is due to
-the other miscellaneous upkeep threads working in tandem.
+activities, including responding to client requests. An MDS under the most
+aggressive client loads uses about 2 to 3 CPU cores. This is due to the other
+miscellaneous upkeep threads working in tandem.
Even so, it is recommended that an MDS server be well provisioned with an
advanced CPU with sufficient cores. Development is on-going to make better use
The other dimension to MDS performance is the available RAM for caching. The
MDS necessarily manages a distributed and cooperative metadata cache among all
clients and other active MDSs. Therefore it is essential to provide the MDS
-with sufficient RAM to enable faster metadata access and mutation.
+with sufficient RAM to enable faster metadata access and mutation. The default
+MDS cache size (see also :doc:`/cephfs/cache-size-limits`) is 4GB. It is
+recommended to provision at least 8GB of RAM for the MDS to support this cache
+size.
Generally, an MDS serving a large cluster of clients (1000 or more) will use at
-least 64GB of cache (see also :doc:`/cephfs/cache-size-limits`). An MDS with a larger
-cache is not well explored in the largest known community clusters; there may
-be diminishing returns where management of such a large cache negatively
-impacts performance in surprising ways. It would be best to do analysis with
-expected workloads to determine if provisioning more RAM is worthwhile.
+least 64GB of cache. An MDS with a larger cache is not well explored in the
+largest known community clusters; there may be diminishing returns where
+management of such a large cache negatively impacts performance in surprising
+ways. It would be best to do analysis with expected workloads to determine if
+provisioning more RAM is worthwhile.
In a bare-metal cluster, the best practice is to over-provision hardware for
the MDS server. Even if a single MDS daemon is unable to fully utilize the
.set_flag(Option::FLAG_RUNTIME),
Option("mds_cache_memory_limit", Option::TYPE_SIZE, Option::LEVEL_BASIC)
- .set_default(1*(1LL<<30))
+ .set_default(4_G)
.set_description("target maximum memory usage of MDS cache")
.set_flag(Option::FLAG_RUNTIME)
.set_long_description("This sets a target maximum memory usage of the MDS cache and is the primary tunable to limit the MDS memory usage. The MDS will try to stay under a reservation of this limit (by default 95%; 1 - mds_cache_reservation) by trimming unused metadata in its cache and recalling cached items in the client caches. It is possible for the MDS to exceed this limit due to slow recall from clients. The mds_health_cache_threshold (150%) sets a cache full threshold for when the MDS signals a cluster health warning."),