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

Dump detailed cache information via statistics

    • Type: Icon: Task Task
    • Resolution: Done
    • Priority: Icon: Major - P3 Major - P3
    • WT2.9.0, 3.2.11, 3.4.0-rc2
    • Affects Version/s: None
    • Component/s: None
    • Labels:
    • Storage Engines
    • Storage 2016-10-31

      There are cases when it would be very useful to be able to see what the cache looks like. It'd be nice if we could expose that via the statistics cursor API. Something like:

      session->open_cursor(session,  "statistics:cache:", NULL, NULL, &cursor)
      

      I'm not sure how the information would be best returned. Possibly each page in the cache gets a set of statistics including:

      • Page type
      • Memory footprint
      • URI of file it belongs to
      • Dirty size
      • Number of deleted entries
      • Flags settings
      • Number of entries
      • Number of updates for leaves
      • Number of children for internal pages
      • How many overflow references there are on the page
      • Whether there are overflow keys
      • Whether the page has been split
      • Whether the page was created in memory or has a backing disk image

      It would be expensive to gather this information, and somewhat difficult due to the system changing while walking the in-memory tree. It could be very helpful in diagnosing issues related to eviction and cache usage.

      Ideally it would be possible to correlate parent/child relationships. Maybe print out a parent reference identifier and an identifier for each page being dumped.

      There is a function called

      Unable to find source-code formatter for language: __wt_cache_dump```. Available languages are: actionscript, ada, applescript, bash, c, c#, c++, cpp, css, erlang, go, groovy, haskell, html, java, javascript, js, json, lua, none, nyan, objc, perl, php, python, r, rainbow, ruby, scala, sh, sql, swift, visualbasic, xml, yaml
       in 

      src/eviction/evict_lru.c{{`}} that walks in-memory pages and dumps cache information to disk - it could be a starting point.

      A search on such a cursor would probably be a no-op, only traversal would be allowed.

            Assignee:
            backlog-server-execution [DO NOT USE] Backlog - Storage Execution Team
            Reporter:
            alexander.gorrod@mongodb.com Alexander Gorrod
            Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

              Created:
              Updated:
              Resolved: