[SERVER-5080] journal rotates while dbMutex is held Created: 24/Feb/12 Updated: 16/Feb/15 Resolved: 21/Jan/15 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Performance, Storage |
| Affects Version/s: | 2.1.0 |
| Fix Version/s: | 3.0.0-rc6 |
| Type: | Bug | Priority: | Major - P3 |
| Reporter: | Eric Milkie | Assignee: | Kaloian Manassiev |
| Resolution: | Done | Votes: | 1 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||||||||||
| Backwards Compatibility: | Fully Compatible | ||||||||||||||||||||
| Operating System: | ALL | ||||||||||||||||||||
| Participants: | |||||||||||||||||||||
| Description |
|
from
dwight says:
This may have caused a couple recent unit test breaks, in particular if it happens to occur while we are in an assert.soon(), since the default is that it only waits 30 seconds and the journal rotating can take a while as Dwight mentions above. |
| Comments |
| Comment by Githook User [ 21/Jan/15 ] | ||||||||||||||
|
Author: {u'username': u'kaloianm', u'name': u'Kaloian Manassiev', u'email': u'kaloian.manassiev@mongodb.com'}Message: Offloads the writing of the journal to disk to a separate thread, so that This allows the journal write to be parallelized with concurrent workload | ||||||||||||||
| Comment by Dwight Merriman [ 06/Mar/14 ] | ||||||||||||||
|
i think the way to go is simply move the _rotate call after the call to groupCommit. it can happen afterwards. you just have to be in _curLogFileMutex, I believe. so probably don't need to be in any dbMutex lock at all. perhaps it is called in the durThread() main loop. | ||||||||||||||
| Comment by Eric Milkie [ 27/Feb/12 ] | ||||||||||||||
|
I looked at the code. It seems like _rotate() (which does not actually rotate every time it's called but only rotates when it's time to do it) is always called each time we call WRITETOJOURNAL(). The comment for WRITETOJOURNAL() says:
There are two places in the code where WRITETOJOURNAL() is called; in groupCommit() and in groupCommitWithLimitedLocks(). The former is called with the read lock still held, while the latter does not. Most of the times groupCommit() is called seem to be rare, but there is one case in the main journal loop that I believe is causing most of the log entries:
The big N is 10, so every 10 times we automatically fall through and call the locking rotate check. Also, it looks like the private Map bytes comparison check fails if we are very write heavy – this is probably another trigger for the log entry. The call to WRITETOJOURNAL() in groupCommit() has a comment:
Perhaps this is the best way to avoid journal rotations with a read lock held; change the code so that no read locks are held during calls to groupCommit(). |