This improves performance significantly for environments constrained by
calls to sync() such as HDDs or lower-end SSDs (or just very busy
environments running many queries)
By default the the queries from other nodes are only processed with
1 thread, which means they will always run slower than on the master and
any long running query will hold up all other queries behind it.
Additionally, when multiple queries commit at once the server can
combine them together into a single on-disk sync ('group commit') which
is not possible otherwise. This optimisation appears to only occur on
Bionic (Percona 5.7) and not Xenial (Percona 5.6).
On Bionic, default to 48 threads which experimentally is a good number
for OpenStack environments without being too crazy high. Galera ensures
that queries that are dependent on each other are still executed
sequentially and generally it is not expected to cause replication
inconsistencies.
However Percona Cluster 5.6 on Xenial appears to have a bug handling
foreign key constraints that causes them to be violated (LP #1823850).
The result is that the slave node crashes out and has to do a full SST
to recover. The same issue is not present on the master. Thus we leave
the default wsrep_slave_threads=1 on Xenial to avoid this issue for now
particularly since Xenial does not appear to be able to use Group Commit
to optimise the number of sync requests generated by the queries - so
this option does not really improve performance there anyway.
Reviewed: https:/ /review. opendev. org/651127 /git.openstack. org/cgit/ openstack/ charm-percona- cluster/ commit/ ?id=0697559b516 66197eecc098561 1ee563c9a70c6d
Committed: https:/
Submitter: Zuul
Branch: master
commit 0697559b5166619 7eecc0985611ee5 63c9a70c6d
Author: Trent Lloyd <email address hidden>
Date: Tue Apr 9 14:30:34 2019 +0800
wsrep_ slave_threads: default to 48 on bionic
This improves performance significantly for environments constrained by
calls to sync() such as HDDs or lower-end SSDs (or just very busy
environments running many queries)
By default the the queries from other nodes are only processed with
1 thread, which means they will always run slower than on the master and
any long running query will hold up all other queries behind it.
Additionally, when multiple queries commit at once the server can
combine them together into a single on-disk sync ('group commit') which
is not possible otherwise. This optimisation appears to only occur on
Bionic (Percona 5.7) and not Xenial (Percona 5.6).
On Bionic, default to 48 threads which experimentally is a good number cies.
for OpenStack environments without being too crazy high. Galera ensures
that queries that are dependent on each other are still executed
sequentially and generally it is not expected to cause replication
inconsisten
However Percona Cluster 5.6 on Xenial appears to have a bug handling threads= 1 on Xenial to avoid this issue for now
foreign key constraints that causes them to be violated (LP #1823850).
The result is that the slave node crashes out and has to do a full SST
to recover. The same issue is not present on the master. Thus we leave
the default wsrep_slave_
particularly since Xenial does not appear to be able to use Group Commit
to optimise the number of sync requests generated by the queries - so
this option does not really improve performance there anyway.
Partial-Bug: #1822903 e52aa3d26fea53b a7c2bbdc771
Change-Id: Ic9cdd6562f30a3