[SERVER-2701] dur commitifneeded needed in NamespaceDetails::capped? Created: 08/Mar/11 Updated: 29/May/12 Resolved: 14/Mar/11 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Storage |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Minor - P4 |
| Reporter: | Dwight Merriman | Assignee: | Aaron Staple |
| Resolution: | Done | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Operating System: | ALL |
| Participants: |
| Description |
|
Mon Mar 7 20:57:48 [conn14] debug nsincecommitifneeded:880 bytes:17530880 |
| Comments |
| Comment by Dwight Merriman [ 14/Mar/11 ] |
|
i think this may actually be ok as-is. |
| Comment by Dwight Merriman [ 09/Mar/11 ] |
|
i'm pretty sure in general it's not safe to commitIfNeeded herein – imagine a capped collection with a bunch of indexes. if adding the index keys comes second, that becomes a separate "transaction". the oplog is generally the last thing we do, in that scenario it is probably ok, but as said above doesn't seem to generalize. if it only goes up to 3x bsonsizemax it is ok anyway. |
| Comment by Dwight Merriman [ 09/Mar/11 ] |
|
can get it to this or higher: Tue Mar 8 19:05:40 [conn42] debug nsincecommitifneeded:9720 bytes:54607872 to repro run with --oplogSize 128, run several times: ./mongo jstests/b*js big_object1.js is the thing that makes it happen. normal this will take some, just seems to be going a bit higher than expected. maybe that is the right number. for a big object we have so 3X max bsonobjsize is expected. |
| Comment by Dwight Merriman [ 08/Mar/11 ] |
|
only if it's super safe |
| Comment by Eliot Horowitz (Inactive) [ 08/Mar/11 ] |
|
I think we need to do this for 1.8.0, or no? |
| Comment by Dwight Merriman [ 08/Mar/11 ] |
|
btw : would it possible to do this incrementally, so that we don't have such a large txn? |
| Comment by Aaron Staple [ 08/Mar/11 ] |
|
There can potentially be lots of writes happening in the loop within cappedAlloc(). It would be fairly easy to add a commitIfNeeded() as part of that loop. We'd need to check the call sites of cappedAlloc() and its ancestor callers for write pointers that might be invalidated by a commit. Dwight, could you assign a priority / version so I'll know when I should work on this? |