[MDEV-17874] MyRocks-Gap-Lock: Lock memory overhead Created: 2018-11-29 Updated: 2023-11-28 Resolved: 2023-11-28 |
|
| Status: | Closed |
| Project: | MariaDB Server |
| Component/s: | Locking, Storage Engine - RocksDB, Tests |
| Affects Version/s: | N/A |
| Fix Version/s: | N/A |
| Type: | Bug | Priority: | Major |
| Reporter: | Sergei Petrunia | Assignee: | Sergei Petrunia |
| Resolution: | Won't Fix | Votes: | 0 |
| Labels: | None | ||
| Issue Links: |
|
||||||||
| Description |
|
Several MyRocks tests currently fail, because they reach rocksdb_max_lock_memory and lock escalation is unable to reduce memory usage. One example is autoinc_vars_thread_2. AUTO_INCREMENT values are generated by each thread using auto_increment_offset which causes all adjacent row locks to belong to different transactions. |
| Comments |
| Comment by Sergei Petrunia [ 2018-11-29 ] | |||
|
in spetrunia/mysql-5.6-rangelocking
in Percona Server:
Add to that keyrange::get_memory_size() which is (sizeof(key_range)=72) + left_key_size +right_key_size (they are intentionally counted twice). In total, for pk INT PRIMARY KEY the lock memory usage is 264 bytes in 5.6-rangelocking (debug build) and 274 in debug build of Percona Server. | |||
| Comment by Sergei Petrunia [ 2018-11-29 ] | |||
|
In Percona Server's MTR environment: tokudb_max_lock_memory is not set, so tokudb_init_func sets it to 1/8 th of tokudb-cache-size which is 512M, so we get 64M. In MariaDB, the default value is tokudb_max_lock_memory = 1 035 604 992= 1G |