Repères de vitesse de transaction pour la réplication mySQL v5.6 - semble très lent

Question

J'essaie de sélectionner la meilleure configuration pour notre nouvelle infrastructure, mais je suis un peu confus quant aux résultats.

J'ai utilisé sysbench v0.5 pour les tests:

préparer les données

 sysbench --test=/usr/share/doc/sysbench/tests/db/oltp.lua \ --oltp-test-mode=complex --oltp-table-size=1000000 \ --mysql-db=mydb --mysql-user=root --mysql-password=mypassword prepare

faites le test

 sysbench --test=/usr/share/doc/sysbench/tests/db/oltp.lua \ --oltp-test-mode=complex --oltp-table-size=1000000 --oltp-read-only=off \ --num-threads=6 --max-time=60 --max-requests=0 \ --mysql-db=mydb --mysql-user=root --mysql-password=mypassword run

Comme vous pouvez le voir sur les résultats ci-dessous, la réplication maître-maître (percona avec 3 machines) a eu les pires performances, puis vient la configuration maître-esclave mySQL (2 machines) et la plus rapide est mySQL en tant que serveur autonome unique.

Est-ce la situation normale avec des solutions de réplication? Cela semblait tellement lent, une différence de 10x entre les configurations me semble anormale. Peut-être que je manque quelque chose ... J'ai été totalement déçu par Percona Galera Cluster, il a la réputation d'être rapide pour innodb. Phew :)

Veuillez vérifier les informations fournies ci-dessous et conseiller, merci.

À propos des serveurs

Matériel

Intel® Xeon® E5-1650 v2 Hexa-Core
64 Go de RAM ECC
2 x 240 Go 6 Go/s SSD Datacenter Edition (Software-RAID 1)
Bande passante 1 Gbit/s

OS

Debian Wheezy
Tous les packages mis à jour/mis à niveau.

Connexion etc.

Les serveurs sont dans le même centre de données, tous connectés avec un commutateur Gbit et disposent de deuxièmes cartes Ethernet, toutes configurées pour un réseau privé entre elles.
Actuellement, il n'y a pas de charge sur les serveurs.

Performances du disque

premier test

# hdparm -Tt /dev/sda /dev/sda: Timing cached reads: 27166 MB in 2.00 seconds = 13599.63 MB/sec Timing buffered disk reads: 1488 MB in 3.00 seconds = 495.64 MB/sec

deuxième test

# dd if=/dev/zero of=/tmp/output bs=8k count=10k; rm -f /tmp/output 10240+0 records in 10240+0 records out 83886080 bytes (84 MB) copied, 0.0517404 s, 1.6 GB/s

/etc/my.cnf Configuration

L'assistant de Percona a été utilisé pour les configurations initiales.
J'ai utilisé les manuels/sites Web officiels et d'autres sources fiables pour apprendre et configurer la réplication.
InnoDB a été utilisé pour le moteur de stockage par défaut (la table de test créée par sysbench est également InnoDB)

Percona XtraDB v5.6 Galera Cluster: my.cnf pour le premier nœud

[client] port = 3306 socket = /var/run/mysqld/mysqld.sock [mysqld_safe] socket = /var/run/mysqld/mysqld.sock Nice = 0 [sst] streamfmt=xbstream [xtrabackup] # compress # compact parallel=8 compress-threads=8 rebuild-threads=8 [mysqld] wsrep_node_name=db1 # Path to Galera library wsrep_provider=/usr/lib/libgalera_smm.so # Cluster connection URL wsrep_cluster_address=gcomm://192.168.1.4,192.168.1.5,192.168.1.6 # This changes how |InnoDB| autoincrement locks are managed and is a requirement for Galera innodb_autoinc_lock_mode=2 # Node #1 address wsrep_node_address=192.168.1.4 # SST method wsrep_sst_method=xtrabackup-v2 # Cluster name wsrep_cluster_name=my_cluster # Authentication for SST method wsrep_sst_auth="replicateuser:replicateuserpassword" # GENERAL # user = mysql default_storage_engine = InnoDB socket = /var/run/mysqld/mysqld.sock pid_file = /var/run/mysqld/mysqld.pid # Rolandomysqldba's recommendation innodb_thread_concurrency = 0 innodb_read_io_threads = 64 innodb_write_io_threads = 64 # MyISAM # key_buffer_size = 32M myisam_recover_options = FORCE,BACKUP # SAFETY # max_allowed_packet = 16M max_connect_errors = 1000000 skip_name_resolve sysdate_is_now = 1 innodb = FORCE # DATA STORAGE # datadir = /var/lib/mysql/ # BINARY LOGGING # log_bin = /var/lib/mysql/mysql-bin expire_logs_days = 14 sync_binlog = 1 # CACHES AND LIMITS # tmp_table_size = 32M max_heap_table_size = 32M query_cache_type = 0 query_cache_size = 0 max_connections = 500 thread_cache_size = 50 open_files_limit = 65535 table_definition_cache = 4096 table_open_cache = 8K # INNODB # innodb_flush_method = O_DIRECT innodb_log_files_in_group = 2 innodb_log_file_size = 512M innodb_flush_log_at_trx_commit = 1 innodb_file_per_table = 1 innodb_buffer_pool_size = 42G # LOGGING # long_query_time = 5 log_error = /var/log/mysql/error.log log_queries_not_using_indexes = 1 slow_query_log = 1 slow_query_log_file = /var/log/mysql/slow.log [mysqldump] quick quote-names max_allowed_packet = 16M [isamchk] key_buffer = 16M

