[SERVER-5159] How to set up MongoDB in order to specify storing data in RAM vs disk Created: 01/Mar/12  Updated: 13/Mar/12  Resolved: 13/Mar/12

Status: Closed
Project: Core Server
Component/s: Performance
Affects Version/s: None
Fix Version/s: None

Type: Question Priority: Major - P3
Reporter: Chris Cho Assignee: Tyler Brock
Resolution: Done Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Participants:

 Description   

Hello, we have a couple of questions that we were hoping that you could answer.

Our use case is using MongoDB as both a message queue as well as a message store. The data in the message queue needs to be fast to access and fast to update while the data in the message store will require lots of space but gets accessed infrequently. They should all be accessible in the same mongo application as well to avoid having to reference two separate instances as it might be just as easy to use a database as the message store. So given the use case above, here are the questions:

1) How does the mechanism work that determines what documents should be kept in RAM when mongo exceeds the size of the machine's physical RAM rather than disk?

2) Can we leverage a configuration setting or some detail about the aforementioned mechanism to ensure that using the same mongo application as a message store will not impact the performance of the message queue?

Thanks in advance.



 Comments   
Comment by Chris Cho [ 13/Mar/12 ]

Please close the issue, thanks.

Comment by Tyler Brock [ 13/Mar/12 ]

Can we provide more information Chris or should we close this issue out?

Comment by Chris Cho [ 02/Mar/12 ]

Hi Eliot,
Thanks for your response. I guess I may end up doing some application-side caching to ensure that the message queue data gets priority in RAM.

Comment by Eliot Horowitz (Inactive) [ 02/Mar/12 ]

What's stored in memory is all based on LRU.
So a high volume small message bus would always be in ram on the same box as a large database slowly accessed.

Generated at Thu Feb 08 03:08:04 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.