web-dev-qa-db-fra.com

100X moins d'insertion de performances avec Galera Multi-Master

Je gère une application qui insère beaucoup de lignes et que nous vivions de basses performances. J'ai donc commencé à analyser le cluster Galera avec Sysbench et OLTP_INSERT.LUA (insertion pratiquement avec une clé aléatoire).

La performance du cluster est vraiment mauvaise.

Avec le même test:

  • En tant que dB autonome, je peux effectuer environ 35 000 TPS
  • Avec Galera Multi-Master, la performance est: 350 TPS

La structure de la table est celle-ci:

       Table: sbtest1
Create Table: CREATE TABLE `sbtest1` (
  `id` int(11) NOT NULL,
  `k` int(11) NOT NULL DEFAULT '0',
  `c` char(120) NOT NULL DEFAULT '',
  `pad` char(60) NOT NULL DEFAULT '',
  PRIMARY KEY (`id`),
  KEY `k_1` (`k`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1

Ce que j'ai essayé jusqu'à présent (sans succès):

  • augmenter wsrep_slave_threads=16
  • peu importe le nombre de threads de client que j'utilise, le TPS est toujours 350 (on dirait que les transactions sont sérialisées d'une manière ou d'une autre par la DB)
  • ensemble wsrep_sync_wait=0 (Bien que je n'effectue aucune lecture)
  • le DB n'utilise pas Binlog, ce n'est pas activé.

Configuration:

[mysqld]   
binlog_format=ROW   
innodb_autoinc_lock_mode=2    
bind-address=0.0.0.0   
datadir=/var/lib/mysql

innodb_buffer_pool_size = 300MB
innodb_large_prefix=1
innodb_file_format=Barracuda

transaction-isolation = READ-COMMITTED

wsrep_on=ON  
wsrep_provider=/usr/lib64/galera/libgalera_smm.so           
wsrep_slave_threads = 16         
wsrep_max_ws_rows=131072    
wsrep_max_ws_size=1073741824    
wsrep_convert_LOCK_to_trx=0    
wsrep_causal_reads=OFF
wsrep_sst_method=xtrabackup-v2
mysqlgalera
3
mhstnsc

J'ai frappé le même problème. La première chose à faire est de vérifier les variables suivantes:

select @@innodb_flush_log_at_trx_commit;

select @@sync_binlog;

Réglage innoDB_FLUSH_LOG_AT_TRX_COMMIT sur 2 et Sync_Binlog à 0 augmentera considérablement les performances.

La raison est dans le mécanisme de certification et la nature du comportement multi-maîtres. Les inserts seront très lents car afin de commettre le cluster de transaction garantira que tous les journaux sont rinçus au moment de leur engagement à chaque nœud.

Assurez-vous que vos caches fit RAM avec la requête suivante également:

select ((@@thread_stack +@@binlog_cache_size +@@read_buffer_size + @@read_rnd_buffer_size +@@sort_buffer_size +@@join_buffer_size + @@global.net_buffer_length +@@global.query_prealloc_size + @@binlog_stmt_cache_size) * @@max_connections + (@@query_cache_size + @@innodb_buffer_pool_size + @@innodb_log_buffer_size + @@key_buffer_size))/(1024*1024);
2
Ilshat Karazbayev

Galera est plus conçue autour d'une ration de lecture/écriture plus égale au cluster ainsi plus de tests de lecture/écriture serait mieux. Votre Sysbench est également probablement que frapper un nœud du cluster. Peut-être concevoir un test plus proche de votre utilisation attendue.

Pour un insert/changement en vrac, Galera a une limite de contrôle de faible débit qui pourrait être augmentée. SHOW GLOBAL STATUS LIKE 'wsrep%' montrera si vous frappez ceci ou une autre limite.

Options disponibles pour WSREP_PROVIDER_OPTIONS Selon le lien.

Autres options à prendre en compte:

  • gcs.fc_master_slave
  • gcs.recv_q_hard_limit
1
danblack