Uploaded image for project: 'Core Server'
  1. Core Server
  2. SERVER-102742

Consider having longer-running operations yield more

    • Query Execution
    • None
    • None
    • None
    • None
    • None
    • None
    • None

      There are many cases where the server becomes overloaded and unresponsive due to long running queries. It may make sense to introduce a policy to have longer running queries yield more often or for longer, so that they take a smaller fraction of the overall system resources at any time, allowing shorter running operations to complete.

      Ideally this would only be necessary when the system is under overload already, but as another option would be to have query plans dynamically change their yielding configuration as the query runtime increases or as the number of concurrent operations increases. Right now all queries yield every 10ms, regardless of how many document's they've scanned or how many iterations they've done.

      Such a policy would mean we're assuming shorter running operations are more important than long running ones. This isn't obviously true all the time, but it may be a useful heuristic. More broadly, scheduling is a well studied problem (see "niceness" in linux) and we may want to draw from prior art there.

      This ticket is mainly for investigation/discussion, and the specific tasks would be:

      • Determine whether this is something we'd want by discussions with product and people involved in workload management
      • Determine where such a policy would exist. It could be built into the server, but some form of it could potentially be built outside the server as well, especially if the server is hit with many long-running operations
      • Ticket out and approve remaining work

            Assignee:
            Unassigned Unassigned
            Reporter:
            ian.boros@mongodb.com Ian Boros
            Votes:
            0 Vote for this issue
            Watchers:
            7 Start watching this issue

              Created:
              Updated:
              None
              None
              None
              None