About MongoDB global locks

Anyone who knows about MongoDB knows that MongoDB has a global lock (read and write locks allow concurrent reads, and write locks block all reads and writes). What's really bad about this lock?

Anyone who knows about MongoDB knows that MongoDB has a global lock (read and write locks allow concurrent reads, and write locks block all reads and writes). What's really bad about this lock?

PairMongoDBEveryone who knows about MongoDB has a headache.Global lock(Read/write lockAnd allow concurrent reads, while writing will block all reads and writes. The worst thing is that this lock is not at the table level, not at the database level, but at the Server level, it sounds like a headache.

This problem was not solved before version 2.0, so it was suggested that to reduce the time occupied by write locks when a record of an update operation may be stored on the disk, you can read and write records first, and load the records to be operated into the memory before performing update in the memory, in this way, the write lock does not include the time when data is loaded from the disk to the memory.

This kind of operation can have a certain effect on foreseeable hot and cold data, but it is obvious that this abnormal method should not be the ultimate solution.

Fortunately, in version 2.0, MongoDB declared a significant improvement in concurrency performance, and the foundation for this improvement is to solve the problem of the global lock.

The solution is not to reduce the lock granularity, although the collection-Level Lock Mechanism is under development. (SERVER-1240)

The solution is to suppress some operations that may cause long lock occupation. For example, the method above is similar. During the update operation, if the record to be updated is found on the disk, the lock will not be used all the time, instead, wait until the data is loaded from the disk to the memory and then add the write lock for update.

Similarly, similar methods can be used for other operations that may take a long time, by splitting a long-time global lock into multiple fine-grained small locks, you can perform operations that require the lock to be obtained in a staggered manner, so as to avoid the situation that the lock is always unavailable, it mainly includes the following operations:

If you are still using a version earlier than 2.0 and there is a problem with concurrency performance, you can consider performing some performance tests on version 2.0.x and upgrading your MongoDB.

The improvement in version 2.0 Sounds feasible, but what is the actual effect? Here we have two performance test images from blog.pythonisito.com.

The first one is the performance comparison between version 1.8 and Version 2.0 after the write lock is applied without triggering page faulting. We can see that, when write operations can be completed directly in the memory, there is almost no difference in the performance between the two.

The second figure shows that the write operation will trigger page faulting, that is, in 1.8, the write lock time will include the time when data is written from the disk to the memory, this period is not included in 2.0. It can be seen that the situation in version 2.0 is much better, because the lock suppression policy is adopted, so that after page faulting is generated, the concurrency performance is better.