# Why default value of rocksdb\_deadlock\_detect option is FALSE?

**URL:** <https://forums.percona.com/t/why-default-value-of-rocksdb-deadlock-detect-option-is-false/6292>\
**Category:** Percona Server for MySQL 5.7\
**Created:** [April 9, 2018, 6:58am UTC](https://forums.percona.com/t/why-default-value-of-rocksdb-deadlock-detect-option-is-false/6292 "2018-04-09T06:58:16Z")\
**Posts on this page:** 2\
**Page:** 1

<div class="post-metadata">

**Author:** ![brew74](https://avatars.discourse-cdn.com/v4/letter/b/3da27b/32.png) [@brew74](https://forums.percona.com/u/brew74)\
**Post date:** [April 9, 2018, 6:58am UTC](https://forums.percona.com/t/why-default-value-of-rocksdb-deadlock-detect-option-is-false/6292/1 "2018-04-09T06:58:16Z")

</div>

According to the MyRocks storage engine variables of Percona server for MySQL  
([URL=“[MyRocks Server Variables — Percona Server 5.7 Documentation](https://www.percona.com/doc/percona-server/5.7/myrocks/variables.html#rocksdb_deadlock_detect)”][https://www.percona.com/doc/percona-...eadlock\_detect[/URL]](https://www.percona.com/doc/percona-...eadlock_detect%5B/URL%5D)), rocksdb\_deadlock\_detect variables’ default value is FALSE.

Does this mean there’s no deadlock checks in RocksDB engine ?  
And we should rely on rocksdb\_lock\_wait\_timeout ?

Is there any reason deadlock check is disabled on RocksDB ?

Thanks in advance.

---

<div class="post-metadata">

**Author:** ![George\_Lorch](https://sea1.discourse-cdn.com/flex019/user_avatar/forums.percona.com/george_lorch/32/1108_2.png) [@George\_Lorch](https://forums.percona.com/u/George_Lorch)\
**Post date:** [April 10, 2018, 5:47pm UTC](https://forums.percona.com/t/why-default-value-of-rocksdb-deadlock-detect-option-is-false/6292/2 "2018-04-10T17:47:03Z")

</div>

This is/was a decision originally made by Facebook developers and we simply inherited it without much consideration. I believe the original decision is based on their performance requirements. This deadlock detection would start traversing locks and transactions as soon as a locker was refused a lock where otherwise the locker would just go into a lock-wait (i.e. a record that the locker wants to lock is already locked by something else). In many cases, there is no real deadlock, just a lock wait. This extra searching for a deadlock where there likely isn’t one creates a potential performance hit. In general, I believe it is meant to be a troubleshooting tool after lock wait timeouts are experienced possibly due to deadlocking, not to prevent them.