The reason they're running slow is because the default in the wiredtiger_open call for transaction_sync is enabled=false,method=fsync. By setting enabled=false the log writes should not be synchronous until someone uses a transaction with sync=true. With enabled=false, the WT_LOG_FLUSH flag is cleared. But with method=fsync we set WT_LOG_FSYNC in the connection's txn_logsync field.

The code in txn.i causes the txn to inherit the connection's setting and then modifies it based on the sync configuration in __wt_txn_config. If WT_LOG_FLUSH is not set and sync isn't true then we clear the txn_logsync field.

However, that is not what is happening in the case of auto-transactions. The code inherits from the connection only, therefore, WT_LOG_FSYNC is set in the txn. The reason is that auto-transactions always send in a NULL cfg and the code never calls __wt_txn_config at all. Therefore the field is never cleared in this default case.

I have a fix I'm testing.

With this change, I'm getting 50000 ops/sec, versus 400 ops/sec before.

FTR, I wondered why, with this change, the Jenkins plot didn't change at all for the log-append job. The reason is that although the individual job appears to use all the defaults in that config file, Jenkins overall sets an environment variable that turns off all syncing via transaction_sync=(method=none) for all jobs. Took me a while to understand why my identically configured AWS box was behaving different than the Jenkins job.

Author:

Message: If we have no config, explicitly check for flushing and clear
txn_logsync. WT-1949
Branch: develop
https://github.com/wiredtiger/wiredtiger/commit/d6f8320a2e5c6fcb665dd1b744dfe0474a8fb431