I do see DBINs since as I said, my writes are guaranteed to be duplicates. But, I see that INs and BINs dominate the size of the log. That confuses me since, BIN should not be dirtied at all, in my case since I only change the duplicate tree rooted from DIN.When you said "My workload always does put() for an existing key" I thought you meant you were doing an update. Do you mean you're inserting a new record for a key that already exists?
Does a change to a DBIN also propagate up to the BIN and the IN??Yes, it does, due to both (2) and (4) above.
I see that its checkpointing roughly 1.2 times per sec.That's an awful lot of checkpointing but still I don't understand why you're not seeing any BIN deltas at all. Could you post your env config?
Checkpointer logs the dirtied entries, whereas the cleaner logs the "live" entries from a stale file. Just want to confirm that the migration by the cleaner, will indeed be factored in by the checkpointer to determine when to checkpoint..Correct.
More migration means more frequent checkpoints and more checkpoints mean more frequent cleaner runs (not necessarily migration), right?Correct. You may want to bump the checkpoint interval way up and turn off high priority checkpoints -- obviously you don't need this setting to avoid long checkpoints. The byte interval supersedes the wakeup interval.
When I do the print log on the entire set of JDB files, I do see BINDeltas. Its only in the later files (which correspond to the writes I was talking about), that I don't see them.Oh, so you do see deltas. Perhaps it's just that in the last section the writes are dirtying more than 25% of the entries per BIN. (see EnvironmentConfig.TREE_BIN_DELTA)