The sixth part of wiredtiger storage engine: cache allocation rules and page elimination mechanism

Time:2020-12-6

The sixth part of wiredtiger storage engine: cache allocation rules and page elimination mechanism

preface

This article will introduce the wiredtiger storage engine from the perspective of logical correctness and complete content. This article is the sixth and final article in a series of introduction to wiredtiger storage engine.

You can read the previous content by clicking on the title below:

This article includes the following contents:

  • Cache allocation rules for wiredtiger storage engine
  • Elimination mechanism of memory page

1.2 cache allocation mechanism

When wiredtiger is started, it will request some memory from the operating system for its own use. This part of memory is called internal cache. If only mongodb related service processes are running on the host, the remaining memory can be used as the file system cache and managed by the operating system, as shown in the following figure:

The sixth part of wiredtiger storage engine: cache allocation rules and page elimination mechanism

Figure: cache allocation rules

When mongodb starts, it first cuts a large block from the whole host memory and allocates it to wiredtiger’s internal cache, which is used to build various pages in B-tree and to add, delete, modify and query based on these pages.

Starting with mongodb version 3.4, the default internal cache size is determined by the following rule: compare the size of 50% of (RAM – 1 GB) and 256 MB, whichever is larger. For example, if the host memory is 10GB, the internal cache value is 50% of (10GB – 1GB), which is equal to 4.5gb;

If the host memory is 1.2GB, the internal cache value is 256MB.

Then, an extra small block will be allocated from the host memory to create a dedicated index for mongodb. The default maximum value is 500MB. This rule is applicable to the construction of all indexes, including when multiple indexes are built at the same time.

Finally, the remaining memory of the host (excluding the use of other processes) will be used as the file system cache for mongodb to use. In this way, mongodb can also cache compressed disk files into memory, thus reducing disk I / O.

In order to save disk space, the data of the collection and index on the disk are compressed. By default, the set adopts the block compression algorithm, and the index adopts the prefix compression algorithm. Therefore, the format of the same data in disk, file system cache and internal cache is different, as described below:

  • The format of all data in the file system cache is consistent with that on the disk. Loading the data into the file system cache first can not only reduce the number of disk I / O, but also reduce the occupation of memory;
  • After the index data is loaded into wiredtiger’s internal cache, the format is different from that on disk, but it can still reduce the memory consumption by taking advantage of its prefix compression feature (that is, removing the duplicate prefix on the index field);
  • After the collection data is loaded into wiredtiger’s internal cache, its data must be decompressed before it can be used by various subsequent operations. Therefore, the format is different from that on disk and file system cache.

1.3 page elimination mechanism

When the “dirty pages” in the cache reach a certain proportion or the cache usage reaches a certain proportion, the corresponding evict page thread will be triggered to eliminate the pages (including clean pages and dirty pages) according to a certain algorithm (LRU queue), so as to free up the memory space and ensure the following new insertion or modification operations.

The trigger condition of page eviction is controlled by the following parameters, as shown in the following table:

Parameter name Default configuration value meaning
eviction_target 80% When the cache usage reaches 80%, work thread will be triggered to eliminate page
eviction_trigger 90% When the usage of cache reaches 90%, application thread and work thread will be triggered to eliminate page
eviction_dirty_target 5% When the proportion of “dirty data” in cache reaches 5%, work thread will be triggered to eliminate page
eviction_dirty_trigger 20% When the proportion of “dirty data” in cache reaches 20%, application thread and work thread will be triggered to eliminate page

In the first case:When the percentage of cache usage reaches the parameter eviction_ When target is set (the default value is 80%), the background thread will be triggered to execute page eviction;

If the usage continues to grow, it will reach the conclusion_ When the trigger parameter is set (the default value is 90%), the read and write requests supported by the application thread will be blocked. The application thread also participates in the page elimination to accelerate the elimination of pages in memory.

The second case is:When the “dirty data” in the cache reaches the parameter eviction_ dirty_ When target is set to 5% in the background, the thread will be triggered;

If the “dirty data” continues to grow to the parameter eviction_ dirty_ Trigger setting (the default value is 20%) will trigger the application thread to execute page eviction.

There is also a characteristic case:When the page is continuously inserted or updated, if the memory occupied by the contents on the page is larger than the maximum value (memory) set by the system_ page_ Max), the page eviction action is forced to be triggered.

First, the large page is divided into several small pages, and then these small pages are saved to the disk through reconcile. Once the reconcile is written to the disk, these pages can be eliminated from the cache, thus making room for more write operations later.

By default, wiredtiger uses only one background thread to complete page eviction. In order to improve the performance of inspection, we can use the parameter threads_ Min and threads_ Max to set the number of background threads that the evict server starts.

By setting a reasonable value, the page elimination can be accelerated to avoid the application thread being forced to join the elimination task due to untimely elimination, which will cause the application thread to block other normal request operations.

When a page is eliminated, the page will be locked first, and then check whether there are other threads on the page (judge whether there is a hazard point pointer pointing to it). If so, the page will not be evicted.

The sixth part of wiredtiger storage engine: cache allocation rules and page elimination mechanism

Columnist: Guo Yuanwei

Senior consultant and architect of big data solutions, member of mongodb Chinese community, chairman of Changsha branch, many years of experience in research and development, planning and consulting of big data in communication industry; author of mongodb practical guide for big data storage; ACP Certified Expert of Alibaba cloud computing.

Maybe you are still interested——

The sixth part of wiredtiger storage engine: cache allocation rules and page elimination mechanismThe sixth part of wiredtiger storage engine: cache allocation rules and page elimination mechanismThe sixth part of wiredtiger storage engine: cache allocation rules and page elimination mechanismThe sixth part of wiredtiger storage engine: cache allocation rules and page elimination mechanism