Mongodb itself does not do memory management, and its memory management completely depends on the system. You can use System Performance Monitor to check memory and virtual memory. To put it simply, mongdb will eat as much memory as you have. It is so greedy that it will put most of the hot data in the memory to improve performance. After all, this is also its advantage.
Our server is Windows Server 2008, with 32G of memory. After running for a period of time, it was all used up, but the performance was surprising. However, there was not only mongodb on that server, so it often affected other programs. Later we tried to use Windows System Resource Manager WSRM limits the memory of the mongodb process. It is indeed effective. You can try it.
But I started using mongodb the year before last. The version at that time was relatively old. After limiting the memory, mongodb was very unstable and occasionally hung up. Looking at the logs, it generally meant that the mapped memory could not be found. So later we gave up limiting memory and switched to using mongodb commands to release memory at fixed points every day{closeAllDatabases:1}
This command also has a cost, it will be blocked until the command is complete, and the efficiency will be reduced immediately after it is released, and it will take a period of "warm-up" to slowly recover.
I think the latter method is good, and through observations over the past two years, everything is relatively stable. Of course, it would be great if you could give mongodb a separate server.
The new MongoDB engine will consider itself to be the only important service in the system, so it will try to occupy as much memory as its own cache (not the operating system's cache). If you need to reserve memory for other processes, or have multiple MongoDB instances, you can use the --cacheSizeGB parameter to limit the MongoDB cache size.
![[Web front-end] Node.js quick start](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
I remember, a person named Tang Jianfa said: MongoDB does not eat memory, but its original intention is to deliberately occupy memory.
Mongodb itself does not do memory management, and its memory management completely depends on the system. You can use System Performance Monitor to check memory and virtual memory. To put it simply, mongdb will eat as much memory as you have. It is so greedy that it will put most of the hot data in the memory to improve performance. After all, this is also its advantage.
Our server is Windows Server 2008, with 32G of memory. After running for a period of time, it was all used up, but the performance was surprising. However, there was not only mongodb on that server, so it often affected other programs. Later we tried to use Windows System Resource Manager WSRM limits the memory of the mongodb process. It is indeed effective. You can try it.
But I started using mongodb the year before last. The version at that time was relatively old. After limiting the memory, mongodb was very unstable and occasionally hung up. Looking at the logs, it generally meant that the mapped memory could not be found. So later we gave up limiting memory and switched to using mongodb commands to release memory at fixed points every day
{closeAllDatabases:1}This command also has a cost, it will be blocked until the command is complete, and the efficiency will be reduced immediately after it is released, and it will take a period of "warm-up" to slowly recover.
I think the latter method is good, and through observations over the past two years, everything is relatively stable. Of course, it would be great if you could give mongodb a separate server.
The new MongoDB engine will consider itself to be the only important service in the system, so it will try to occupy as much memory as its own cache (not the operating system's cache). If you need to reserve memory for other processes, or have multiple MongoDB instances, you can use the
--cacheSizeGBparameter to limit the MongoDB cache size.I wrote a script to clear the cache every early morning. . .
http://onwise.xyz/2017/02/23/...