Skip to content

Commit ae18449

Browse files
committed
PS-9721 Improve documentation on MyRocks variables (8.0)
On branch ps-9822 modified: docs/variables.md
1 parent c0e355c commit ae18449

File tree

1 file changed

+67
-9
lines changed

1 file changed

+67
-9
lines changed

docs/variables.md

Lines changed: 67 additions & 9 deletions
Original file line numberDiff line numberDiff line change
@@ -269,8 +269,18 @@ Enabled by default.
269269
| Data type | Boolean |
270270
| Default | OFF |
271271

272-
Specifies whether to allow multiple writers to update memtables in parallel.
273-
Disabled by default.
272+
#### Enable concurrent memtable writes
273+
274+
This option is a direct bridge to RocksDB's `DBOptions::allow_concurrent_memtable_write`. If this setting is not enabled, MyRocks processes memtable updates sequentially, even when multiple threads issue writes simultaneously. Enabling this option allows parallel memtable updates, which can improve write throughput in multi-threaded workloads.
275+
276+
#### When to enable
277+
278+
This setting is disabled by default. Consider enabling rocksdb_allow_concurrent_memtable_write in the following situations:
279+
280+
| Condition | Description |
281+
|----------------------------|-------------|
282+
| High concurrent write workload | Your application has many threads or clients writing to MyRocks at the same time. Enabling this option can improve throughput and reduce latency in multi-threaded environments. |
283+
| Write-bound workloads | If write performance is a bottleneck and CPU usage is low during writes, it may be due to serialized memtable updates. Enabling this option allows better use of CPU cores and can improve overall write performance. |
274284

275285
### `rocksdb_allow_to_start_after_corruption`
276286

@@ -1092,11 +1102,27 @@ By default, it is created in the current working directory.
10921102
| Data type | Numeric |
10931103
| Default | 0 |
10941104

1095-
Specifies the maximum size of all memtables used to store writes in MyRocks
1096-
across all column families. When this size is reached, the data is flushed
1097-
to persistent media.
1098-
The default value is `0`.
1099-
The allowed range is up to `18446744073709551615`.
1105+
This option is a direct bridge to RocksDB's `DBOptions::db_write_buffer_size`.
1106+
1107+
The `rocksdb_db_write_buffer_size` setting limits the amount of memory in memtables across all column families. MyRocks flushes the largest memtable to disk when the total size exceeds this limit. This operation helps prevent excessive memory use and makes memory behavior more predictable.
1108+
1109+
#### Available values
1110+
1111+
The default value is `0`, which is disabled, and MyRocks does not limit the amount of memory used by memtables.
1112+
1113+
Setting a non-zero value provides a safeguard against excessive memory usage. It ensures that the total memory used by memtables does not exceed the specified limit, preventing potential memory overflow issues.
1114+
1115+
The maximum range is `18446744073709551615`.
1116+
1117+
#### When to use
1118+
1119+
This setting is disabled by default. You should consider setting rocksdb_db_write_buffer_size under the following conditions:
1120+
1121+
• Running multiple column families and controlling overall memory usage.
1122+
1123+
• Operating in shared environments or low-memory systems.
1124+
1125+
• Avoiding Out-of-Memory (OOM) issues in write-heavy workloads.
11001126

11011127
### `rocksdb_deadlock_detect`
11021128

@@ -1488,11 +1514,43 @@ The variable was implemented in [Percona Server for MySQL 8.0.20-11](release-not
14881514
| Data type | Boolean |
14891515
| Default | OFF |
14901516

1517+
#### Version changes
1518+
14911519
The variable was implemented in [Percona Server for MySQL 8.0.25-15](release-notes/Percona-Server-8.0.25-15.md#id1).
14921520

1493-
DBOptions::enable_pipelined_write for RocksDB.
1521+
#### Improving Write Throughput with Pipelined Writes
1522+
1523+
This option maps directly to RocksDB’s `DBOptions::enable_pipelined_write`. For details, see the [RocksDB documentation on Pipelined Write](https://github.com/facebook/rocksdb/wiki/Pipelined-Write).
1524+
1525+
1526+
RocksDB uses pipelined writes to increase throughput in workloads with
1527+
concurrent writers. When the Write-Ahead Log (WAL) is enabled, write
1528+
operations normally pass through a shared queue. Each writer appends to the
1529+
WAL and then updates the memtable in strict sequence. This pattern limits
1530+
parallelism.
1531+
1532+
With pipelined writes, RocksDB overlaps the WAL and memtable stages across
1533+
writers. As soon as one thread completes its WAL write, the next thread in
1534+
line can begin its own WAL operation—even if the previous thread has not yet
1535+
updated the memtable. This change interleaves write stages, reduces latency,
1536+
and improves overall write throughput.
1537+
1538+
Enabling `rocksdb_enable_pipelined_write` activates this feature. It is
1539+
especially useful in workloads with high concurrency or transaction phases
1540+
that generate bursts of write activity, such as the prepare step in
1541+
two-phase commit protocols.
1542+
1543+
1544+
#### When to enable pipelined writes
1545+
1546+
Pipelined writes are disabled by default. You should consider enabling enable_pipelined_write in MyRocks under the following conditions:
14941547

1495-
If `enable_pipelined_write` is `ON`, a separate write thread is maintained for WAL write and memtable write. A write thread first enters the WAL writer queue and then the memtable writer queue. A pending thread on the WAL writer queue only waits for the previous WAL write operations but does not wait for memtable write operations. Enabling the feature may improve write throughput and reduce latency of the prepare phase of a two-phase commit.
1548+
| Condition | Description |
1549+
|------------------------------------|-----------------------------------------------------------------------------------------------------------------------------------|
1550+
| High concurrent write workloads | If your application involves many concurrent writers, pipelined writes, which overlap WAL and memtable writes, can improve throughput. |
1551+
| Write-Ahead logging (WAL) is enabled | This feature only applies when WAL is enabled. Enabling pipelined writes has no effect if you’re not using WAL. |
1552+
| Lower latency for transactions | Particularly beneficial in reducing latency during the prepare phase of two-phase commits (2PC), which is critical in transactional workloads. |
1553+
| WAL writes are a bottleneck | If profiling shows that waiting for WAL writes limits your write throughput, pipelined writes can help by decoupling WAL and memtable operations. |
14961554

14971555
### `rocksdb_enable_remove_orphaned_dropped_cfs`
14981556

0 commit comments

Comments
 (0)