Résultats du test Sysbench

mySQL v5.6.21 (Single)

transactions: 101001 (1683.29 per sec.)

mySQL v5.6.21 répliqué (maître + 1 esclave)

Maître et esclave en ligne

transactions: 10501 (174.95 per sec.)

L'esclave était hors ligne, la synchronisation binlog était désactivée

transactions: 11280 (187.86 per sec.)

Slave était déconnecté

transactions: 10779 (179.55 per sec.)

Avec retard maître à esclave (1 h)

transactions: 10595 (176.48 per sec.)

MariaDB v5.5 (simple)

transactions: 73683 (1228.00 per sec.)

Percona XtraDB v5.6 Galera Cluster (3 Master-Master, xtrabackup-v2)

Maître (nœud initial)

transactions: 703 (11.65 per sec.)

Tester sur un autre nœud

transactions: 643 (10.67 per sec.)

Modification de la méthode de réplication en rsync

transactions: 652 (10.80 per sec.)

RolandoMySQLDBA · Answer

Vous devez tout mettre sur un pied d'égalité. Comment ?

Sans un réglage correct, il est possible que les anciennes versions de MySQL dépassent et dépassent les nouvelles versions.

Avant d'exécuter SysBench sur les trois environnements

Assurez-vous que tous les paramètres InnoDB sont identiques pour tous les serveurs DB
Pour le maître/esclave, exécutez STOP SLAVE; sur l'esclave
Pour PXC (Percona XtraDB Cluster), arrêtez deux Masters

Comparez les vitesses de MySQL, Percona et MariaDB autonomes.

UNE ANALYSE

