現在、3 つのサーバーが実行されており、2 つのリモート、メイン サーバーが実行MySQL 5.5.24され、バックアップが実行MySQL 5.1.63され、1 つのローカルMySQL 5.5.20が開発用に実行されています。メイン サーバーはレポート目的で使用されます。現在、144 個のテーブル (MyISAMおよびInnoDB) と約 80 GB のデータがあり、大きなテーブルにはそれぞれ約 1,300 万行あります。
リモートサーバーでは、webmin を介したアクセスが非常に制限されているため、直接変更を加えることができないため、IT 部門に依頼する必要があります。
先月発生した MySQL のクラッシュ以来、メイン サーバーで重大なパフォーマンスの問題が発生しています。サーバーは、いくつかのディスク書き込みバグを含む開発リリースを実行していました。回復後、MySQL 5.5.23バージョンをインストールしたところ、パフォーマンスの問題が発生しました。最近インストールしましMySQL 5.5.24た (最新の安定バージョン) が、まだパフォーマンスの問題があります
サーバー構成は次のとおりです。すべて専用サーバーです。
メイン:
Operating system: Gentoo Linux
Kernel and CPU: Linux 2.6.31-gentoo-r6 on x86_64
Processor information: Intel(R) Xeon(TM) CPU 2.66GHz, 8 cores
Real memory (ram): 23.55 GB total
Virtual memory: 3.74 GB total
Local disk space: 463.38 GB total (about 30% free)
バックアップ:
Operating system: Gentoo Linux
Kernel and CPU: Linux 2.6.31-gentoo-r6 on x86_64
Processor information: Intel(R) Core(TM)2 Duo CPU E6405 @ 2.13GHz, 2 cores
Real memory (ram): 15.68 GB total
Virtual memory: 16.01 GB total
Local disk space: 4.73 TB total (about 80% free)
開発:
Operating system: Ubuntu Linux 9.04
Kernel and CPU: Linux 2.6.32-33-server on x86_64
Processor information: Intel(R) Core(TM)2 Duo CPU E6550 @ 2.33GHz, 2 cores
Real memory (ram): 1.95 GB total
Virtual memory: 5.65 GB total
Local disk space: 141.15 GB total (about 5% free)
すべてのサーバーの my.cnf 構成は同じです。innodb_buffer_pool_size
my.cnf
[mysqld]
back_log = 50
max_connections = 100
max_connect_errors = 10
table_open_cache = 2048
max_allowed_packet = 16M
binlog_cache_size = 1M
max_heap_table_size = 64M
read_buffer_size = 2M
read_rnd_buffer_size = 16M
sort_buffer_size = 8M
join_buffer_size = 8M
thread_cache_size = 8
thread_concurrency = 8
query_cache_size = 64M
query_cache_limit = 2M
ft_min_word_len = 4
default-storage-engine = MYISAM
thread_stack = 262K
stored_program_cache= 1024
transaction_isolation = REPEATABLE-READ
tmp_table_size = 64M
binlog_format=mixed
slow_query_log
long_query_time = 2
key_buffer_size = 512M
bulk_insert_buffer_size = 64M
myisam_sort_buffer_size = 128M
myisam_max_sort_file_size = 10G
myisam_repair_threads = 1
myisam_recover
innodb_additional_mem_pool_size = 16M
innodb_buffer_pool_size = 8G
innodb_data_file_path = ibdata1:10M:autoextend
innodb_write_io_threads = 8
innodb_read_io_threads = 8
innodb_thread_concurrency = 16
innodb_flush_log_at_trx_commit = 1
innodb_log_buffer_size = 8M
innodb_log_file_size = 256M
innodb_log_files_in_group = 3
innodb_max_dirty_pages_pct = 90
innodb_lock_wait_timeout = 240
server-id = 1
event_scheduler = 1
[mysqldump]
quick
max_allowed_packet = 16M
[mysql]
no-auto-rehash
[myisamchk]
key_buffer_size = 512M
sort_buffer_size = 512M
read_buffer = 8M
write_buffer = 8M
[mysqlhotcopy]
interactive-timeout
[mysqld_safe]
open-files-limit = 8192
多数の列とデータを使用していくつかの大規模なものを試しましたがStored Procedures、バックアップ サーバーはメイン サーバーよりも約 10 倍高速であり、開発サーバーでそれらを実行すると、メイン サーバーよりも約 5 倍高速です。
メイン サーバーとバックアップ サーバーは同じリモート ロケーションにあり、VPN を介しているため、接続速度の問題がないことがわかっています。
コードを投稿することはできませんが、すべての一時テーブルの作成が非常に高速であるためStored Procedures、問題が最終段階にあることはわかっています。ほとんどの場合、複数の結合を使用して大量のデータを処理します。SELECTSHOW FULL PROCESSLISTSELECTStored Procedures
メインサーバーが最も強力であるにもかかわらず、パフォーマンスが非常に悪い理由はありますか?
最新バージョンの報告されたパフォーマンスのバグを探していますが、見つかったものはまったく役に立ちませんでしたhttp://bugs.mysql.com/bug.php?id=44585
どんな助けにも本当に感謝します
この質問は、サーバーの障害時に尋ねた方がよいでしょうか? 初めての質問です
私の英語でごめんなさい。