現在300〜600人の同時ユーザーがいる(そして成長している)Facebookアプリを実行しています。ハードウェアを成長させる準備をするために、i7/12GB RAM/2x 80GB Intel x25 ssd(debian 5.0/mysql 5.0/64bit)をbi-xeon/24GB RAM/2x 120GB Intel Intel ssd(ubuntu 10.10/mysql 5.1 /)に変更しました64ビット)。
今、私はパフォーマンスが「小さな箱」よりも悪いという問題に直面しています。両方のサーバーで、コンテンツを提供するためにnginx/php fcgiを使用しています。
私はinnodbのみを使用しており、読み取り/書き込みは約65%/ 35%です。約800-1000 qpsですが、すべてのクエリは単純で、2つ以上の追加テーブルに参加することはありません。すべてのインデックスが設定され、個別のクエリは低速ログ(> 2秒)に記録されません。現時点では、毎月2倍になると予想して約400MBのデータ(インデックス付きで約1GB)を持っています。
それをスムーズに実行するために何を変更するべきかについてのヒントを私に与えることができるすべての人を崇拝します。
I7ボックスの古い構成はこのようなもので(myisamとinnodbの混合)、最大800人以上のユーザーでかなり良好に機能しました。
古いmy.cnf
key_buffer = 3000M
max_allowed_packet = 128M
thread_stack = 192K
thread_cache_size = 8
max_connections = 400
table_cache = 8000
thread_concurrency = 16
query_cache_limit = 8M
query_cache_size = 128M
wait_timeout = 10
interactive_timeout = 10
connect_timeout = 600
low_priority_updates = 1
join_buffer_size = 8M
read_buffer_size = 2M
sort_buffer_size = 3M
myisam_sort_buffer_size = 32M
read_rnd_buffer_size = 4M
innodb_buffer_pool_size = 3G
innodb_log_buffer_size = 8M
Bi-xeonボックスの新しい構成は次のようになり(純粋なinnodb)、300以上のユーザーで高負荷が発生します。プロセスリストの最上位にある約30のmysqlプロセス。
ディスクI/O:
avg-cpu: %user %Nice %system %iowait %steal %idle
36.28 0.00 1.60 0.17 0.00 61.95
my.cnf
key_buffer = 64M
max_allowed_packet = 1M
thread_stack = 192K
thread_cache_size = 128
max_connections = 500
table_cache = 512
#thread_concurrency = 10
sort_buffer_size = 256K
read_buffer_size = 256K
read_rnd_buffer_size = 256K
tmp_table_size = 32M
max_heap_table_size = 32M
query_cache_limit = 1M
query_cache_size = 128M
query_cache_type = 1
innodb_file_per_table = 1
innodb_data_file_path = ibdata1:1000M:autoextend
innodb_buffer_pool_size = 16384M
innodb_additional_mem_pool_size = 8M
innodb_flush_log_at_trx_commit = 1
innodb_support_xa = 0
innodb_lock_wait_timeout = 50
innodb_flush_method=O_DIRECT
innodb_log_files_in_group = 2
innodb_log_file_size = 128M
innodb_log_buffer_size = 8M
innodb_thread_concurrency = 12
StackExchnageにいくつかの投稿を書いた
必要なガイダンスについては、これらをお読みください。
ここで、より差し迫った問題について:400 MBのデータと1 GBのインデックスがあると述べました。そのようなことは、あなたのインデックスがデータより50%大きいことを私に怖がらせます。ただし、すべてのデータがInnoDBであり、現在のクエリパフォーマンスに満足しているため、設定は十分です。特に、16384MBのinnodb_buffer_pool_sizeです。それは16GBです。これで準備は完了です。ちょっと待って !!!あなたのinnodb_log_file_sizeは128Mですか? 16GBのバッファープールを考えると小さすぎます。 ib_logfileファイルのサイズを変更する必要があります(innodb_log_file_sizeを2047Mに設定します)。
スレッドごとに負荷が発生している可能性があります。接続バッファ(join_buffer_size、sort_buffer_size、read_buffer_size、read_rnd_buffer_size)を設定してみてください
From Me: なぜMySQLはメモリ不足だと言っているのですか?
@DTestから: mysql max_connections変数をどのように計算しますか?
試してみる !!!
innodb_flush_log_at_trx_commit = 1
= 2
の使用を検討してください。max_connections
-SHOW GLOBAL STATUS LIKE 'max_used_connections'
クエリキャッシュ:
query_cache_size = 128M
query_cache_type = 1
これらは痛いかもしれません。上記、たとえば、50M
の場合、QCはメンテナンスに多くの時間を費やしています。それをON
にすることも無駄かもしれません。 SHOW GLOBAL STATUS LIKE 'Qc%'
を実行して、有効性を確認します。