MongoDB, the renowned NoSQL database, has recently unveiled its latest iteration - MongoDB 7.0. This release introduces a plethora of new features and significant performance enhancements. As we explore MongoDB 7.0, a standout feature capturing our attention is the dynamic WiredTiger tickets system. This feature, powered by a new algorithm for real-time ticket management, holds the potential to reshape how MongoDB handles concurrency control within the WiredTiger storage engine. In this deep dive, our goal is to illuminate the intricacies of WiredTiger tickets and provide insights into the dynamic changes brought about by MongoDB 7.0.

Understanding WiredTiger Tickets

Explanation of Read and Write tickets

WiredTiger tickets play a pivotal role in MongoDB's sophisticated concurrency control mechanism, especially within the WiredTiger storage engine. These tickets can be broadly classified into two main types: Read tickets and Write tickets.

In scenarios where multiple operations, such as reads and writes, attempt to access the database simultaneously, WiredTiger leverages tickets to ensure these operations do not conflict in a manner that compromises data integrity or system performance.

Previous ticket allocation parameters

Each transaction initiated in MongoDB acquires a ticket at the beginning and returns it to the ticket pool upon completion. Before MongoDB 7.0, the number of tickets was determined by two critical parameters:

1. wiredTigerConcurrentReadTransactions
2. wiredTigerConcurrentWriteTransactions

These parameters controlled the number of concurrent read and write transactions (tickets) allowed within the WiredTiger storage engine, with the default value set at 128 tickets.

Dynamic WiredTiger Tickets

With the introduction of MongoDB 7.0, the dynamic WiredTiger tickets represent a significant departure in how MongoDB handles its resources. Rather than adhering to a fixed allocation model, dynamic tickets empower MongoDB to adapt and allocate resources dynamically and in real-time, utilizing an innovative algorithm (for more details, refer to this link). This dynamic allocation ensures resources are adjusted to match the current workload, guaranteeing optimal performance even under varying conditions.

Sticking with these default values allows MongoDB to dynamically manage the number of tickets, optimizing performance with a maximum value of 128.

However, starting with MongoDB 7.0, if you set wiredTigerConcurrentReadTransactions and wiredTigerConcurrentWriteTransactions to a non-default value, it disables the algorithm that dynamically adjusts the number of concurrent storage engine transactions.

Disabling Dynamic WiredTiger Tickets

To disable dynamic WiredTiger tickets, follow these steps:

 
> db.serverStatus().wiredTiger.concurrentTransactions
{
  write: {
	out: 0,
	available: 4,
	totalTickets: 4,
	immediatePriorityAdmissionsCount: Long("0"),
	addedToQueue: Long("0"),
	removedFromQueue: Long("0"),
	queueLength: Long("0"),
	startedProcessing: Long("492"),
	processing: Long("0"),
	finishedProcessing: Long("492"),
	totalTimeProcessingMicros: Long("7180"),
	canceled: Long("0"),
	newAdmissions: Long("8"),
	totalTimeQueuedMicros: Long("0")
  },
  read: {
	out: 0,
	available: 4,
	totalTickets: 4,
	immediatePriorityAdmissionsCount: Long("485"),
	addedToQueue: Long("0"),
	removedFromQueue: Long("0"),
	queueLength: Long("0"),
	startedProcessing: Long("500"),
	processing: Long("0"),
	finishedProcessing: Long("500"),
	totalTimeProcessingMicros: Long("17498"),
	canceled: Long("0"),
	newAdmissions: Long("493"),
	totalTimeQueuedMicros: Long("0")
  },
  monitor: {
	timesDecreased: Long("0"),
	timesIncreased: Long("0"),
	totalAmountDecreased: Long("0"),
	totalAmountIncreased: Long("0")
  }
}
	

• Stop the MongoDB service

 
sudo systemctl stop mongod.service
	

• Edit the MongoDB configuration file and add the below setParameter option

 
setParameter:
  storageEngineConcurrentReadTransactions: 128
  storageEngineConcurrentWriteTransactions: 128
	

• Start the MongoDB service

 
sudo systemctl start mongod.service
	

• Verify the status of the wiredTiger concurrent read and write tickets

 
> db.serverStatus().wiredTiger.concurrentTransactions
{
  write: {
	out: 0,
	available: 128,
	totalTickets: 128,
	immediatePriorityAdmissionsCount: Long("0"),
	addedToQueue: Long("0"),
	removedFromQueue: Long("0"),
	queueLength: Long("0"),
	startedProcessing: Long("9"),
	processing: Long("0"),
	finishedProcessing: Long("9"),
	totalTimeProcessingMicros: Long("16"),
	canceled: Long("0"),
	newAdmissions: Long("0"),
	totalTimeQueuedMicros: Long("0")
  },
  read: {
	out: 0,
	available: 128,
	totalTickets: 128,
	immediatePriorityAdmissionsCount: Long("9"),
	addedToQueue: Long("0"),
	removedFromQueue: Long("0"),
	queueLength: Long("0"),
	startedProcessing: Long("15"),
	processing: Long("0"),
	finishedProcessing: Long("15"),
	totalTimeProcessingMicros: Long("910"),
	canceled: Long("0"),
	newAdmissions: Long("13"),
	totalTimeQueuedMicros: Long("0")
  }
}
	

As you can see, the totalTickets for both read and write operations have increased to 128. Your configuration is now static.

 
Important Note:

Before we wrap up, it's crucial to understand that dynamic WiredTiger tickets cannot be disabled during runtime. Attempting to do so will result in an error.
	

 
> db.adminCommand( { setParameter: 1, wiredTigerConcurrentReadTransactions: 128 } )
MongoServerError: Cannot modify concurrent read transactions limit when it is being dynamically adjusted
	

Recommendation

• In our extensive experience working with clients, we have consistently found that configuring 128 concurrent tickets proves to be highly effective for their workloads, even in the MongoDB 7.0 environment. As a result, we strongly recommend adhering to this configuration for the time being.
• Looking ahead, we have plans to conduct further evaluations to gauge the performance and potential benefits of dynamic WiredTiger tickets. Should any members of the MongoDB team come across this blog, we encourage enriching the official documentation with additional details regarding the performance enhancements and improvements associated with dynamic WiredTiger tickets.

While dynamic allocation presents a promising feature, it's crucial to recognize that not all scenarios necessitate or derive benefits from it. Your hands-on experience and in-depth knowledge of your database environment should be the guiding factors in choosing between static and dynamic ticket allocation.

At present, we strongly advocate sticking with the proven configuration of 128 concurrent tickets, a strategy consistently effective across diverse client workloads. Looking ahead, our commitment to exploring the performance and advantages of dynamic WiredTiger tickets remains unwavering. We hope that the MongoDB team considers augmenting the official documentation with more detailed information on this impactful topic.

As we conclude our deep dive into MongoDB 7.0's dynamic WiredTiger tickets, remember that Mydbops is here to guide you in unlocking the full potential of your MongoDB database.

{{cta}}