wbtiger
/
foundationdb
mirror of https://github.com/apple/foundationdb.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

Addressed more review comments

This commit is contained in:
tclinken 2020-01-11 16:07:36 -08:00
parent 3eb428d874
commit b18f06b52a
1 changed files with 6 additions and 6 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

12
documentation/sphinx/source/administration.rst
View File

@ -494,12 +494,12 @@ Machine-readable status
The status command can provide a complete summary of statistics about the cluster and the database with the ``json`` argument. Full documentation for ``status json`` output can be found :doc:`here <mr-status>`.
From the output of ``status json``, operators can find useful health metrics to determine whether or not their cluster is hitting performance limits.
====================== =========================================================== ===================================================
Ratekeeper limit ``cluster.qos.transactions_per_second_limit`` The number of read versions per second that the cluster can give out. A low ratekeeper limit indicates that the cluster performance is limited in some way. The reason for a low ratekeeper limit can be found at ``cluster.qos.performance_limited_by``. ``cluster.qos.released_transactions_per_second`` describes the number of read versions given out per second, and can be used to tell how close the ratekeeper is to throttling.
Storage queue size ``cluster.qos.worst_queue_bytes_storage_server`` The maximum size in bytes of a storage queue. Each storage server has mutations that have not yet been made durable, stored in the storage queue. If this queue gets too large for any storage server, the ratekeeper will increase throttling. Storage servers with large storage queues have fallen behind and will likely struggle to serve read requests.
Durable version lag ``cluster.qos.worst_durability_lag_storage_server`` The ``versions`` field contains the maximum number of versions in a storage queue. Ideally, this should be near 5 million. The ``seconds`` field contains the maximum number of seconds of non-durable data in a storage queue. Ideally, this should be near 5 seconds. If a storage server is overwhelmed, the durability lag could rise, causing performance issues. The sec
Transaction log queue ``cluster.qos.worst_queue_bytes_log_server`` The maximum size in bytes of the mutations stored on a transaction log that have not yet been popped by storage servers.
====================== =========================================================== ===================================================
====================== ==============================================================================================================
Ratekeeper limit ``cluster.qos.transactions_per_second_limit`` contains the number of read versions per second that the cluster can give out. A low ratekeeper limit indicates that the cluster performance is limited in some way. The reason for a low ratekeeper limit can be found at ``cluster.qos.performance_limited_by``. ``cluster.qos.released_transactions_per_second`` describes the number of read versions given out per second, and can be used to tell how close the ratekeeper is to throttling.
Storage queue size ``cluster.qos.worst_queue_bytes_storage_server`` contains the maximum size in bytes of a storage queue. Each storage server has mutations that have not yet been made durable, stored in its storage queue. If this value gets too large, it indicates a storage server is falling behind. A large storage queue will cause the ratekeeper to increase throttling. However, depending on the configuration, the ratekeeper can ignore the worst storage queue from one fault domain. Thus, ratekeeper uses ``cluster.qos.limiting_queue_bytes_storage_server`` to determine the throttling level.
Durable version lag ``cluster.qos.worst_durability_lag_storage_server`` contains information about the worst storage server durability lag. The ``versions`` subfield contains the maximum number of versions in a storage queue. Ideally, this should be near 5 million. The ``seconds`` subfield contains the maximum number of seconds of non-durable data in a storage queue. Ideally, this should be near 5 seconds. If a storage server is overwhelmed, the durability lag could rise, causing performance issues.
Transaction log queue ``cluster.qos.worst_queue_bytes_log_server`` contains the maximum size in bytes of the mutations stored on a transaction log that have not yet been popped by storage servers. A large transaction log queue size can potentially cause the ratekeeper to increase throttling.
====================== ==============================================================================================================
.. _administration_fdbmonitor: