新しいインフラストラクチャに最適な構成を選択しようとしていますが、結果について少し混乱しました。
テストにはsysbench v0.5を使用しました。
データの準備
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
テストを実行
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
以下の結果からわかるように、マスターマスターレプリケーション(3台のマシンのpercona)は最悪のパフォーマンスを示し、次にmySQLマスター-スレーブ(2台のマシン)構成になり、単一のスタンドアロンサーバーとして最速のmySQLになります。
これはレプリケーションソリューションの通常の状況ですか?それはとてもすごく遅いようでした、構成間の10倍の違いは私にとって異常に見えます。多分私は何かが足りない...私はPercona Galera Clusterに完全に失望しました、それはinnodbに対して高速であるという評判があります。ふew :)
以下の情報を確認してアドバイスをお願いします。
サーバーは同じデータセンターにあり、すべてGbitスイッチに接続されており、2つ目のイーサネットカードがあり、すべてサーバー間のプライベートネットワーク用に構成されています。
現在、サーバーに負荷はありません。
最初のテスト
# 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
2回目のテスト
# 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
Perconaのウィザードは、初期構成に使用されました。
レプリケーションを学び、構成するために、公式マニュアル/ウェブサイトおよびその他の信頼できるソースを使用しました。
InnoDBがデフォルトのストレージエンジンに使用されました(sysbenchによって作成されたテストテーブルもInnoDBです)
[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
transactions: 101001 (1683.29 per sec.)
マスターとスレーブオンライン
transactions: 10501 (174.95 per sec.)
スレーブがオフラインで、binlog同期がオフでした
transactions: 11280 (187.86 per sec.)
スレーブはオフラインでした
transactions: 10779 (179.55 per sec.)
マスターからスレーブへの遅延あり(1時間)
transactions: 10595 (176.48 per sec.)
transactions: 73683 (1228.00 per sec.)
マスター(初期ノード)
transactions: 703 (11.65 per sec.)
別のノードでテストする
transactions: 643 (10.67 per sec.)
レプリケーション方式をrsyncに変更する
transactions: 652 (10.80 per sec.)
あなたはすべてを平等な競争の場に置くべきです。どうやって ?
適切なチューニングを行わないと、MySQLの古いバージョンが新しいバージョンを追い越し、打ち負かす可能性があります。
Sep 25, 2013
: XtraDBとMariaDBの代わりにInnoDBとMySqlを使用する必要があるのはなぜですか?Mar 26, 2012
: Percona vs MySQLNov 24, 2011
: mysql 5.5が5.1より遅い理由(linux、mysqlslapを使用)Oct 05, 2011
: 一部の新しいMySQLバージョンではクエリが長時間実行されますJun 19, 2011
: MySQLベイクオフを適切に実行する方法3つの環境でSysBenchを実行する前に
STOP SLAVE;
を実行しますスタンドアロンのMySQL、Percona、およびMariaDBの速度を比較します。
MySQLが最良の場合(Perconaの人々、腐った野菜はまだ私に投げないでください。これは単なる推測です)、START SLAVE;
を実行します。マスター/スレーブでSysBenchを実行します。パフォーマンスが著しく遅い場合は、準同期レプリケーションを実装する必要がある場合があります。
PXCが最適な場合は、wsrep設定またはネットワーク自体を調整する必要がある場合があります。
MariaDBが最適な場合は、 MariaDBクラスター (お金がある場合)に切り替えるか、MariaDBでマスター/スレーブを設定します。 Sysbenchを実行します。パフォーマンスが著しく遅い場合は、wsrep設定またはネットワーク自体を調整する必要がある場合があります。
Wsrep設定を調整する理由Galera wsrep(WriteSet Replication)は、実質的に同期的なコミットとロールバックを使用することに注意してください。つまり、すべてのノードがコミットするか、すべてのノードがロールバックします。この場合、最も弱いリンクは
注意:MySQLを複数のCPUに合わせて調整する必要もあります。
Jun 01, 2012
: 16GBのRAMを持っています。MySQLサーバーをどのように構成すればよいですか?May 07, 2012
: MySQLサーバーのパフォーマンスApr 26, 2012
: CPUパフォーマンスはデータベースサーバーに関連していますか?Mar 16, 2012
: Debianでの単一のMySQLクエリに複数のコアを使用Oct 07, 2011
: MyISAM以外のストレージエンジンを使用してこれらのテーブルを最適化する必要がありますか、それともより優れたディスクを取得する必要がありますか?Sep 20, 2011
: マルチコアとMySQLパフォーマンスSep 12, 2011
: MySQLで複数のコアを使用することは可能ですか?May 26, 2011
: シングルスレッドデータベースとマルチスレッドデータベースのパフォーマンスについてPercona XtraDBクラスターは、そもそもスケールをあまりうまく書けないことに注意してください。 ドキュメントがその欠点の下で言っていることに注意してください(2番目の欠点) :
これは、効果的な書き込みスケーリングソリューションとしては使用できません。 2つのノードへの書き込みトラフィックを実行すると、1つのノードへのすべてのトラフィックに対して書き込みスループットが向上する可能性がありますが、それほど期待できません。すべての書き込みは、引き続きすべてのノードで実行する必要があります。
PXCの場合は、1つのノードをオフにします。 2ノードクラスタに対してSysBenchを実行します。書き込みパフォーマンスが3ノードクラスタよりも優れている場合、ノード間の通信がボトルネックであることは明らかです。
サーバーのRAMの半分以上の42GBのバッファープールがあることに気づきました。 innodb_buffer_pool_instances を2以上に設定して、バッファープールをパーティション化する必要があります。それ以外の場合は、スワッピングが予想されます。
innodb_log_buffer_size はデフォルトで8Mです。 256Mにすると、ログ書き込みパフォーマンスが向上します。
innodb_log_file_size は512Mです。 2Gにすると、ログの書き込みパフォーマンスが向上します。この設定を適用する場合は、 innodb_log_buffer_size を512Mに設定します。
以下で発見した進捗状況やその他の情報を更新します。
mySQLはこれで始まります
su - mysql -s /bin/sh -c "/usr/bin/mysqld_safe > /dev/null 2>&1 &"
エラーログは、65535 open_files_limitディレクティブが成功しなかったことを示しました。単に、mysqlユーザーは独自の制限を設定できませんでした。
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
/etc/sysctl.confに追加され、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
transactions: 113132 (1885.45 per sec.)