web-dev-qa-db-ja.com

MySQLデータベースが使用するCPUが多すぎる

CPUを使いすぎているMySQLデータベースがあります。実際に、データベースにクエリを実行するWebサーバーに対してベンチマークを実行しています。現在、データベースがボトルネックになっているため、CPUを使いすぎています。 VMには5つのvCPUと4GBのメモリがあります。

CPU使用量を減らすためにできる変更はありますか？そして、パフォーマンスを向上させますか？

# * Fine Tuning
#
key_buffer              = 16M
max_allowed_packet      = 16M
thread_stack            = 192K
thread_cache_size       = 8
# This replaces the startup script and checks MyISAM tables if needed
# the first time they are touched
myisam-recover         = BACKUP
#max_connections        = 100
#table_cache            = 64
#thread_concurrency     = 10
#
# * Query Cache Configuration
#
query_cache_limit       = 1M
query_cache_size        = 16M
#
# * Logging and Replication
#
# Both location gets rotated by the cronjob.
# Be aware that this log type is a performance killer.
# As of 5.1 you can enable the log at runtime!
#general_log_file        = /var/log/mysql/mysql.log
#general_log             = 1
#
# Error log - should be very few entries.
#
log_error = /var/log/mysql/error.log
#
# Here you can see queries with especially long duration
#log_slow_queries       = /var/log/mysql/mysql-slow.log
#long_query_time = 2
#log-queries-not-using-indexes
#
# The following can be used as easy to replay backup logs or for replication.
# note: if you are setting up a replication slave, see README.Debian about
#       other settings you may need to change.
#server-id              = 1
#log_bin                        = /var/log/mysql/mysql-bin.log
expire_logs_days        = 10
max_binlog_size         = 100M
#binlog_do_db           = include_database_name
#binlog_ignore_db       = include_database_name
#
# * InnoDB
innodb_buffer_pool_size= 1000000000

[mysqldump]
quick
quote-names
max_allowed_packet      = 16M

[mysql]
#no-auto-rehash # faster start of mysql but no tab completition

[isamchk]
key_buffer              = 16M

MySQLTunerからの出力：

[OK] Logged in using credentials from debian maintenance account.

[--] Skipped version check for MySQLTuner script
[OK] Currently running supported MySQL version 5.5.47-0ubuntu0.12.04.1
[OK] Operating on 64-bit architecture

-------- Storage Engine Statistics -------------------------------------------
[--] Status: +ARCHIVE +BLACKHOLE +CSV -FEDERATED +InnoDB +MRG_MYISAM
[--] Data in InnoDB tables: 695M (Tables: 8)
[!!] Total fragmented tables: 8

-------- Security Recommendations  -------------------------------------------
[OK] There are no anonymous accounts for any database users
[OK] All database users have passwords assigned
[!!] User 'user@%' hasn't specific Host restriction.
[--] There are 605 basic passwords in the list.

-------- CVE Security Recommendations  ---------------------------------------
[--] Skipped due to --cvefile option undefined

-------- Performance Metrics -------------------------------------------------
[--] Up for: 45m 29s (1M q [560.371 qps], 1K conn, TX: 434M, RX: 73M)
[--] Reads / Writes: 100% / 0%
[--] Binary logging is disabled
[--] Total buffers: 1017.0M global + 2.7M per thread (151 max threads)
[OK] Maximum reached memory usage: 1.4G (38.57% of installed RAM)
[OK] Maximum possible memory usage: 1.4G (38.50% of installed RAM)
[OK] Slow queries: 0% (2K/1M)
[!!] Highest connection usage: 100%  (152/151)
[OK] Aborted connections: 0.07%  (1/1442)
[!!] Query cache efficiency: 7.8% (105K cached / 1M selects)
[!!] Query cache prunes per day: 39159937
[OK] Sorts requiring temporary tables: 0% (0 temp sorts / 37K sorts)
[!!] Joins performed without indexes: 6782
[OK] Temporary tables created on disk: 0% (54 on disk / 37K total)
[OK] Thread cache hit rate: 59% (581 created / 1K connections)
[!!] Table cache hit rate: 4% (25 open / 515 opened)
[OK] Open file limit used: 0% (0/1K)
[OK] Table locks acquired immediately: 100% (1M immediate / 1M locks)

-------- MyISAM Metrics ------------------------------------------------------
[!!] Key buffer used: 18.2% (3M used / 16M cache)
[OK] Key buffer size / total MyISAM indexes: 16.0M/98.0K
[!!] Read Key buffer hit rate: 3.9% (128 cached / 123 reads)

-------- InnoDB Metrics ------------------------------------------------------
[--] InnoDB is enabled.
[OK] InnoDB buffer pool / data size: 953.0M/695.3M
[OK] InnoDB buffer pool instances: 1
[OK] InnoDB Used buffer: 97.41% (59413 used/ 60992 total)
[OK] InnoDB Read buffer efficiency: 100.00% (248726755 hits/ 248733105 total)
[OK] InnoDB Write log efficiency: 99.83% (1724316 hits/ 1727328 total)
[OK] InnoDB log waits: 0.00% (0 waits / 3012 writes)

-------- ThreadPool Metrics --------------------------------------------------
[--] ThreadPool stat is disabled.

-------- AriaDB Metrics ------------------------------------------------------
[--] AriaDB is disabled.

-------- TokuDB Metrics ------------------------------------------------------
[--] TokuDB is disabled.

-------- Galera Metrics ------------------------------------------------------
[--] Galera is disabled.

-------- Replication Metrics -------------------------------------------------
[--] No replication slave(s) for this server.
[--] This is a standalone server..

