[SERVER-10067] Future of 32-bit server Created: 01/Jul/13 Updated: 10/Dec/14 Resolved: 01/Jul/13 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Write Ops |
| Affects Version/s: | 2.5.0 |
| Fix Version/s: | None |
| Type: | Question | Priority: | Minor - P4 |
| Reporter: | Curt Mayers | Assignee: | Unassigned |
| Resolution: | Done | Votes: | 0 |
| Labels: | 32-bit, memory, mongod, roadmap | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Environment: |
All |
||
| Participants: |
| Description |
|
What are your futuure intentions for the 32-bit servers. I am currently running 2 instances of mongod – one a 64-bit instance for transactional data, and the other a 32-bit instance for our "archival" data. The archival data is quite large: several times the total memory capacity of the server, but is accessed pretty rarely (a typical record might get hit only 4 or 5 times per year). Just as a matter of resource management, I want all available memory to go to the transactional server. The 32-bit server seems like a good solution for us, because it's memory usage caps out (under Windows) at somewhere around 2GB. But I recently attended a 10gen presentation where I believe your representative said something about discontinuing support for 32-bit server releases (I'm not exactly sure, because the issue wasn't really on my radar at the time). But now it has become kind of important to me. If you ARE discontinuing 32-bit releases, would it be possible to add s startup option allowing a memory allocation cap on a running server instance? What is the best approach for the kind of scenario (archival, logging, or other large, infrequently-accessed data stores)--are virtual machines the only other viable approach? |
| Comments |
| Comment by Daniel Pasette (Inactive) [ 01/Jul/13 ] |
|
There are no plans to eliminate 32-bit versions of mongod. However, I think you misunderstand how memory mapped files work in mongodb. 32-bit instances of mongodb have a limit of how much data they are able to store, not just how much memory they use. The amount of memory used by a particular instance depends on how much that data is actually accessed. This means that if you have a rarely touched database, the data files will be mapped into virtual memory, but will not be RAM until accessed. However, if you were to do a scan of a large collection on your archive instance, that would cause all of that data to be paged into RAM. To run multiple instances of mongodb on the same physical hardware, while controlling the amount of memory allocated to each instance, you will need to use some sort of virtualization technique. |