1

MySQL の復元が遅いと思われるものがあり、チューニングのアドバイスを探しています (私は PostgreSQL と SQL Server の専門家です)。

開発サーバーには、48 GB の RAM、8 コア、Centos 6.2 64 ビットおよび MySQL 5.1.61 (本番環境の MySQL と同じ) を実行し、ソフトウェア管理 RAID-10 / XFS の 4 x 7200 RPM SAS ドライブがあります。唯一の MySQL クライアント プロセスは復元です。ダンプは、本番サーバー上のすべてのデータベースのプレーンな mysqldump で取得されました。

FOREIGN_KEY_CHECKS と UNIQUE_CHECKS をゼロに設定するなど、 http://derwiki.tumblr.com/post/24490758395/loading-half-a-billion-rows-into-mysqlからいくつかのオプションを適用しました。以下に my.cnf を含めました。

mytop と pv (pv backup.sql | mysql -u root -p) を使用して復元を監視すると、INSERT INTO ステートメントが徐々に遅くなり始めているように見えます。mytop で表示される qps は 3 から始まり、ダンプ ファイルによって 60% で 0 に低下します。この場合、3 つの挿入 (値を含む) はまだ遅いように見えるため、mytop がどれほど正確かはわかりません。htop は、MySQL が使用する CPU の CPU 使用率が 10% 未満であり、48 GB の RAM のうち 8 GB 未満しか使用されていないことを示しています。

データベースは異なりますが、復元手法は似ていますが、PostgreSQL を使用すると、同じサーバー上で約 5 ～ 10 倍高速に実行されます。

アイデア？

[mysqld]
# my.cnf
socket=/var/lib/mysql/mysql.sock
user=mysql
symbolic-links=0
slow-query-log
long_query_time = 60
log-slow-admin-statements
slow_query_log_file = /var/log/mysql_slow.log
innodb_buffer_pool_size = 2G
max_allowed_packet = 1G
key_buffer_size = 1G
concurrent_insert = 1
innodb_flush_log_at_trx_commit = 2
bulk_insert_buffer_size = 1G
innodb_flush_method = O_DIRECT
4

1 に答える 1

1

innodb インデックスが速度を落としているようです。データベースのダンプ方法を変更できる場合は、すべての非主キー インデックスを削除してデータをロードし、それらを再度追加します。データが主キーによってロードされるように順序付けすることをお勧めします。これはおそらく多すぎる質問です。

これらのヒントをすでに認識しているようですね: http://dev.mysql.com/doc/refman/5.5/en/optimizing-innodb-bulk-data-loading.html

ディスクへのフラッシュ操作 ( innodb_flush_log_at_trx_commit = 2) が 1 秒間に何度も発生している可能性があります。innodb_log_file_sizeディスクへの頻繁な書き込みを避けるために、 *innodb_log_files_in_groupで十分であることを確認してください。

（設定からInnodbを使用していると仮定しました）

于 2012-06-06T03:44:44.033 に答える