-
Type:
Task
-
Resolution: Done
-
None
-
Affects Version/s: None
-
Component/s: None
-
None
Running 1, 2, and 8 threads with the Remove.v2.IntId test shows a 90% slowdown between 1 and 8 threads. Most often I see a 50% slowdown between 1 and 2 threads. Running pmp, I almost never catch any thread in WT during the 1-thread run. With 8 threads, I always see 7 out of 8 yielding in __wt_page_in_func. (This is with btree, logging off.)
Here's typical output:
5 sched_yield,__wt_page_in_func,__wt_row_search,__wt_btcur_search_near,__curfile_search_near,mongo::WiredTigerIndex::IndexCursor::_locate,mongo::WiredTigerIndex::IndexCursor::locate,mongo::BtreeBasedAccessMethod::findSingle,
2 sched_yield,__wt_page_in_func,__wt_row_search,__wt_btcur_remove,__curfile_remove,mongo::WiredTigerIndexUnique::_unindex,mongo::WiredTigerIndex::unindex,mongo::BtreeBasedAccessMethod::removeOneKey,mongo::BtreeBasedAccessMethod::remove,mongo::IndexCatalog::_unindexRecord,mongo::IndexCatalog::unindexRecord,mongo::Collection::deleteDocument,
1 __rec_row_leaf_insert,__rec_row_leaf,__wt_rec_write,__rec_review,__wt_rec_evict,__wt_evict_page,__wt_page_in_func,__wt_row_search,__wt_btcur_search_near,__curfile_search_near,mongo::WiredTigerIndex::IndexCursor::_locate,mongo::WiredTigerIndex::IndexCursor::locate,mongo::BtreeBasedAccessMethod::findSingle,
I turned on stats logging and added a bunch of stats in __wt_page_in_func to see why and the reason is that the page is locked, all the time:
Oct 27 17:04:54 4788 /home/sue/work/mongo/data/db pgin: pgin calls Oct 27 17:04:54 12203 /home/sue/work/mongo/data/db pgin: busy hazard pointer Oct 27 17:04:54 77425947 /home/sue/work/mongo/data/db pgin: busy locked Oct 27 17:04:54 0 /home/sue/work/mongo/data/db pgin: busy reading Oct 27 17:04:54 77340108 /home/sue/work/mongo/data/db pgin: yield calls
Notice that, on average, each call to the page in function resulted in over 16K calls to yield (and other stat periods showed even higher per-call averages).
- is related to
-
- Closed