it-swarm.com.de

Benchmarks für die Transaktionsgeschwindigkeit für die Replikation von mySQL v5.6 - scheint sehr langsam zu sein

Ich versuche, die beste Konfiguration für unsere neue Infrastruktur auszuwählen, bin aber etwas verwirrt über die Ergebnisse.

Ich habe sysbench v0.5 für die Tests verwendet:

Daten vorbereiten

 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

mache den 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

Wie Sie den Ergebnissen unten entnehmen können, hatte die Master-Master-Replikation (Percona mit 3 Computern) die schlechteste Leistung, dann kommt die mySQL-Master-Slave-Konfiguration (2 Computer) und die schnellste ist mySQL als einzelner Standalone-Server.

Ist dies die normale Situation bei Replikationslösungen? Es schien so verdammt langsam zu sein, dass der 10-fache Unterschied zwischen den Konfigurationen für mich ungewöhnlich erscheint. Vielleicht fehlt mir etwas ... Ich war total enttäuscht von Percona Galera Cluster, es hat den Ruf, schnell für innodb zu sein. Puh :)

Bitte überprüfen Sie die unten angegebenen Informationen und beraten Sie, danke.

Über die Server


Hardware

  • Intel® Xeon® E5-1650 v2 Hexa-Core
  • 64 GB ECC-RAM
  • 2 x 240 GB 6 Gbit/s SSD Datacenter Edition (Software-RAID 1)
  • 1 Gbit/s Bandbreite

Betriebssystem

  • Debian Wheezy
  • Alle Pakete aktualisiert/aktualisiert.

Verbindung etc.

  • Die Server befinden sich im selben Rechenzentrum, alle sind mit einem Gbit-Switch verbunden und verfügen über zweite Ethernet-Karten, die alle für die private Vernetzung zwischen ihnen konfiguriert sind.

  • Derzeit sind die Server nicht belastet.

Festplattenleistung

erster 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

zweiter 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 Konfiguration

  • Perconas Assistent wurde für die Erstkonfigurationen verwendet.

  • Ich habe die offiziellen Handbücher/Websites und andere zuverlässige Quellen verwendet, um die Replikation zu lernen und zu konfigurieren.

  • InnoDB wurde für die Standardspeicher-Engine verwendet (die von sysbench erstellte Testtabelle ist auch InnoDB).

Percona XtraDB v5.6 Galera Cluster: my.cnf für den ersten Knoten

