MySQLの高いCPU使用率をVPSで実行する方法
私は2つのvCore、80 GB SSD、4 GBのメモリ、Ubuntu 18.04、Apache 2.4.29、およびmysqlコミュニティバージョン8.0.20を備えた仮想プライベートサーバー上のWordPressサイトを管理しています。
サーバーでサイトを起動すると、すべてが正常に機能しましたが、データベースのメンテナンス（単純なテーブルの最適化）を実行した直後、プロセッサーの使用率が合計容量の100％に達するまで数秒間高いことに気づき、その後ダウンしました。再び上昇し、それは常にそのようです。サーバーを再起動した後も、CPU使用率が高くなります。
htopコマンドを使用すると、問題が常にmysqlプロセスであることがわかります。
私はmysqlに行ってみましたが、「show processlist」コマンドを使用してすべてが正常に見え、クエリがハングしていません。コマンドをもう一度実行すると、いくつかのWordPress関連クエリが表示されますが、コマンドを再度実行すると、クエリは正常に完了します。
ただし、投稿の保存、公開、投稿リストのクエリ、投稿の削除などのクエリの実行には非常に長い時間がかかります。 10秒から20秒ですが、ホームページにも時間がかかります。
私はキャッシュプラグインとCDNを使用しています。サイトは問題ありませんが、何かがおかしいです。
すべてのプラグインとテーマを無効にしてみましたが、CPUが急上昇し続けています。
テスト期間中、私は何年も使用していた「リビジョンを削除した後にデータベースを最適化」をオンにしました。 46のpingbackリンクを17分削除しようとしましたが、クエリは正常に完了しました。
ここで注意すべき最大のことは、サイトがUbuntu 16.04および古いバージョンのmysqlとApacheを備えた同様のハードウェア仕様で実行される前に、プロセッサが汗をかいたことがない（CPUが決して高くない）ことです。
調査に費やしている間、プロセッサの使用率が高いことがデータベースの問題であると考えていましたが、今はそれがmysql構成の問題である可能性があると考えていました。
たとえば、/etc/mysqlフォルダ内には、conf.dおよびmysql.conf.dフォルダとDebian.cnf、my.cnf.fallback、mysql.cnfを含む2つのフォルダと4つのファイルがあります。ファイル、およびmy.confファイルがありますが、これは/etc/alternatives/my.cnfを指すシンボリックリンクで、/etc/mysql/mysql.cnfを指します。
Inside the conf.d/mysql.cnf file, the content appears as followed:
# The MySQL Client configuration file.
#
# For explanations see
# http://dev.mysql.com/doc/mysql/en/server-system-variables.html
[mysql]
Mysql.cnf内には、次の内容が含まれています。
# The MySQL Server configuration file.
#
# For explanations see
# http://dev.mysql.com/doc/mysql/en/server-system-variables.html
# * IMPORTANT: Additional settings that can override those from this file!
# The files must end with '.cnf', otherwise they'll be ignored.
#
!includedir /etc/mysql/conf.d/
!includedir /etc/mysql/mysql.conf.d/
最後に、mysql.conf.d内には、テキストを含むmysqld.cnfファイルのみが表示されます。
#
# The MySQL Server configuration file.
#
# For explanations see
# http://dev.mysql.com/doc/mysql/en/server-system-variables.html
[mysqld]
pid-file = /var/run/mysqld/mysqld.pid
socket = /var/run/mysqld/mysqld.sock
datadir = /var/lib/mysql
log-error = /var/log/mysql/error.log
重要：以下のコンテンツは、問題のある新しいサーバーではなく、古いサーバーからのものです。新しいサーバーに構成がないことを指摘するために、以下で言及しています。以下の設定を使用して問題を修正できます。
これらの構成を確認した後、古い構成の1つを調べてmysql構成ファイルを確認することにしました。これを確認しました。
以下のコンテンツでは、この投稿を少し短くするためにコメントをいくつか省略しました。
# Here is entries for some specific programs
# The following values assume you have at least 32M ram
[mysqld_safe]
socket = /var/run/mysqld/mysqld.sock
Nice = 0
[mysqld]
#
# * Basic Settings
#
user = mysql
pid-file = /var/run/mysqld/mysqld.pid
socket = /var/run/mysqld/mysqld.sock
port = 3306
basedir = /usr
datadir = /var/lib/mysql
tmpdir = /tmp
lc-messages-dir = /usr/share/mysql
skip-external-locking
#
# Instead of skip-networking the default is now to listen only on
# localhost which is more compatible and is not less secure.
bind-address = 127.0.0.1
#
# * Fine Tuning
#
key_buffer_size = 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-options = 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
これらは今私の質問です：
- MysqlでのCPU使用率が高いのは、新しいサーバーが古いサーバーのように構成されていないためです。
- Mysql設定を正しく確認しましたか？ （
/etc/my.cnfはできませんでした。） - 問題が構成にある場合、古い
mysqld.cnfを新しいサーバーで使用できますか？ Ubuntu 18.04とmysql 8を実行する新しいサーバーと互換性があるということですか？ - 誰かがこのmysqlの問題に対して他の提案や解決策を提供できますか？
key_buffer_sizeはMyISAMを意味します。あなたが圧倒的に正当な理由がない限り（そして2020年にはそうでないことはほぼ確実です）、MyISAMに使用しないでください。
query_cacheはほとんどの場合、害よりも害を及ぼします。そのため、MySQL 8.0では完全に削除されています。セットする：
query_cache_type = 0
query_cache_size = 0
1）mysqldのCPU使用率が高いことが、構成によって引き起こされることはほとんどありません。これは通常、クエリとインデックス作成の不良が原因です。
そうは言っても-innodb_buffer_pool_sizeの明示的な設定はないようです。これは、そのサイズの専用ではないサーバーではおそらく約2GBに設定する必要があります。データが非常に小さい場合を除きます。データの大きさは？
2）はい。
3）ほとんど。一部のオプションは廃止され、削除される可能性があります。 mysqldで認識されなくなったオプションは、通常、起動に失敗し、構成から削除する必要があります。
4）有効にする
slow_query_log = 1
long_query_time = 0
ログの24時間をキャプチャします。大きくなります。 mysqldumpslowまたはpt-query-digestを使用して処理します。遅いクエリを特定し、可能な場合はより適切にインデックスを作成するか、必要に応じてパフォーマンスの高い形式に書き換えます。
サーバーで、今日の0 GBから6 GBのスワップ領域を有効にすることを検討してください。
Linuxコマンドプロンプトでulimit -n 20000を入力し、Enterキーを押して、OSによる追加のオープンファイルを有効にします。現在、ulimit -aレポートごとに1024に制限されています。これは動的に適用され、再起動は必要ありません。 MySQLの次の停止/開始で使用できるようになります。
OSのシャットダウン/再起動後もこれを永続的にするには、このガイドに従い、20000を使用します。例は500000です。 https://glassonionblog.wordpress.com/2013/01/27/increase-ulimit-and-file -descriptors-limit /
htop2は、多くのmysqld PIDが数分間占有され、通常はスリープ状態であることを示します。一般的なログ分析により、このパターンが存在する理由を特定できます。
1秒あたりのレート= RPS
My.cnf [mysqld]セクションで検討すべき提案
thread_cache_size=100 # from 9 to reduce threads_created count (expensive operation)
innodb_io_capacity=1900 # from 200 to use more of your SSD io capacity
read_rnd_buffer_size=128K # from 256K to reduce handler_read_rnd_next RPS of 97
read_buffer_size=256K # from 128K to reduce handler_read_next RPS of 1,744
観察、4日間のcom_create_tableは、325,788のテーブルがどのような目的で3,284のRPhrを作成したことを示していますか？ 4日間に削除されたテーブルは報告されませんでした。
482のSelect_scan RPhrは、インデックスが欠落していることを示します。 FAQページにはQが含まれています。インデックスを使用していないJOINSまたはQUERIESを見つけるにはどうすればよいですか？分析と解決を支援するため。
サイトのパフォーマンスを向上させる機会は他にもあります。時間が許せば連絡してください。