Si MySQL est le meilleur (les gens de Percona, ne me jetez pas de légumes pourris pour l'instant. Ce n'est qu'une conjecture), exécutez START SLAVE;. Exécutez SysBench sur le maître/esclave. Si les performances sont considérablement plus lentes, vous devrez peut-être implémenter la réplication semi-synchrone.

Si PXC est le meilleur, vous devrez peut-être régler les paramètres wsrep ou le réseau lui-même.

Si MariaDB est le meilleur, vous pouvez passer à MariaDB Cluster (si vous avez l'argent) ou configurer Master/Slave avec MariaDB. Exécutez Sysbench. Si les performances sont considérablement plus lentes, vous devrez peut-être régler les paramètres wsrep ou le réseau lui-même.

Pourquoi régler les paramètres wsrep? Gardez à l'esprit que Galera wsrep (réplication WriteSet) utilise des validations et des annulations virtuellement synchrones. En d'autres termes, tous les nœuds sont validés ou tous les nœuds sont annulés. Dans ce cas, le maillon le plus faible devrait être

la rapidité de la communication entre les nœuds (particulièrement vrai si les nœuds se trouvent dans des centres de données différents)
si un nœud a des paramètres matériels sous-configurés
si un nœud communique plus lentement que l'autre nœud

Note latérale: Vous devez également vous assurer de régler MySQL pour plusieurs processeurs

Jun 01, 2012: J'ai 16 Go de RAM, comment dois-je configurer MySQL Server?
May 07, 2012: Performances du serveur MySQL
Apr 26, 2012: Les performances du processeur sont-elles pertinentes pour un serveur de base de données?
Mar 16, 2012: tilisation de plusieurs cœurs pour des requêtes MySQL uniques sur Debian
Oct 07, 2011: Dois-je utiliser un moteur de stockage autre que MyISAM pour optimiser ces tables ou dois-je obtenir de meilleurs disques?
Sep 20, 2011: Multi-cœurs et performances MySQL
Sep 12, 2011: Possible de faire en sorte que MySQL utilise plusieurs cœurs?
May 26, 2011: À propos des performances des bases de données monothread et multithread

MISE À JOUR 2014-11-04 21:06 EST

Veuillez garder à l'esprit que Percona XtraDB Cluster n'écrit pas très bien l'échelle pour commencer. Notez ce que le la documentation indique sous ses inconvénients (deuxième inconvénient) :

Cela ne peut pas être utilisé comme une solution efficace de mise à l'échelle en écriture. Il peut y avoir des améliorations dans le débit d'écriture lorsque vous exécutez le trafic d'écriture sur 2 nœuds par rapport à tout le trafic sur 1 nœud, mais vous ne pouvez pas en attendre beaucoup. Toutes les écritures doivent encore être effectuées sur tous les nœuds.

SUGGESTION # 1

Pour PXC, désactivez un nœud. Exécutez SysBench sur un cluster à deux nœuds. Si les performances d'écriture sont meilleures qu'un cluster à trois nœuds, il est évident que la communication entre les nœuds est le goulot d'étranglement.

SUGGESTION # 2

J'ai remarqué que vous disposez d'un pool de mémoire tampon de 42 Go, soit plus de la moitié de la RAM du serveur. Vous devez partitionner le pool de tampons en définissant innodb_buffer_pool_instances à 2 ou plus. Sinon, vous pouvez vous attendre à des échanges.

SUGGESTION # 3

Votre innodb_log_buffer_size est de 8M par défaut. Essayez d'en faire 256 Mo pour augmenter les performances d'écriture du journal.

SUGGESTION # 4

Votre innodb_log_file_size est 512M. Essayez d'en faire 2G pour augmenter les performances d'écriture du journal. Si vous appliquez ce paramètre, définissez innodb_log_buffer_size à 512 Mo.

cenk · Answer

Je mettrai à jour mes progrès et d'autres choses que j'ai découvertes ci-dessous.

Vérification de /etc/init.d/mysql

mySQL commence par cela

su - mysql -s /bin/sh -c "/usr/bin/mysqld_safe > /dev/null 2>&1 &"

Le journal des erreurs a montré que la directive 65535 open_files_limit n'a pas réussi. Simplement, l'utilisateur mysql n'a pas pu fixer ses propres limites.

Augmentation des nofiles ulimit pour tous les utilisateurs (activation de open_files_limit)

Vérifier l'allocation actuelle sur Debian

su mysql -s /bin/sh -c "ulimit -a"

/etc/security/limits.conf

# Added these * soft nofile 65535 * hard nofile 65535 * soft nproc 10240 * hard nproc 10240

/etc/pam.d/su

# Find and uncomment the following: session required pam_limits.so

Réglage Sysctl sur tous les serveurs

Ajouté à /etc/sysctl.conf et fait sysctl -p

#mo swap vm.swappiness = 0 kernel.sysrq = 0 net.core.somaxconn = 65535 net.ipv4.conf.default.rp_filter=1 net.ipv4.tcp_syncookies = 1 net.ipv4.tcp_tw_recycle = 1 net.ipv4.tcp_congestion_control = cubic net.ipv4.tcp_keepalive_time = 900 net.ipv4.tcp_keepalive_intvl = 60 net.ipv4.tcp_keepalive_probes = 15 # Increase system file descriptor limit fs.file-max = 100000 # Discourage swap vm.swappiness = 0 # Increase ephermeral IP ports net.ipv4.ip_local_port_range = 1024 65535 # Increase Linux autotuning TCP buffer limits # Set max to 16MB for 1GE and 32M (33554432) or 54M (56623104) for 10GE # Don't set tcp_mem itself! Let the kernel scale it based on RAM. net.core.rmem_max = 16777216 net.core.wmem_max = 16777216 net.core.rmem_default = 16777216 net.core.wmem_default = 16777216 net.core.optmem_max = 40960 net.ipv4.tcp_rmem = 4096 87380 16777216 net.ipv4.tcp_wmem = 4096 65536 16777216 # Make room for more TIME_WAIT sockets due to more clients, # and allow them to be reused if we run out of sockets # Also increase the max packet backlog net.core.netdev_max_backlog = 65535 net.ipv4.tcp_max_syn_backlog = 30000 net.ipv4.tcp_max_tw_buckets = 2000000 net.ipv4.tcp_tw_reuse = 1 net.ipv4.tcp_fin_timeout = 10 # Disable TCP slow start on idle connections net.ipv4.tcp_slow_start_after_idle = 0 # If your servers talk UDP, also up these limits net.ipv4.udp_rmem_min = 8192 net.ipv4.udp_wmem_min = 8192 # Disable source routing and redirects net.ipv4.conf.all.send_redirects = 0 net.ipv4.conf.all.accept_redirects = 0 net.ipv4.conf.all.accept_source_route = 0 # Log packets with impossible addresses for security net.ipv4.conf.all.log_martians = 1

Statut actuel

 transactions: 113132 (1885.45 per sec.)