[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:
Depends
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: SERVER-23976 SERVER-26812 fix clang format
Branch: master
https://github.com/mongodb/mongo/commit/3d0f477cb2466a386a4f1fe5d020f4801f79ef78

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
Branch: master
https://github.com/mongodb/mongo/commit/0bac17d6a2950613b5e9793dd1aa328bc4a3b5e3

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.

Generated at Thu Feb 08 04:13:17 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.