Uploaded image for project: 'WiredTiger'
  1. WiredTiger
  2. WT-8123

Examine performance of validating the update chain in reconciliation

    XMLWordPrintable

    Details

    • Type: Improvement
    • Status: Closed
    • Priority: Major - P3
    • Resolution: Gone away
    • Affects Version/s: None
    • Fix Version/s: None
    • Component/s: None
    • Labels:
      None
    • Story Points:
      5
    • Sprint:
      Storage - Ra 2021-10-04

      Description

      BF-22597 shows a 27% performance improvement for Test: ycsb_50read50update within Task: ycsb_60GB.  A graph of the drop can be seen in the BF ticket (or at here and select ycsb_50read50update with measurement "Data - disk xvde disk written (writes/s) - mean")

      The improvement corresponds to the merge of the single ticket WT-7853, that ticket keeps a list of updates during reconciliation in order to accurately tag them with WT_UPDATE_DS or not.

      Originally we thought this was a performance degradation, so I made this suggestion, which we still might consider:  A guess about the performance drop are the new calls to __wt_calloc and __wt_free.  We might look into using scratch memory (__wt_scr_alloc_ and __wt_scr_free ) if the list is created and freed in a single thread, or possibly allocating/extending an array of WT_UPDATE_CACHE items instead of one at a time.

      I'm leaving this ticket open to consider this change and also to make sure we understand the performance improvement.

        Attachments

        1. image-2021-09-30-15-13-26-788.png
          image-2021-09-30-15-13-26-788.png
          171 kB
        2. LatestVsWT-7853.png
          LatestVsWT-7853.png
          901 kB

          Activity

            People

            Assignee:
            haseeb.bokhari Haseeb Bokhari
            Reporter:
            donald.anderson Donald Anderson
            Votes:
            0 Vote for this issue
            Watchers:
            4 Start watching this issue

              Dates

              Created:
              Updated:
              Resolved: