web-dev-qa-db-ja.com

Mysql：cpuが低いときに1000を同時に処理することは可能ですか？

Centos 7を実行しており、Mariadb 5.5を実行中で、本日10.3にアップグレードしています。 PHP 5。

クエリは不良であり、最適化するにはそれらの数が多すぎますが、できる限りのことを試みていますが、データベース構造が不良です。

クライアントはクエリの最適化を気にせず、CPU使用率を下げたいだけです-負荷テストツールである locust を実行し、1500人のユーザーと1000人の同時ユーザーに与えます。これは悪いと言います検索機能は彼が言った問題です。

繰り返しになりますが、クエリは悪いです。私はちょうど雇われて、私ができることをしましたが、彼は正しいメトリックスを見ていますか？

クエリを修正する以外に何をしようとしましたか：

インデックスを追加すると、インデックスはありませんでしたが、my.cnf

innodb_stats_on_metadata = 0
innodb_buffer_pool_dump_at_shutdown =1
innodb_buffer_pool_load_at_startup =1
## innodb_buffer_pool_instances should match the number of cores on the server

innodb_log_file_size = 2047M
innodb_flush_method=O_DIRECT
sync_binlog=0
innodb_thread_concurrency = 48
innodb_read_io_threads = 24
innodb_write_io_threads = 24

## set innodb_buffer_pool to 50% to 70% of the ram on the server so if the server have 32G, then set it to 16G. 50% is a good start
## turn off slow query log, if you're not logging, and only log for small durations when you want to monitor things
slow_query_log =0

スロークエリログからもできることを最適化しようとしました。また、キャッシュのため、クエリを傍受し、クエリの1/10をサーバーに送信すると聞いたproxySQLを使用しようとしています。

クライアントにはストリーミングアプリがあり、ピークイベント中に7k人のユーザーにヒットします。これが同時ユーザーとしてカウントされるかどうかは不明で、すべてのユーザーが検索するかどうかは非常に疑わしいものです。彼らはオンプレミスサーバーを持っています

DL380 Gen10 2x Intel Xeon Silver 4110/2.1 GHz 64 GB RAM 300 GB HDD

私の質問：

  1. 検索クエリのCPU使用率を削減するために知らなかった対策はありますか？
  2. すべてのクエリを最適化した場合、そのような負荷テストではCPUの低下が予想されますか？彼らはCPU使用率を50％程度まで下げたいと思っています。私は彼らが間違ったメトリックスを見ていると感じています。以前は、CPUが100％になるとサーバーがダウンすることが原因でした。
mysqloptimizationmariadbmysql-5.5proxysql
1
Lynob

費用対効果が最も高い、修正すべき「悪い」クエリを特定する方法は次のとおりです。スローログと_pt-query-digest_。詳細はこちら： http://mysql.rjweb.org/doc.php/mysql_analysis#slow_queries_and_slowlog

劇的な改善をするために、リストを3つ以上下に移動する必要はめったにありません。

追加するインデックスを理解するのが苦手な場合は、単に「これまでに列にインデックスを付ける」のではなく、 http://mysql.rjweb.org/doc.php/index_cookbook_mysql を参照してください

検索クエリのCPU使用率を削減するために知らなかった対策はありますか？

いいえ。高いCPUは、選択した複合インデックスを使用するか、クエリを再編成することで修正されます。クエリを見せてください。 「検索」という言葉は曖昧すぎます。

これが極端な逸話です。CPUが100％で固定されていました。スローログは1つのクエリを指しています。 WHERE DATE(foo) = '...'がありました。 「sargable」にすることで、CPUは2％に低下しました。

ベンチマークについては...注意してください。彼らは、馬力がなくなる前に実行できる接続の数を確認する傾向があります。つまり、結果は100％CPUであることが保証されます！実際に得られるメトリックは、「クエリ/秒」または「最大接続数」です。

さらに、mysqlをいくつかの同時ユーザー数を超えてプッシュすると、スループットが低下することが繰り返し文書化されています。 10年前、その数は約6でした。現在は64に近いですが、1000ですか？ありえない。 1000がすべてつまずき合っているため、車輪が回転しています。

1000人のユーザーを処理する方法複数のスレーブに給電するレプリケーション。そのような場合、1000のスレーブがあり、それぞれがわずか10の接続を実行しています。 CPUが非常に低くなります。等。

2
Rick James

クエリが悪い

その後、修正が必要です。あなたはcould追加のハードウェアを追加しますが、せいぜい線形の改善が得られます。クエリを修正すると、巨大なスキャンなどを削除することにより、数桁の改善が見込まれる可能性があります。実際のクエリに関する情報がないので、ここでは推測しているだけです。

最適化するにはそれらが多すぎます

多くの場合、すぐに最適化するのは遠いかもしれませんが、メトリックを取得して、最悪の犯罪者を最初に攻撃できます。これは常に複雑なものでもありません。特定の期間に何度も実行される単純な次善のクエリは、月に1回実行される大規模で複雑なレポートよりも最初に攻撃する方が適切です。

データベース構造が不良です。

これはクエリの改善を妨げる可能性があります。特に、悪い設計が適切なインデックスの選択の欠如だけではない場合はなおさらです。両方を一緒に作業することは、長期的には最良の計画かもしれませんが、最初の有益な結果を確認するにはさらに多くの作業が必要になります。繰り返しになりますが、具体的な情報は提供していませんので、あいまいな答え/推測しか提供できません。

1
David Spillett