What are read and write tickets in WiredTiger?

Read and write tickets control concurrency in WiredTiger. That is, they control how many read and write operations can execute on the storage engine at the same time. These settings are specific to WiredTiger, and thus do not govern the number of concurrent operations in the database. MongoDB has a separate mechanism for saving operation progress, then yielding to other operations.

Default values

The default value for both read and write tickets is 128. This value is large enough that WiredTiger concurrency is not a bottleneck on typical server hardware.

As those numbers put a limit on concurrent operations, it is reasonable to assume that increasing WiredTiger's read/write ticket numbers would alleviate operation queue pressure. In most cases, however, WiredTiger concurrency is a symptom of queue pressure, not the cause. In these situations, increasing WiredTiger read/write ticket numbers will cause queuing in other parts of the system (for example CPU and I/O) in a less controlled fashion than normal.

Exhausted read or write tickets numbers

When available read and write tickets drop to zero, the number of concurrent running operations is equal to the configured read/write values. This means that any other operations must wait until one of the running threads finishes its work on the storage engine before executing.

In the majority of cases, read/write tickets dropping to zero is a sign of an increase in load or of slow performance (for example slow hardware or poorly-indexed queries) causing operations to run for much longer than expected.

Changing the default value of read and write tickets

Changing the values of read or write tickets should only be done after a thorough assessment by MongoDB. Increasing read/write tickets when it is not the cause of the issue might result in sustained performance degradation.

Changing the values to an extremely high number (much higher than the cores available) could also force the CPU to spend more time doing expensive context-switches rather than doing actual work. This would lead to a decrease in throughput and an increase in queue pressure.