A recent change affecting the sys-perf evergreen project has caused 34 regressions and 1 improvement across 16 tests in 3 tasks for 1 measurement. Overall, no high value workloads were affected.

Commit info - 16a7913, 2026-02-05

All performance metrics, tasks and tests that have been affected as a result of this change can be found in this:

• Full list of change points for this BF (view the summary tab for aggregate data on this BF)

Some example change points that occurred are:

• Regression: 33.46% in ops_per_sec for Task compound_wildcard_index_write_commands in Test [CWI.remove] Compound Wildcard index with 2 fields, one of which is multikey. Collection size 100000 docs.
• Regression: 32.68% in ops_per_sec for Task compound_wildcard_index_write_commands in Test [CWI.remove] Compound Wildcard index with 2 fields, one of which is multikey. Collection size 100000 docs.
• Regression: 25.31% in ops_per_sec for Task compound_wildcard_index_write_commands in Test [CWI.remove] Compound Wildcard index with 2 fields, one of which is multikey. Collection size 100000 docs.
• Regression: 25.25% in ops_per_sec for Task compound_wildcard_index_write_commands in Test [CWI.remove] Compound Wildcard index with 2 fields, one of which is multikey. Collection size 100000 docs.
• Regression: 24.40% in ops_per_sec for Task compound_wildcard_index_write_commands in Test [CWI.remove] Compound Wildcard index with 2 fields, one of which is multikey. Collection size 100000 docs.

Note: Metadata and source location for affected workloads can be found by hovering over the data points in the trends charts

Please reach out to #ask-devprod-performance or #perf-build-baroning if you need help running workloads.

Some helpful links:

• Performance workloads documentation
• Analyzing Performance of Code Changes
• Guide to Metrics Reported by Performance Tests
• Guide for Investigating a Performance Change
• Guide for Validating a Performance Change
• Guide for Investigating Binary Layout Issues

When closing this ticket, please populate the 'Fix revision' field if appropriate.

The root cause of the regression is that WT-16605 starts to set the WT_BTREE_IN_MEMORY flag for the in-memory databases. By accident, it turns off the updates eviction for in-memory databases. Previously, the WT_BTREE_IN_MEMORY flag was only set for the ingest btrees in the disaggregated storage. Due to unknown reason, we turned off updates eviction for that. However, in-memory btrees should be allowed to do updates eviction as reconciliation will reconcile the updates to the disk image and remove the updates from the update chains. Fix the issue by allowing updates eviction for in-memory btrees.