Elena Stepanova added a comment - 2018-04-25 21:48 And still fails http://buildbot.askmonty.org/buildbot/builders/kvm-deb-trusty-amd64/builds/10324/steps/mtr/logs/stdio

Sergei Petrunia added a comment - 2018-10-16 10:02 https://buildbot.askmonty.org/buildbot/builders/kvm-rpm-centos74-amd64-debug/builds/999/steps/mtr/logs/stdio Now with numbers: rocksdb.2pc_group_commit 'write_committed' w2 [ fail ] Test ended at 2018-10-13 23:20:34   CURRENT_TEST: rocksdb.2pc_group_commit --- /usr/share/mysql-test/plugin/rocksdb/rocksdb/r/2pc_group_commit.result 2018-10-13 21:56:11.000000000 +0000 +++ /dev/shm/var/2/log/2pc_group_commit.reject 2018-10-13 23:20:34.235742808 +0000 @@ -44,7 +44,7 @@ select IF(variable_value - @b3 between 1 and 9000, 'OK', variable_value - @b3) from information_schema.global_status where variable_name='Rocksdb_wal_synced'; IF(variable_value - @b3 between 1 and 9000, 'OK', variable_value - @b3) -OK +9434 ## # 2PC enabled, MyRocks durability disabled, single thread ##

Sergei Petrunia added a comment - 2019-07-11 11:29 One can use settings like binlog_commit_wait_count=30 binlog_commit_wait_usec=500K and this will produce more SQL-level commit groups. That is, Binlog_group_commits will show less groups (=more grouping), even when running on a RAM disk. But these settings have no effect on Rocksdb_wal_synced .

Sergei Petrunia added a comment - 2019-07-11 15:04 - edited Added a code to hook to test sync point "DBImpl::WriteImpl:BeforeLeaderEnters" with my_sleep(500) (this is 500 milliseconds). With rocksdb_write_policy=write_prepared, this achieves the desired effect: For 10K queries, 50 threads, and ram disk I get ~750 Binlog_group_commits and 1850 Rocksdb_wal_syncs. Doesn't have much effect for rocksdb_write_policy=write_committed, though.

Sergei Petrunia added a comment - 2019-07-11 15:22 The upstream doesn't watch rocksdb_wal_syncs. They check rocksdb_wal_group_syncs instead. rocksdb_wal_group_syncs is a MyRocks-level (not RocksDB's) counter, it counts rocksdb_flush_wal() calls that the SQL layer's group commit makes.

Sergei Petrunia added a comment - 2019-07-11 16:06 - edited fbmysql-2pc_group_commit-xpl.diff Examining counter increments in the current upstream: ## 2PC + durability + single thread +# --concurrency=1 --number-of-queries=1000 +# WAL_SYNCED WAL_GROUP_SYNCED +# 1000 1000     ## 2PC + durability + group commit +# --concurrency=50 --number-of-queries=10000 +# WAL_SYNCED WAL_GROUP_SYNCED +# 1101 1101 # 2PC enabled, MyRocks durability disabled +# --concurrency=1 --number-of-queries=1000 +# WAL_SYNCED WAL_GROUP_SYNCED +# 1 0   +# --concurrency=50 --number-of-queries=10000 +# WAL_SYNCED WAL_GROUP_SYNCED +# 0 0 # 2PC disabled, MyRocks durability enabled +# --concurrency=1 --number-of-queries=1000 +# WAL_SYNCED WAL_GROUP_SYNCED +# 1000 0     +# --concurrency=50 --number-of-queries=10000 +# WAL_SYNCED WAL_GROUP_SYNCED +# 10000 0 (both write_committed and write_prepared produce similar results)

Sergei Petrunia added a comment - 2019-07-11 16:09 The upstream has smaller WAL_SYNCED with binlog ON (because the SQL layer calls FlushWAL() once per group). with 2PC disabled, they also got 10K WAL_SYNCED even for concurrent workload.

Sergei Petrunia added a comment - 2019-07-11 17:26 Re-running test on the current MariaDB. Using the workload from 2pc_group_commit test: 10K queries, concurrency=50 log_bin=OFF write_committed the workload takes 1.2 sec, Rocksdb_wal_synced=8K enabled rocksdb_enable_delay_commits (500 ms delay): the workload takes same 1.2 sec, Rocksdb_wal_synced=1.2K with write_prepared it's similar: workload time is about the same With rocksdb_enable_delay_commits, Rocksdb_wal_synced goes down from 8K to 750. log_bin=ON write_committed: the workload takes 1.6 sec, Rocksdb_wal_synced=9,600 enabled rocksdb_enable_delay_commits (500 ms delay): 12 seconds. Rocksdb_wal_synced=9,900 write_prepared: the workload takes 1.6 sec, Rocksdb_wal_synced=8,300 enabled rocksdb_enable_delay_commits (500 ms delay): 1.7 seconds, Rocksdb_wal_synced=1,700