web-dev-qa-db-ja.com

MySQLにより、大量のサーバーリソースが残された状態で平均負荷が高くなる

アプリケーションを実行している2台のサーバーがあり、mysql sgbdを実行するサーバーの負荷平均はWebサーバーの約3倍です。サーバーに多くのリソース（RAM）が残っているので、それは何かおかしいと思います。負荷平均は約3〜4で、サーバーはその応答時間を増やしています。 _mysqltuner.pl_の出力は次のとおりです。

_[--] Up for: 9h 10m 55s (42M q [1K qps], 4M conn, TX: 19B, RX: 6B)
[--] Reads / Writes: 94% / 6%
[--] Total buffers: 10.2G global + 6.6M per thread (800 max threads)
[OK] Maximum possible memory usage: 15.4G (49% of installed RAM)
[OK] Slow queries: 0% (5K/42M)
[OK] Highest usage of available connections: 36% (294/800)
[OK] Key buffer size / total MyISAM indexes: 100.0M/34.8M
[!!] Key buffer hit rate: 73.3% (45K cached / 12K reads)
[!!] Query cache is disabled
[OK] Sorts requiring temporary tables: 0% (2K temp sorts / 3M sorts)
[OK] Temporary tables created on disk: 0% (54 on disk / 52K total)
[OK] Thread cache hit rate: 99% (478 created / 4M connections)
[!!] Table cache hit rate: 0% (400 open / 78K opened)
[OK] Open file limit used: 0% (3/4K)
[OK] Table locks acquired immediately: 100% (37M immediate / 37M locks)
[OK] InnoDB buffer pool / data size: 10.0G/1.0G
[OK] InnoDB log waits: 0
_

サーバー設定（注：このサーバーは_mysql server_のみを実行します）：

  • Intel Xeon E5-2620v3（6コア-12スレッド）
  • 2x 16GB DDR4-2133 ECC（合計：32GB）
  • 2x 256 GB SSD 2.5インチ（RAID1）

このサーバー構成に基づいて、my.cnfに最適なオプションがあるかどうか疑問に思っています。サーバー構成と_mysqltuner.pl_出力に基づいてこれを更新するための提案があるかどうか知りたいです。これが私の_my.cnf_です：

_skip-external-locking
skip-name-resolve
lower_case_table_names          = 1

wait_timeout                    = 4
interactive_timeout             = 15

key_buffer_size                 = 100M
join_buffer_size                = 4M

max_allowed_packet              = 1M
thread_stack                    = 256K
thread_cache_size               = 250

myisam-recover                  = BACKUP
max_connections                 = 800

#Qcache not enabled due to high tax of inserts/updates
query_cache_limit               = 1M
query_cache_type                = 0
query_cache_size                = 0

log_error = /var/log/mysql/error.log

log_slow_queries                = /var/log/mysql/mysql-slow.log
long_query_time                 = 1

expire_logs_days                = 10
max_binlog_size                 = 100M

join_buffer_size                = 4M

tmp_table_size                  = 30M
max_heap_table_size             = 30M

#InnoDB config's
innodb_commit_concurrency       = 0
innodb_io_capacity              = 90000
innodb                          = ON
innodb_flush_method             = O_DIRECT
innodb_file_per_table           = 1
innodb_flush_log_at_trx_commit  = 2
innodb_doublewrite              = 1
innodb_additional_mem_pool_size = 64M
innodb_thread_concurrency       = 12
innodb_log_file_size            = 512M
innodb_log_buffer_size          = 24M
innodb_read_io_threads          = 12
innodb_buffer_pool_size         = 10G
innodb_write_io_threads         = 12
innodb_log_files_in_group       = 2
_

注：my.cnfの一部の不要なパラメーターを非表示にしています。

[〜＃〜]更新[〜＃〜]

私は_Mysql Server 5.5_を使用していますが、_table_open_cache_を増やしました（投稿の瞬間のデフォルト値は_64_です）。 mysql tuneがテーブルキャッシュについて説明すると、次の行が表示されます。

_[OK] Table cache hit rate: 99% (1K open / 1K opened)
_

ENGINEポイントについては、87個のテーブルがあり、そのうち11個のみがMyISAM（データベース全体の12％+これらのテーブルは「選択/挿入」テーブル）であり、他のテーブルはすべてInnoDB（select/insert/updateの高額税込み）。私のシステムにはDELETE句がありません。代わりに、削除されたことを示すフラグを行に設定します（そのため、ビジーでないときに削除できます）。多くのクエリ（特にSelect count(*)のようなクエリ）の実行に1.5秒、2秒以上かかっています。

_innodb_io_capacity_について、サーバーディスクはすべて100.000IOPSのSSDです。

mysqlinnodbmysql-5.5mysqltuner
1
BigBlast

MyISAMを使用していますか？またはInnoDB？または両方？

[!!]クエリキャッシュが無効になっています

これは「良い」であり、「悪い」ではありません。

[!!]テーブルキャッシュヒット率：0％（400オープン/ 78Kオープン）

あなたはいくつのテーブルを持っていますか？何千？なぜそんなに多くなのか詳しく説明してください。 （これは通常、設計上の欠陥です。）一方、_table_open_cache_を、たとえば_2000_に増やします。どのMySQLバージョンを実行していますか？十分に新しいバージョンの場合は、_table_open_cache_instances = 8_を設定します。

[OK]利用可能な接続の最大使用率：36％（294/800）

ある意味で「OK」です。しかし、別の意味では、294の同時接続は大量です。詳しく説明してください。おそらく彼らは切断に失敗していますか？

[-]最大：9時間
[OK]クエリが遅い：0％（5K/42M）
平均負荷は約3〜4です
long_query_time = 1

それらの種類は互いに矛盾しています。私の意見では、「負荷平均」はあまり役に立ちません。 CPU使用率の測定値はありますか？それでも、CPUが高い場合、1秒以上かかるクエリが増えないのはなぜですか？とにかく、pt-query-digestを実行して、最初に見つかったクエリをいくつか見てみましょう。それらをスピードアップできるかもしれません。それはシステムをスピードアップするかもしれません。

更新

更新していただきありがとうございます。

InnoDBテーブルのSELECT COUNT(*)はテーブルのサイズに比例するため、徐々に遅くなります。 slowlogは、どれが頻繁に実行されて迷惑になるかを指摘します。

SSDと十分なキャッシング（key_buffer、buffer_pool、table_open_cache）と_innodb_flush_log_at_trx_commit = 2_の間で、I/Oを最小化している可能性があります。スローログに焦点を当てます。

1
Rick James

リック・ジェームスはそれをかなりうまくカバーしました、私はただ一つを追加したいです：

[!!] Query cache is disabled
[--] Reads / Writes: 94% / 6% - and [1K qps]

私にとっては、クエリキャッシュを有効にする可能性があるようですが、クエリに大きく依存します-多くのクエリに動的条件（最新のものを取得するための日時/タイムスタンプ）または同様のものを含める場合、おそらくしないでくださいわざわざ。しかし、これらの読み取りクエリの多くが各接続で同じである場合は、それを試してみます-テスト目的でサーバーを再起動せずにQCを有効にできます-それを100MBと言ってしばらくの間有効にしてから、負荷を比較してくださいなし、応答性など、違いがあるかどうかを確認します-QCが知られているスケーラビリティの問題のため、実際には事態が悪化する可能性があるため、テスト中に監視しますが、実稼働サーバーでは小規模ですが測定可能な正の効果。

0
jkavalik