-------- Recommendations -----------------------------------------------------
General recommendations:
    Run OPTIMIZE TABLE to defragment tables for better performance
    Restrict Host for user@% to user@SpecificDNSorIp
    MySQL started within last 24 hours - recommendations may be inaccurate
    Enable the slow query log to troubleshoot bad queries
    Reduce or eliminate persistent connections to reduce connection usage
    Adjust your join queries to always utilize indexes
    Increase table_open_cache gradually to avoid file descriptor limits
    Read this before increasing table_open_cache over 64: http://bit.ly/1mi7c4C
    Beware that open_files_limit (1024) variable
    should be greater than table_open_cache ( 400)
Variables to adjust:
    max_connections (> 151)
    wait_timeout (< 28800)
    interactive_timeout (< 28800)
    query_cache_limit (> 1M, or use smaller result sets)
    query_cache_size (> 16M)
    join_buffer_size (> 128.0K, or always use indexes with joins)
    table_open_cache (> 400)

vmstat出力：

root@database:/home/user# vmstat 1 10
procs -----------memory---------- ---swap-- -----io---- -system-- ----cpu----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa
11  0      0 1264444 156800 1595928    0    0     1    39   33   26  2  2 39  1
14  0      0 1263652 156800 1595928    0    0     0    16 15953 11988 87  7  5  0
 9  0      0 1263584 156800 1595928    0    0     0    16 20043 10770 86  8  5  0
18  0      0 1263696 156800 1595928    0    0     0    16 13679 10370 88  6  6  0
11  0      0 1263728 156800 1595928    0    0     0    16 12920 9972 89  6  5  0
13  0      0 1263696 156800 1595928    0    0     0    16 13454 10560 88  6  6  0
11  0      0 1263544 156800 1595928    0    0     0    20 14192 10877 88  6  6  0
12  0      0 1263556 156800 1595928    0    0     0    88 13901 10417 88  6  5  0
16  0      0 1263428 156800 1595928    0    0     0    16 12457 10490 88  6  6  0
 8  0      0 1263468 156800 1595928    0    0     0    16 12470 10216 89  5  5  0

ご覧のように、データベースのCPUフットプリントは高くなっていますが、Webサーバーは高い使用率を観測していません。 enter image description here

mysqlperformancemysql-5.5database-tuning
2
user3580316

完全なプロセスリストを表示してください。そうすると、インデックスを最適化する必要がある場合は、長時間実行されているクエリがあるかどうかを確認できます（JOINが使用しているフィールドの説明とインデックスの追加を参照）。

クエリキャッシュサイズを増やす必要があります。それは途方もなく低いです（そして制限は途方もなく高いです）...

query_cache_limit = 128K query_cache_size = 128M

またはそれを作ってみる

query_cache_limit = 384K query_cache_size = 512M

ミューテックス/競合の問題はありません。もし持っていれば、CPUが十分に活用されません。

実行時間の長いクエリがなく、qcacheを設定しても効果がない場合は、おそらく通常のサーバーを探す必要があることを意味します。これらのvcpusは遅いですが、インデックスが存在せず、キャッシュが低すぎる可能性があります。

1
Slawek

CPUはほとんどの時間をユーザー空間で費やしています。これは、ロックの問題または非常に非効率的なクエリが原因であると考えられます。

私が行うことは、次の手順を実行し、それぞれの後に問題がまだ存在するかどうかを確認することです。ある場合のみ続行してください。

  1. Query_cacheを無効にします。とにかくそれからあまり多くの利益を得ることはなく、それは一般的な競合ポイントです。

  2. log_queries_not_using_indexesでスロークエリログをオンにして、クエリを分析し、インデックス付けされていない結合を修正します。 mysqltunerの出力から：[!!] Joins performed without indexes: 6782pt-query-digest は、その際に非常に役立ちます。

  3. ミューテックスを見る

    a。）show engine innodb mutex;の出力を確認します

    b。）performance_schemaおよびmutex_instancesテーブルがある場合は、select * from performance_schema.mutex_instances;を確認します。そうでない場合は、セットアップすることを強くお勧めします。

    クエリが相互にロックしている可能性があります。そして、単にセマフォのスピンがCPU時間を使い果たします。潜在的な「侵入者」として表示される明らかなクエリを修正します。この動作の非常に一般的な原因である、更新の選択、重複キー更新のクエリの挿入などを検索できます。

  4. perf top -p [mysql process id]は、mysqlがCPU時間の大部分を費やす場所に関する詳細情報を提供します。このポイントに到達すると、その特定の問題を克服する方法について、より具体的な質問を作成できます。

5
Károly Nagy

CPU使用率が高いということは、クエリの調整が不十分であること、適切なインデックス（特にコンポジット）が不足していること、および/または偽のベンチマークです。

ベンチマークは読み取り専用であるため、QCを上げるとonlyベンチマークにメリットがあります。上げないでください！代わりに、クエリキャッシュをオフにします。さもなければ、書き込みが入ってくると、あなたは苦しむでしょう。 QCが大きいほど、パージに時間がかかります。その間、SELECTはglobal mutexを待機しています。

「断片化されたテーブル」は無視してください。それは偽物です。

152人の同時接続ユーザーがいる場合、それらはおそらくお互いにつまずきます。システムmightは、下限を設定することでより適切に実行されます。そして、それぞれの待ち時間はおそらく改善されます。

あなたのベンチマークは現実的ではないことをお勧めします。これほど多くの同時接続を許可しないでください。

500％CPUは、すべてのCPUが常にビジーであることを意味します。クエリを確認する必要があります。ログの要約が遅いときに戻ってきます。

2
Rick James