[SERVER-14562] more debug information for very long-held dblocks Created: 15/Jul/14 Updated: 11/Jul/16 Resolved: 29/Oct/14 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Concurrency |
| Affects Version/s: | None |
| Fix Version/s: | 2.8.0-rc0 |
| Type: | Improvement | Priority: | Major - P3 |
| Reporter: | Greg Studer | Assignee: | Kaloian Manassiev |
| Resolution: | Done | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||
| Participants: | |||||
| Linked BF Score: | 0 | ||||
| Description |
|
When certain operations take a very long amount of time waiting for locks, it's difficult to determine what they were waiting on unless it was a client operation and reported as slow. Non-client operations have no visibility. Proposal: potentially in debug mode only, for now, report warnings in the log for operations that A) hold locks for long amounts of time (multiple seconds) and B) wait a long amount of time for locks. Traces would also be great, but maybe too noisy. As an example, in testing we intermittently see activity stop and killCursors take > 30s to complete (waiting for locks), but no other client operations take nearly this amount of time. |
| Comments |
| Comment by Kaloian Manassiev [ 29/Oct/14 ] |
|
Available as of commit: https://github.com/mongodb/mongo/commit/083474cc37be86d9cb6302b8fe899293eb692429 |