[SERVER-26812] top command counters should not be able to move backwards Created: 27/Oct/16 Updated: 06/Dec/22 |
|
| Status: | Backlog |
| Project: | Core Server |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Major - P3 |
| Reporter: | Jonathan Reams | Assignee: | Backlog - Query Execution |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | open_todo_in_code, query-44-grooming | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||
| Assigned Teams: |
Query Execution
|
||||
| Operating System: | ALL | ||||
| Participants: | |||||
| Linked BF Score: | 15 | ||||
| Description |
|
We already test that top counters don't move backwards, but we don't seem to actually guarantee it. |
| Comments |
| Comment by Charlie Swanson [ 30/Jun/17 ] |
|
Summarizing comments above and some of my own investigation: Most (maybe all?) of the top recording goes through helpers in db_raii.h/cpp, where we use a Timer to track the elapsed milliseconds. This timer uses the system tick source, which is sometimes monotonically increasing, but sometimes subject to move backwards/forwards if the clock was changed for some reason. If we want to avoid weird reporting problems when the system time is changed, we'd have to guarantee usage of a monotonically increasing clock. There are three things attached to the global service context: a TickSource, a precise ClockSource, and a fast ClockSource. It's my understanding that none of these guarantee a monotonically increasing time, so are not suitable if we want to avoid the problem reported here. The proposal is to add a new clock source to the service context which is monotonic, then explicitly using that clock source for the Timer object on the AutoStatsTracker in db_raii.h. This seems like a lot of work for not that much gain (relatively), so the query team has decided to move this to the backlog. |
| Comment by Githook User [ 03/Nov/16 ] |
|
Author: {u'username': u'jbreams', u'name': u'Jonathan Reams', u'email': u'jbreams@mongodb.com'}Message: |
| Comment by Githook User [ 03/Nov/16 ] |
|
Author: {u'username': u'jbreams', u'name': u'Jonathan Reams', u'email': u'jbreams@mongodb.com'}Message: SERVER-26812 Don't check that time moves forward in top stats when we don't guarantee it |
| Comment by Andy Schwerin [ 28/Oct/16 ] |
|
This might actually be a "fix the test" scenario. I mean, what if instead of setting the clock backwards, the user inadvertently set the clock forwards several hours. That would make any operations running during that period to look like they took several hours when they did not. This seems at least as bad as the operations taking negative time, but there's not really anything we can do about it without detecting clock adjustments. Because these counters are only used for reporting and not for waiting, it might be reasonable to use the monotonic clock instead. However, if we do this, we should attach a monotonic clock source to the ServiceContext and use that, to make it easier to mock and test. |