3 ms·

Starting to get excited once again about MongoDB. I was kind of down about it after having some issues with real world implementations. Considering journaling i

Starting to get excited once again about MongoDB. I was kind of down about it after having some issues with real world implementations. Considering journaling is something I would never have thought would have made it in, I wonder if they will come around on the memory mapped I/O like everyone else eventually does. EDIT: Also... does the group commit mean that ALL write transactions will be un-acknowledged to the client until the group commit finishes?

mathias_10gen 16y ago
Clients are able to wait for the next group commit by adding fsync:true to getLastError calls (some drivers allow you to add this to WriteConcern). We already have some enhancements to this planned for the 1.9 series.
dmytton 16y ago
"You can wait for group commit acknowledgement with the getLastError command. When running with --journal, the fsync:true option returns after the data is physically written to the journal (rather than actually fsync'ing all the data files). Note that the group commit interval (see above) is considerable: you may prefer to call getLastError without fsync, or with a w: parameter instead with replication. In releases after 1.8.0 the delay for commit acknowledgement will be shorter." http://www.mongodb.org/display/DOCS/Journaling http://www.mongodb.org/display/DOCS/Journaling
- rbranson 16y ago
  RTFM'ing myself in public. While it's a great step forward, the whole thing sounds pretty immature at this point. It'll be a good day when this stuff matures and MongoDB has fsync:true and --journal by default, much to the chagrin of sensationalists everywhere. They'll really need to add some major smarts into the journaling and group commit if they're going to be able to stack up concurrent I/Os to help feed big disk arrays and even to get the best use out of SSDs which make back-and-forth latency on the I/O pipes even more significant.
tmountain 16y ago
I'm curious what you're getting at IRT memory mapped I/O. To me, one of Mongo's selling points is the way it lets the OS manage caching for you instead of bothering you with tuning a bunch of buffers and things along those lines. For the sake of disclosure, I'm running 6 servers in a pretty high volume cluster, and while I've had to address some issues here and there, memory management hasn't been one of them.

mathias_10gen 16y ago

Clients are able to wait for the next group commit by adding fsync:true to getLastError calls (some drivers allow you to add this to WriteConcern). We already have some enhancements to this planned for the 1.9 series.

dmytton 16y ago

"You can wait for group commit acknowledgement with the getLastError command. When running with --journal, the fsync:true option returns after the data is physically written to the journal (rather than actually fsync'ing all the data files). Note that the group commit interval (see above) is considerable: you may prefer to call getLastError without fsync, or with a w: parameter instead with replication. In releases after 1.8.0 the delay for commit acknowledgement will be shorter." http://www.mongodb.org/display/DOCS/Journaling http://www.mongodb.org/display/DOCS/Journaling

rbranson 16y ago
RTFM'ing myself in public. While it's a great step forward, the whole thing sounds pretty immature at this point. It'll be a good day when this stuff matures and MongoDB has fsync:true and --journal by default, much to the chagrin of sensationalists everywhere. They'll really need to add some major smarts into the journaling and group commit if they're going to be able to stack up concurrent I/Os to help feed big disk arrays and even to get the best use out of SSDs which make back-and-forth latency on the I/O pipes even more significant.

tmountain 16y ago

I'm curious what you're getting at IRT memory mapped I/O. To me, one of Mongo's selling points is the way it lets the OS manage caching for you instead of bothering you with tuning a bunch of buffers and things along those lines. For the sake of disclosure, I'm running 6 servers in a pretty high volume cluster, and while I've had to address some issues here and there, memory management hasn't been one of them.