web-dev-qa-db-ja.com

低メモリ使用量高CPU mysqld

中〜高トラフィックのサーバーを管理しています。

wordpressウェブサイトを提供します。

それは多くのCPU(いくつかの時点で300%以上)を使用し、常にメモリ使用量の約15%をスタックしているようです。

これは、nginxおよびphp7-fpmの下でのInnoDBエンジンを備えたMySQL 5.7サーバーです。

サーバーには16GB RAM

私はmysqltunerで調整しようとしましたが、それは役に立ちません

ここに私のmysqld.cnfがあります

[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     = 64M
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        = 192M
query_cache_type        = 1
innodb_buffer_pool_size = 10G

#
# * 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/lib/mysql/Ubuntu-1604-xenial-64-minimal-slow.log
slow_query_log_file     = /var/log/mysql/mysql-slow.log
slow_query_log          = 1
#long_query_time = 5
#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 is enabled by default with a 10MB datafile in /var/lib/mysql/.
# Read the manual for more InnoDB related options. There are many!
#
# * Security Features
#
# Read the manual, too, if you want chroot!
# chroot = /var/lib/mysql/
#
# For generating SSL certificates I recommend the OpenSSL GUI "tinyca".
#
# ssl-ca=/etc/mysql/cacert.pem
# ssl-cert=/etc/mysql/server-cert.pem
# ssl-key=/etc/mysql/server-key.pem

上記で何を調整するか教えてください

敬具

更新

問題は解決されましたが、現在のサーバーでは解決されませんでした。 VPSのイメージを作成し、別の仮想マシンをリクエストしました。それを新しいサーバーにコピーして問題を解決しました。最初のマシンに障害のあるハードドライブがあったことしか想像できません。

Mysqlのスロークエリログをデバッグした後、彼が提案したように、報告されたすべてのスロークエリは意味をなさないことがわかったため、@ Rick Jamesの答えを正解として受け入れました。

1
fat_mike

クエリキャッシュに非効率があります。

query_cache_size        = 192M

これを50Mに変更します。

これは、チューニングが「ハイCPU」に役立つ数少ないケースの1つです。通常、インデックスとクエリの公式を確認する必要があります。そう...

遅いテーブルをいくつか見つけて、関係するテーブルのSHOW CREATE TABLEEXPLAIN SELECT ...を提示してください。その後、この議論を続けることができます。

ああ、いいね; slowlogがすでにオンになっており、long_query_timeに役に立たない値があることがわかります。 1に変更します。 1日後、pt-query-digest(またはmysqldumpslow -s t)を使用して「最悪」のクエリを見つけます。

1
Rick James