web-dev-qa-db-ja.com

MySQLがCPUを使いすぎている

私が管理している非常に機密性の高い大規模なライブデータベースがあるので、現在DBAになることを勉強しています。これが私の専用データベースサーバーの現在のシステム統計です。

  • CentOS 5.9
  • 24GB RAM
  • 8コアCPU
  • / var/lib/mysql用の50GBのFusionIOディスク

  • MySQL 5.5.23

    top-18:40:27 up up 14日、4：43、1ユーザー、平均負荷：19.72、22.62、24.04

    タスク：合計183、ランニング3、スリープ180、停止0、ゾンビ0

    CPU：69.9％us、0.4％sy、0.0％ni、29.2％id、0.0％wa、0.1％hi、0.4％si、0.0％st

    メモリ：合計24685224k、20172096k使用、4513128k空き、343420kバッファ

    スワップ：2007284k合計、0k使用、2007284k空き、729004kキャッシュ

    PIDユーザーPR NI VIRT RES SHR S％CPU％MEM TIME +コマンド

    5446 mysql 15 0 18.4g 17g 6176 R 765.8 76.2 114437：38 mysqld

現在、50 GBのFusionIOスライスのうち43 GBを使用しています。 MySQLの平均は約700 QPSで、CPU使用率は75〜90％です。これが私のmy.cnfファイルです。

[mysqld]
user=mysql
datadir=/var/lib/mysql
socket=/var/lib/mysql/mysql.sock

#innodb
#innodb_log_file_size = 256M
#innodb_log_buffer_size = 8M
innodb_flush_log_at_trx_commit = 2
innodb_lock_wait_timeout=50
innodb_file_per_table
innodb_buffer_pool_size=16G
innodb_buffer_pool_instances=4
#eliminating double buffering
innodb_flush_method = O_DIRECT
flush_time=86400

skip-name-resolve
query_cache_limit=4M
query_cache_size=256M
sort_buffer_size=8M
read_rnd_buffer_size=1M
max_connections=5000
interactive_timeout=60
wait_timeout=300
connect_timeout=30
thread_cache_size=32
key_buffer=124M
tmp_table_size=4096M
max_heap_table_size=256M
join_buffer=16M
max_connect_errors=2000
table_cache=2048
thread_concurrency=12
long_query_time=5
log-slow-queries=/var/log/mysql-slow.log
#table_definition_cache=384
max_allowed_packet=1024M
#server-id=20
#log-bin=mysql-bin
#expire_logs_days=10

event_scheduler=ON


[mysqld_safe]
log-error=/var/log/mysqld.log
pid-file=/var/run/mysqld/mysqld.pid

私のMySQLやCentOSにCPUの使用量を大幅に減らすことができる構成の変更を推奨できますか？それとも、他のリソースの改善ですか？

mysqlperformanceinnodbmysql-5.5fusion-io
6
Logan Best

あなたは二つのものを解き放つ必要があります

私はこれを長年にわたって議論してきました。 InnoDBがより多くのCPU /コアアクティビティに従事するようにするための私の以前の投稿のいくつかをご覧ください。

試してみる ！！！

更新2013-06-20 02:39 EDT

あなたの最後のコメント

こんにちは、Rolando、read_ioとwrite_ioを8に追加し、他の投稿を読みましたが、CPU使用率が低下しているようには見えません。パフォーマンスが向上することを期待して、4つのバッファプールインスタンスを1つに下げましたが、それでもうまくいきません。 CPU使用率を下げるのに役立つ、実装できる他の提案はありますか？

innodb_buffer_pool_instances をコアの数に合わせて8に上げることをお勧めします。 MySQLドキュメントでは、バッファープールインスタンスごとに1Gを推奨しています。次に、16にレイズします（16Gのinnodb_buffer_pool_sizeがあるため）。最初に8、次に16を試してください。

これでも、かなり悲惨なニュースがあります。これが 2年前のFusionIOからのプレスリリース です。パラグラフ2は言う：

StatSoftホワイトペーパーは、Fusion ioDrivesが分析ソフトウェア製品およびソリューションのSTATISTICAスイートのI/Oパフォーマンスを大幅に向上させ、CPUの使用率と効率を大幅に向上させたと結論付けました。 StatMemoryは、ioMemoryにより、従来のディスクベースのストレージと比較して、300パーセントと500パーセントのデータパフォーマンスとレイテンシ削減の改善を達成しました。 Fusion ioDriveによってI/Oパフォーマンスが向上したため、大規模なデータセットのテストではCPU使用率が90％に増加しましたが、ディスクベースのテクノロジーでは32％のCPU使用率が観察されました。

RAID 10を使用している場合SASまたは/var/lib/mysql、InnoDBはCPUで一日を過ごすでしょう。 ただし、このプレスリリースの外観から、InnoDBはCPU使用率に関してFusionIOと競合しています。

提案

FusionIOディスクのIOPを確認し、 innodb_io_capacity をその数に設定します。 innodb_io_capacity のデフォルト値は200です。IOPが200より大きい場合は、設定してください。 IOPが1000年代にある場合、InnoDBはFusionIOと平等な競争の場にいるチャンスがあります。

試してみる ！！！

10
RolandoMySQLDBA

最初に確認するのは、忙しいときに実行されているクエリです。ハードウェアやデータベースの構成ではなく、クエリの設計の問題である可能性があります。たとえば、適切なインデックスがない場合や、クエリプランナーがインデックスを使用できないようにクエリを記述した場合、メモリ内のテーブルまたはインデックス構造のスキャンに多くの時間が費やされ、CPUリソースが消費される可能性があります。

3
David Spillett

テーブルが大きくなりすぎるの場合、サーバーの負荷が劇的に上昇し、CPU使用率が急上昇することがわかりました。

0
Roy Hinkley