-
Type:
Task
-
Resolution: Unresolved
-
Priority:
Major - P3
-
None
-
Affects Version/s: None
-
Component/s: Reconciliation
-
Storage Engines
-
5
-
StorEng - Defined Pipeline
I've been analyzing a customer workload and there is a puzzle in the information I can't understand. Opening this ticket to capture the puzzle and hopefully decode it.
There is a table that has the following set of updating cursor operations:
"cursor" : { "insert calls" : 170103909, "modify" : 0, "remove calls" : 188969693, "reserve calls" : 0, "truncate calls" : 0, "update calls" : 0, }
"reconciliation" : { "approximate byte size of timestamps in pages written" : 10124139424, "approximate byte size of transaction IDs in pages written" : 5062069712, "page reconciliation calls" : 19577238, "page reconciliation calls for eviction" : 18894625, "pages deleted" : 102533, "pages written including an aggregated newest start durable timestamp " : 693836, "pages written including an aggregated newest stop durable timestamp " : 2034996, "pages written including an aggregated newest stop timestamp " : 19821, "pages written including an aggregated newest stop transaction ID" : 19821, "pages written including an aggregated newest transaction ID " : 2595578, "pages written including an aggregated oldest start timestamp " : 319780, "pages written including an aggregated prepare" : 0, "pages written including at least one prepare" : 0, "pages written including at least one start durable timestamp" : 5552041, "pages written including at least one start timestamp" : 5552041, "pages written including at least one start transaction ID" : 5552041, "pages written including at least one stop durable timestamp" : 12629383, "pages written including at least one stop timestamp" : 12629383, "pages written including at least one stop transaction ID" : 12629383, "records written including a prepare" : 0, "records written including a start durable timestamp" : 130693718, "records written including a start timestamp" : 130693718, "records written including a start transaction ID" : 130693718, "records written including a stop durable timestamp" : 502064996, "records written including a stop timestamp" : 502064996, "records written including a stop transaction ID" : 502064996 },
There are a few interesting things here, that I'd like to understand better:
- Why are records written including a start timestamp and records written including a start transaction ID identical? I would expect in this MongoDB workload for timestamps to remain valid longer than transaction IDs.
- Why is records written including a stop timestamp so much higher than records written including a start timestamp when the workload has a broadly similar number of insert and remove calls.
- How is records written including a stop timestamp so much higher than "remove calls" when both truncate and reserve are 0