[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

Sysbench-Testergebnisse


mySQL v5.6.21 (Single)

transactions: 101001 (1683.29 per sec.)

mySQL v5.6.21 repliziert (Master + 1 Slave)

Master und Slave online

transactions: 10501  (174.95 per sec.)

Slave war offline, Binlog-Synchronisierung war deaktiviert

transactions: 11280  (187.86 per sec.)

Der Sklave war offline

transactions: 10779  (179.55 per sec.)

Mit Master-Slave-Verzögerung (1 Std.)

transactions: 10595  (176.48 per sec.)

MariaDB v5.5 (Single)

transactions: 73683  (1228.00 per sec.)

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

Master (Anfangsknoten)

transactions: 703    (11.65 per sec.)

Test auf einem anderen Knoten

transactions: 643    (10.67 per sec.)

Ändern der Replikationsmethode in rsync

transactions: 652    (10.80 per sec.)
6
cenk

Sie sollten alles auf gleiche Wettbewerbsbedingungen stellen. Wie ?

Ohne die richtige Abstimmung ist es älteren Versionen von MySQL möglich, neue Versionen zu überholen und zu übertreffen.

Vor dem Ausführen von SysBench in den drei Umgebungen

  • Stellen Sie sicher, dass alle InnoDB-Einstellungen für alle DB-Server identisch sind
  • Führen Sie für den Master/Slave STOP SLAVE; auf dem Slave
  • Fahren Sie für PXC (Percona XtraDB Cluster) zwei Master herunter

Vergleichen Sie die Geschwindigkeiten von MySQL, Percona und MariaDB.

ANALYSE

Wenn MySQL am besten ist (Percona-Leute, bitte werfen Sie noch kein verdorbenes Gemüse auf mich. Dies ist nur eine Vermutung), führen Sie START SLAVE;. Führen Sie SysBench auf dem Master/Slave aus. Wenn die Leistung erheblich langsamer ist, müssen Sie möglicherweise eine semisynchrone Replikation implementieren.

Wenn PXC am besten ist, müssen Sie möglicherweise die wsrep-Einstellungen oder das Netzwerk selbst anpassen.

Wenn MariaDB am besten ist, können Sie zu MariaDB Cluster (wenn Sie das Geld haben) wechseln oder Master/Slave mit MariaDB einrichten. Führen Sie Sysbench aus. Wenn die Leistung erheblich langsamer ist, müssen Sie möglicherweise die wsrep-Einstellungen oder das Netzwerk selbst anpassen.

Warum wsrep Einstellungen einstellen? Beachten Sie, dass Galera wsrep (WriteSet Replication) praktisch synchrone Commits und Rollbacks verwendet. Mit anderen Worten, entweder alle Knoten werden festgeschrieben oder alle Knoten werden zurückgesetzt. In diesem Fall müsste das schwächste Glied sein

  • wie schnell die Kommunikation zwischen Knoten erfolgt (insbesondere, wenn sich die Knoten in verschiedenen Rechenzentren befinden)
  • wenn ein Knoten unterkonfigurierte Hardwareeinstellungen hat
  • wenn ein Knoten langsamer kommuniziert als der andere Knoten

Randnotiz: Sie sollten auch sicherstellen, dass MySQL für mehrere CPUs optimiert ist

UPDATE 2014-11-04 21:06 EST

Bitte beachten Sie, dass Percona XtraDB Cluster die Skalierung zunächst nicht sehr gut schreibt. Beachten Sie, was das Dokumentation sagt unter seinen Nachteilen (Zweiter Nachteil) :

Dies kann nicht als effektive Lösung für die Schreibskalierung verwendet werden. Es kann einige Verbesserungen beim Schreibdurchsatz geben, wenn Sie Schreibverkehr auf 2 Knoten gegenüber dem gesamten Verkehr auf 1 Knoten ausführen, aber Sie können nicht viel erwarten. Alle Schreibvorgänge müssen noch auf allen Knoten ausgeführt werden.

VORSCHLAG # 1

Deaktivieren Sie für PXC einen Knoten. Führen Sie SysBench für einen Cluster mit zwei Knoten aus. Wenn die Schreibleistung besser ist als bei einem Cluster mit drei Knoten, ist die Kommunikation zwischen den Knoten offensichtlich der Engpass.

VORSCHLAG # 2

Mir ist aufgefallen, dass Sie einen 42-GB-Pufferpool haben, der mehr als die Hälfte des Arbeitsspeichers des Servers ausmacht. Sie müssen den Pufferpool partitionieren, indem Sie innodb_buffer_pool_instances auf 2 oder mehr setzen. Andernfalls können Sie mit einem gewissen Austausch rechnen.

VORSCHLAG # 3

Ihr innodb_log_buffer_size ist standardmäßig 8M groß. Versuchen Sie es mit 256 MB, um die Leistung beim Schreiben von Protokollen zu erhöhen.

VORSCHLAG # 4

Ihre innodb_log_file_size ist 512M. Versuchen Sie es mit 2G, um die Leistung beim Schreiben von Protokollen zu erhöhen. Wenn Sie diese Einstellung anwenden, setzen Sie innodb_log_buffer_size auf 512M.

2
RolandoMySQLDBA

Ich werde meinen Fortschritt und andere Dinge, die ich unten entdeckt habe, aktualisieren.

Überprüfen von /etc/init.d/mysql

damit beginnt mySQL

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

Das Fehlerprotokoll zeigte, dass die Direktive 65535 open_files_limit nicht erfolgreich war. MySQL-Benutzer konnten einfach keine eigenen Grenzen setzen.

Erhöhen von ulimit-Nofiles für alle Benutzer (Aktivieren von open_files_limit)

Überprüfen der aktuellen Zulage für 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

Systemoptimierung auf allen Servern

Zu /etc/sysctl.conf hinzugefügt und sysctl -p ausgeführt

#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

Aktueller Status

 transactions: 113132 (1885.45 per sec.)
0
cenk