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

Use std::set::upper_bound when calculating the stable timestamp

    • Type: Icon: Bug Bug
    • Resolution: Fixed
    • Priority: Icon: Major - P3 Major - P3
    • 3.6.0-rc0
    • Affects Version/s: None
    • Component/s: Replication
    • Labels:
      None
    • Fully Compatible
    • ALL
    • Repl 2017-09-11, Repl 2017-10-02
    • 0

      Currently the function ReplicationCoordinatorImpl::_calculateStableTimestamp uses std::find_if to search through the list of stable timestamp candidates. The list of stable timestamp candidates is maintained in sorted order, since it is a std::set, however, std::find_if doesn't take advantage of this. Thus, it's performance is linear in the size of the candidates list, and becomes the slowest part of the set stableTimestampForStorage operation if the candidate list grows to some non-trivial size.

      We can optimize this by using the std::set::upper_bound function to calculate the stable timestamp. For a std::set container, upper_bound has logarithmic complexity, and returns the first element in a sorted range that is greater than some given value. If we do something like

      candidates.upper_bound(commitPoint)
      

      we can obtain an iterator to the smallest candidate timestamp that is greater than the commit point. By decrementing this iterator by 1, we can then obtain the greatest timestamp candidate that is less than or equal to the commit point. (This is the basic concept; there are a few edge cases to handle).

      This should be done to address the performance regressions introduced by SERVER-29891.

            Assignee:
            william.schultz@mongodb.com William Schultz (Inactive)
            Reporter:
            william.schultz@mongodb.com William Schultz (Inactive)
            Votes:
            0 Vote for this issue
            Watchers:
            5 Start watching this issue

              Created:
              Updated:
              Resolved: