fixup: cleanup whitespace for linter
@@ -10,7 +10,7 @@ approvers:
- "@smarterclayton"
- "@deads"
creation-date: 2021-07-14
-last-updated: 2021-07-14
+last-updated: 2021-08-06
status: implementable
see-also:
@@ -70,7 +70,7 @@ MVCC poses a performance challenge for `bbolt` because the db can store many ver
versions can build up indefinitely and result in memory and disk performance issues. The solution is to regularly
compact the key space.
-compaction is essentially a delete action in `bbolt`, where the prevision versions of a keys value are pruned.
+Compaction is essentially a delete action in `bbolt`, where the prevision versions of a keys value are pruned.
`bbolt` organizes data on pages and when a page is no longer used as the result of a db mutation it is called a
free page and an accounting of all free pages are stored in a freelist for later reuse.
@@ -97,20 +97,21 @@ From these two fields we can conclude the total fragmented space on that etcd me
percentage of bytes of the total keyspace are over a defined threshold percentage. The controller will
utilize maintenance API again and issue a `DefragmentRequest` RPC.
-Defragmentation is I/O blocking thus important to only defrag a single etcd at a time. Additionally, to reduce
-the possibility of multiple leader elections we defragment the leader last. The amount of time that is required to
-defragment the store is directly related to the amount of free pages that exists. For this reason we feel it
-makes sense to continuously observe the clusters state and defrag frequently along the cadence of
-compaction resulting in shorter intervals of disruption by keeping the number of pages limited and the size of the
-database smaller.
+Defragmentation is I/O blocking thus important to only defrag a single etcd at a time. This is achieved by performing
+an MemberListRequest RPC which returns the cluster membership. The controller will then loop this list and explicitly
+defrag each member individually. Additionally, to reduce the possibility of multiple leader elections we defragment
+the leader last. The amount of time that is required to defragment the store is directly related to the amount of
+free pages that exists. For this reason we feel it makes sense to continuously observe the clusters state and defrag
+frequently along the cadence of compaction resulting in shorter intervals of disruption by keeping the number of
+pages limited and the size of the database smaller.
The criteria for defragmentation is defined as:
- Cluster must be observed as `HighlyAvailableTopologyMode`.
- The etcd cluster must report all members as healthy.
-- `minDefragBytes` this is a minimum database size in bytes before defragmentation should be considered.
+- `minDefragBytes` this is a minimum database size in bytes before defragmentation should be considered. `100 MB`.
- `maxFragmentedPercentage` this is a percentage of the store that is fragmented and would be reclaimed after
- defragmentation.
+ defragmentation. `45%`.
TODO show performance graphs.
