You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
bmatican
changed the title
[docdb] Deadlock between DeleteTablet calls and paused compactions
[docdb] Potential long wait / deadlock between DeleteTablet calls and paused compactions
Aug 19, 2019
Summary:
While performing shutdown we set shutting down flag, then abort all compactions
associated with this rocks DB.
But while scheduling new compaction we don't check shutting down flag,
so new compaction could be scheduled in parallel to shutdown.
Causing rocksdb DB to wait until this compaction completes.
Added shutdown check while scheduling compaction.
Test Plan: Jenkins
Reviewers: mikhail, timur, bogdan
Reviewed By: bogdan
Subscribers: ybase
Differential Revision: https://phabricator.dev.yugabyte.com/D7094
…ons to false
Summary:
The issue described in #2100 was fixed by D7094, but we still could get into the situation when RocksDB shutdown takes a long time.
Because its compaction task was paused by other tasks with higher priority.
So it is better to set gflag `use_priority_thread_pool_for_compactions` to `false` until dynamic priorities will be implemented.
Test Plan: Jenkins
Reviewers: amitanand, kannan
Reviewed By: kannan
Subscribers: ybase
Differential Revision: https://phabricator.dev.yugabyte.com/D7184
Summary:
Long testing of write heavy workload shown that we perform better with compaction preemption.
So this diff changes allow_preempting_compactions to true.
Test Plan: Jenkins
Reviewers: rao, mikhail, bogdan, kannan
Reviewed By: bogdan, kannan
Subscribers: ybase
Differential Revision: https://phabricator.dev.yugabyte.com/D7547
Rocksdb shutdown stuck
Pause compaction
Actual symptom that highlighted the issue was the master heartbeater was stuck, because it also needs to get info from all the tablets:
The text was updated successfully, but these errors were encountered: