First, Introduction:
Like most NoSQL databases, Redis also follows the Key/value data storage model. In some cases, Redis will save keys/values in memory to improve the efficiency of data query and data modification, but this is not always a good choice. In view of this, we can further optimize, that is, as far as possible in memory to retain only the keys data, so as to ensure the efficiency of data retrieval, and values are rarely used in the time can be swapped out to disk.
In practical applications, only about 10% of the keys belong to relatively common keys, so that Redis can swap out the rest of the keys and values to disk, and once these swapped keys or values need to be read, Redis then reads it back into main memory again.
Second, the application scene:
For most databases, the best way to run is to load all the data into memory, and the subsequent query operations can be completely based on memory data. In reality, however, such scenarios are not common, and in many cases only some of the data can be loaded into memory.
In Redis, there is a very important concept that the keys will not be exchanged, so if you have a large number of keys in your database, where each key is only associated with a small value, then this scenario is not ideal for using virtual memory. If, on the contrary, the database contains only a small number of keys, and each key is associated with a very large value, then this scenario is suitable for the use of virtual storage.
In practical applications, to enable virtual storage to function more fully to help us improve the efficiency of the system, we can combine keys with many smaller values into keys with a small number of larger values. One of the most important methods is to change the original Key/value mode to a hash based mode, which allows many of the original keys to become the attributes in the hash.
Third, the configuration:
1. Add the following configuration entry in the configuration file to enable the current Redis server to turn on the virtual Storage feature at startup.
vm-enabled Yes
2. Set Redis the maximum number of virtual bytes available in the configuration file. If the data in memory is greater than this value, a portion of the object is swapped out to disk, and the memory occupied by the swapped object is freed until the memory used is less than the value to stop swapping.
Copy Code code as follows:
Redis's Exchange rule is to consider the "oldest" data as much as possible, that is, data that is not used for the longest time will be swapped out. If the age of two objects is the same, then the data with greater value will be swapped out first. It should be noted that REDIS does not swap keys to disk, so if the data for the keys is filled with the entire virtual deposit, then the data model will not be appropriate to use the virtual storage mechanism, or set the value larger to accommodate the entire keys data. In practical applications, if you consider using Redis virtual memory, we should allocate as much memory as possible to redis use to avoid frequent swapping.
3. Set the number of pages in the configuration file and the number of bytes per page. In order to transfer the data in memory to disk, we need to use the swap file. These files have nothing to do with data persistence, and Redis will remove them all before exiting. Since most of the access to the swap file is random access, it is recommended that the swap file be stored on a solid-state disk, which can greatly improve the system's operational efficiency.
Copy Code code as follows:
Vm-pages 134217728
Vm-page-size 32
In the above configuration, Redis divides the interchange file into Vm-pages pages, where each page occupies a vm-page-size, Redis the final available interchange file size is: Vm-pages * vm-page-size. Since a value can be stored on one or more pages, but a page cannot hold multiple value, in view of this, we need to fully consider the Redis feature when setting vm-page-size.
4. There is a very important configuration parameter in the Redis configuration file, namely:
Copy Code code as follows:
This parameter represents the maximum number of threads that Redis applies when performing an IO operation on the swap file. Generally, we recommend that the value be equal to the CPU cores of the host. If this value is set to 0, then Redis will perform this operation synchronously when IO interacts with the swap file.
For Redis, if the operation Exchange file is synchronized, when a client is accessing data in the swap file, the client's request will be suspended until the previous operation ends if another client attempts to access the data in the swap file. Especially when reading large data values on relatively slow or busy disks, the effect of this blocking is even more abrupt. However, synchronous operations are not useless, in fact, from a global execution efficiency perspective, synchronization is better than the asynchronous way, after all, the synchronization method saves the thread switching, synchronization between threads, and thread pull up and other operations resulting in additional overhead. In particular, when most of the frequently used data can be read directly from the main memory, the synchronization mode will be more excellent performance.
If your actual application is the opposite, there is a lot of swapping in and out operation, and your system has a lot of cores, in view of this, you do not want the client to access the swap file had to block for a short period of time, if so, I think the asynchronous way may be more suitable for your system.
The best answer will come from constant experimentation and tuning as to which configuration is ultimately chosen.
