web-dev-qa-db-ja.com

MySQLのCPU使用率が高く、RAM使用率が低い

次の仕様があります。

Digital Oceanでホストされている8vCPU/32 GBメモリ/ 160 GBディスク

WebアプリケーションはLaravel（PHP）に基づいて構築されており、現在550人の同時ユーザーにサービスを提供しています。

これらはプロセスです：

17767 mysql     20   0 29.160g 4.160g  18804 S 214.3 13.2  25:55.25 mysqld
20455 www-data  20   0  496504  45364  31252 S  19.9  0.1   0:11.90 Apache2
21849 www-data  20   0  496420  44828  30868 S  10.4  0.1   0:08.25 Apache2
20470 www-data  20   0  494500  43232  31188 S   8.8  0.1   0:09.81 Apache2
 2422 www-data  20   0  496436  41656  27660 R   8.5  0.1   0:02.39 Apache2
29369 www-data  20   0  494324  42960  31048 R   8.5  0.1   0:04.87 Apache2
28830 www-data  20   0  494320  41632  29700 S   8.1  0.1   0:02.57 Apache2
21160 www-data  20   0  496392  44796  30804 S   7.8  0.1   0:08.95 Apache2
20899 www-data  20   0  494424  42572  30552 R   7.2  0.1   0:07.29 Apache2
20971 www-data  20   0  496432  45092  31060 S   6.8  0.1   0:07.21 Apache2
21589 www-data  20   0  496468  44692  30612 S   6.5  0.1   0:06.98 Apache2
32660 www-data  20   0  496520  44816  30796 R   6.5  0.1   0:03.80 Apache2
21650 www-data  20   0  494460  42984  30996 S   5.5  0.1   0:06.84 Apache2
...
...
...

MYSQLからのCPU使用率は214％であり、私の努力のどれもその数を減らすのに役立っていないようです。

Digital Oceanが提供するグラフを見ると、現在の全体的なCPU使用率は合計で80％であり、RAMはわずか25％です。変ですか？ CPUではなく、パフォーマンスに関しては、通常RAMがボトルネックであるという印象を常に持っていました。

これが私のMYSQL設定です

key_buffer_size     = 16M
max_allowed_packet  = 16M
thread_stack        = 192K
thread_cache_size       = 16
myisam-recover-options  = BACKUP
max_connections        = 500
wait_timeout        = 20000
query_cache_limit   = 2M
query_cache_size=0
query_cache_type=0
tmp_table_size = 320M
max_heap_table_size = 320M
log_error = /var/log/mysql/error.log
expire_logs_days    = 10
max_binlog_size   = 100M
innodb_buffer_pool_size=22G
innodb_buffer_pool_instances=22
innodb_log_file_size=5G
innodb_read_io_threads=8G
innodb_write_io_threads=8G

すべてのオプションを使い果たしたような気がします。私は多くのインターネットの投稿を調査しましたが、ハードウェアをより適切に表すためにinnodb_buffer_pool_size、innodb_buffer_pool_instanceなどの多くの変数を調整し、mysqlチューナーを使用し、その推奨事項をすべて実行しました。コードのすべてのビットに何時間も費やし、すべてのクエリとリクエストをログに記録し、低速であり、アプリケーションから生き残るために最適化し、それによって違いも最小限に抑えました。何か足りないものはありますか？それとも、サーバーを強化する必要があるのでしょうか？ 25％のRAM使用率は異常に低いです...

どんな提案も大いに役立ちます。乾杯。

ubuntumysqlapache-2.4central-processing-unit
1
slothinspace

少なくとも出力を投稿する必要があります

完全なプロセスリストを表示;

そしてそこからおそらく遅いクエリロギングを有効にします：

slow_query_log = 1

long_query_time = 0

そしてしばらくしてからの出力を投稿してください：

mysqldumpslow -s t /path/to/slow.log |頭-100

次に、どのクエリがCPUを消費しているかを調べ、CPUの消費を減らすことができるかどうかを確認します。

データベースのパフォーマンスの最適化は、構成が本当に病理学的に間違っていない限り、5％の構成と95％のクエリの最適化です。繰り返しになりますが、mysqltunerがあなたに言ったことを信じていれば、病理学的に間違った設定が考えられます。 8bn ioスレッド...

2
Gordan Bobic

評判が悪いのでコメントできない。私はここに新しいです！しかし、これはコメントと考えてください。

考慮すべきいくつかの事柄。 Inno_buffer_pool_sizeはドキュメントに対して過度であり、ドキュメントによればそうです。 * "バッファープールサイズは常にinnodb_buffer_pool_chunk_size * innodb_buffer_pool_instancesに等しいか、その倍数でなければなりません" *

私は数か月前に同様の問題を抱えていて、考えられるすべてを変更した後、構成ファイル（私の場合は/etc/my.cnf.d/server.cnf）のバックアップコピーを作成してすべてを削除することで最終的に解決しましたbind IPアドレスやポートなどの必須要素を除きます。

Mysqlをリロードした後、問題は解消されたので、新しいのは自分が行った変更の組み合わせでした。各変更を再導入し、元の問題が再発するまで毎回再起動しました。どのオプションだったか思い出せませんが、いじって調整しました。

スワッピングが問題であるとは思われませんが、発生する可能性のあるディスクスワッピングに注意してください。

繰り返しますが、これはコメントです。 :)

2
Admiral Noisy Bottom
innodb_read_io_threads=8G
innodb_write_io_threads=8G

番号！！

各io_threadは、ある程度のRAM、CPU、システムなどを使用します。「8」は妥当です。 "8G"はvery無理です。システムがクラッシュしなかったのには驚きました。

他の設定を変更しましたか？

1
Rick James