New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
db: avoid acquiring DB.mu in the commit pipeline #2680
Comments
jbowens
added a commit
to jbowens/pebble
that referenced
this issue
May 9, 2024
Previously, DB.commitWrite would acquire the DB.mu before calling makeRoomForWrite to ensure the current memtable had sufficient space for the batch's contents. When DB.commitWrite is called, the caller already holds the commit pipeline's mutex providing mutual exclusion with other committers and, crucially, preventing the concurrent rotation of the memtable. This commit adjusts DB.commitWrite to attempt reserving space in the current mutable memtable before acquiring DB.mu. In the common case, if successful, there is no need to acquire DB.mu. If unsuccessful, the committer falls back to acuqiring DB.mu and rotating the memtable through calling makeRoomForWrite. Close cockroachdb#2680.
jbowens
added a commit
to jbowens/pebble
that referenced
this issue
May 9, 2024
Previously, DB.commitWrite would acquire the DB.mu before calling makeRoomForWrite to ensure the current memtable had sufficient space for the batch's contents. When DB.commitWrite is called, the caller already holds the commit pipeline's mutex providing mutual exclusion with other committers and, crucially, preventing the concurrent rotation of the memtable. This commit adjusts DB.commitWrite to attempt reserving space in the current mutable memtable before acquiring DB.mu. In the common case, if successful, there is no need to acquire DB.mu. If unsuccessful, the committer falls back to acuqiring DB.mu and rotating the memtable through calling makeRoomForWrite. Close cockroachdb#2680.
jbowens
added a commit
to jbowens/pebble
that referenced
this issue
May 12, 2024
Previously, DB.commitWrite would acquire the DB.mu before calling makeRoomForWrite to ensure the current memtable had sufficient space for the batch's contents. When DB.commitWrite is called, the caller already holds the commit pipeline's mutex providing mutual exclusion with other committers and, crucially, preventing the concurrent rotation of the memtable. This commit adjusts DB.commitWrite to attempt reserving space in the current mutable memtable before acquiring DB.mu. In the common case, if successful, there is no need to acquire DB.mu. If unsuccessful, the committer falls back to acuqiring DB.mu and rotating the memtable through calling makeRoomForWrite. Close cockroachdb#2680.
jbowens
added a commit
to jbowens/pebble
that referenced
this issue
May 12, 2024
Previously, DB.commitWrite would acquire the DB.mu before calling makeRoomForWrite to ensure the current memtable had sufficient space for the batch's contents. When DB.commitWrite is called, the caller already holds the commit pipeline's mutex providing mutual exclusion with other committers and, crucially, preventing the concurrent rotation of the memtable. This commit adjusts DB.commitWrite to attempt reserving space in the current mutable memtable before acquiring DB.mu. In the common case, if successful, there is no need to acquire DB.mu. If unsuccessful, the committer falls back to acuqiring DB.mu and rotating the memtable through calling makeRoomForWrite. Close cockroachdb#2680.
jbowens
added a commit
to jbowens/pebble
that referenced
this issue
May 13, 2024
Previously, DB.commitWrite would acquire the DB.mu before calling makeRoomForWrite to ensure the current memtable had sufficient space for the batch's contents. When DB.commitWrite is called, the caller already holds the commit pipeline's mutex providing mutual exclusion with other committers and, crucially, preventing the concurrent rotation of the memtable. This commit adjusts DB.commitWrite to attempt reserving space in the current mutable memtable before acquiring DB.mu. In the common case, if successful, there is no need to acquire DB.mu. If unsuccessful, the committer falls back to acuqiring DB.mu and rotating the memtable through calling makeRoomForWrite. Close cockroachdb#2680.
jbowens
added a commit
that referenced
this issue
May 13, 2024
Previously, DB.commitWrite would acquire the DB.mu before calling makeRoomForWrite to ensure the current memtable had sufficient space for the batch's contents. When DB.commitWrite is called, the caller already holds the commit pipeline's mutex providing mutual exclusion with other committers and, crucially, preventing the concurrent rotation of the memtable. This commit adjusts DB.commitWrite to attempt reserving space in the current mutable memtable before acquiring DB.mu. In the common case, if successful, there is no need to acquire DB.mu. If unsuccessful, the committer falls back to acuqiring DB.mu and rotating the memtable through calling makeRoomForWrite. Close #2680.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Currently during batch
prepare
, a batch acquires the commit mutex. It then allocates sequence numbers for its keys. Then, incommitWrite
it locks the global database mutex in order to grab the current mutable memtable:This can contribute to high tail latencies (#2646). All batch commits become stalled, waiting for the goroutine holding
DB.mu
to complete.We could avoid this mutex acquisition in the common case where there's room in the existing memtable for the current batch. The committing goroutine can load the mutable memtable through an atomic load. Memtable reservation can also be performed through lock-free operations. If reservation finds that there is not sufficient space in the memtable, it falls back into acquiring
d.mu
and enteringmakeRoomForWrite
. There are instances where we rotate the memtable before it's full. In these instances,makeRoomForWrite
can set the mutable memtable tonil
, reflecting that a rotation is in progress and incoming writers must queue inmakeRoomForWrite
. A version of this was hacked together in ef6e59b.The text was updated successfully, but these errors were encountered: