-
Type:
Task
-
Resolution: Done
-
Affects Version/s: None
-
Component/s: None
-
Labels:None
@agorrod, this is the best fix I can come up with for the cache dirty-bytes problem.
I think you're the best reviewer.
The commit explains what I did.
My primary concern is we could fall far enough behind (because we're not reconciling the page), that the cache would have a seriously incorrect count of dirty bytes. Could that happen in a new tree, where we're just frantically inserting new data?
If that's a problem, I was thinking of doing something like this:
diff --git a/src/include/btree.i b/src/include/btree.i index aa63fe0..45428fd 100644 --- a/src/include/btree.i +++ b/src/include/btree.i @@ -282,6 +282,8 @@ __wt_page_modify_init(WT_SESSION_IMPL *session, WT_PAGE *page) static inline void __wt_page_only_modify_set(WT_SESSION_IMPL *session, WT_PAGE *page) { + int64_t diff; + /* * We depend on atomic-add being a write barrier, that is, a barrier to * ensure all changes to the page are flushed before updating the page @@ -300,6 +302,20 @@ __wt_page_only_modify_set(WT_SESSION_IMPL *session, WT_PAGE *page) */ if (F_ISSET(&session->txn, TXN_RUNNING)) page->modify->disk_snap_min = session->txn.snap_min; + } else { + /* + * Make sure the cache's dirty-byte information for this page + * isn't too far from reality -- if we're off by more than 10%, + * fix it. + */ + diff = page->memory_footprint - + page->modify->last_memory_footprint; + if (diff < 0) + diff = -diff; + if (diff > (int64_t)page->memory_footprint / 10) { + __wt_cache_dirty_decr(session, page); + __wt_cache_dirty_incr(session, page); + } } }