web-dev-qa-db-ja.com

Ubuntu 16.04 MySQL5.7.12にアップグレードした後のMySQLパフォーマンスの恐ろしい低下

最近14.04から16.04にアップグレードした開発サーバーがあります。

私のウェブサイトalgebra.comのデータをホストするデータベース「algebra」があります。質問と回答があり、1対Nの関係にあるQ＆AWebサイトです。

アップグレード後、まったく同じデータベースクエリのパフォーマンスが大幅に低下しました。

たとえば、質問IDで質問と回答を結合するクエリは、以前は0.5秒未満でした。アップグレード後、1分かかります。

これは開発サーバーなので、ubuntu 14.04を実行し、同じクエリに0.38秒しかかからない本番サーバーと比較できます。

これがクエリプランです

mysql> explain SELECT 
    ->     questions.id, questions.email, questions.topic, questions.question,  
    ->     questions.date, 
    ->     questions.deleted, 
    ->     questions.is_spam, 
    ->     questions.solved, 
    ->  
    ->     questions.tb_id, 
    ->     questions.tb_isbn, 
    ->     questions.tb_title, 
    ->     questions.tb_edition, 
    ->     questions.tb_chapter, 
    ->     questions.tb_problem, 
    ->  
    ->     solutions.id, solutions.author author, solutions.date, solutions.answer 
    -> FROM questions, solutions 
    -> WHERE 
    ->      questions.solved = 1 
    ->      AND questions.id = solutions.question 
    ->      AND questions.deleted != 1 
    ->      AND questions.is_spam != 1 
    -> ORDER BY solutions.date DESC 
    -> LIMIT 50;

「GoodServer」の場合：

+----+-------------+-----------+--------+-----------------------+---------+---------+----------------------------+--------+----------------+
| id | select_type | table     | type   | possible_keys         | key     | key_len | ref                        | rows   | Extra          |
+----+-------------+-----------+--------+-----------------------+---------+---------+----------------------------+--------+----------------+
|  1 | SIMPLE      | solutions | ALL    | solutions_by_question | NULL    | NULL    | NULL                       | 650770 | Using filesort |
|  1 | SIMPLE      | questions | eq_ref | PRIMARY               | PRIMARY | 4       | algebra.solutions.question |      1 | Using where    |
+----+-------------+-----------+--------+-----------------------+---------+---------+----------------------------+--------+----------------+
2 rows in set (0.00 sec)

「悪いサーバー：

+----+-------------+-----------+------------+------+-----------------------+-----------------------+---------+----------------------+--------+----------+----------------------------------------------+
| id | select_type | table     | partitions | type | possible_keys         | key                   | key_len | ref                  | rows   | filtered | Extra                                        |
+----+-------------+-----------+------------+------+-----------------------+-----------------------+---------+----------------------+--------+----------+----------------------------------------------+
|  1 | SIMPLE      | questions | NULL       | ALL  | PRIMARY               | NULL                  | NULL    | NULL                 | 482186 |     8.10 | Using where; Using temporary; Using filesort |
|  1 | SIMPLE      | solutions | NULL       | ref  | solutions_by_question | solutions_by_question | 4       | algebra.questions.id |      1 |   100.00 | Using index condition                        |
+----+-------------+-----------+------------+------+-----------------------+-----------------------+---------+----------------------+--------+----------+----------------------------------------------+

データベースの内容はほぼ同じで、開発データベースは昨夜のサーバーのバックアップです。

パフォーマンスの低下を理解するこの野生のガチョウの追跡を開始できるアイデアはありますか？

ありがとう！

ubuntumysqldatabasedatabase-administration
2
Igor Chudov

16.04 Ubuntuサーバーに更新し、5.7.12を使用している場合、RAMを使い果たすバグと、サーバーの使用可能なRAMそして理想的とは言えない設定です。これは多くの人にとって問題でしたが、特にRAMの少ない小さなサーバー/ vpsでは問題がありました。

Laracasts.comでMySQL5.7のメモリリークを検索します

https://www.reddit.com/r/mysql/comments/4gnj93/mysql_5712_ubuntu_1604_ridiculous_memory/

他にも問題があり、そのうちのいくつかはもちろん5.7.13で修正されています...

http://mysqlentomologist.blogspot.com/2016/06/fun-with-bugs-43-bugs-fixed-in-mysql.html

また、InnoDBまたはMyISAMのどちらを使用するかによって、影響を与えるいくつかの異なる最適化/変更が行われました。例を挙げると、MySQLを再起動すると約320MBのRAMを消費する2GB RAMの最近インストールされたVPSは、メンテナンス中にアイドリングアプリで1GBを消費するまでゆっくりと上昇しますモード...トラフィックまたはdbクエリがゼロの場合（これはMyISAMを使用するOpenCartインストールでした...これは、前進しようとする人には望まないでしょう...しかし、それは「急いで、これを実行し、これを使用して.... "）。そのため、アプリ内のMyISAMへの依存、メモリリーク、およびOracleチームが世に送り出したいくつかの貧弱なデフォルトのために、特定のインスタンスに戻ってMySQLからの同じパフォーマンスの低下の問題に対処するにはより多くの$と時間が必要です。

確かに、新しい更新のためにクエリと結合を最適化する必要があります。しかし、同時に、ふるいの問題のように根本的なメモリリークが発生するため、多くの労力を浪費し、何も達成できなくなる可能性があります。最適化を行う場合は、問題を引き起こしているサーバーとは別のMySQLサーバーを使用することをお勧めします。

MySQLのバグ修正がいかに遅いかを考えると、選択肢は次のとおりです。

1）乗り越えて、それを修正するリポジトリの更新を待つ

2）現在のバージョンをアンインストールして、以前のバージョンに戻ります（ただし、なぜですか？）

3）MariaDBまたはPerconaに置き換えます

新しいUbuntu16.04サーバーを起動する場合は、リモート管理ユーザーエージェントに接続する前、またはサーバー管理パネルをインストールする前にリポジトリを変更して、MariaDB/Perconaトラックを使用するようにします。または、Ubuntuリポジトリではなく公式のMySQLリポジトリを追跡して、修正をすばやく取得します。

安全で即時の解決策（バグがあり、リリースストリームに主要な互換性ブレークポイントがある以前のバージョンの使用を延長するよりも確かに賢い）は、MariaDBまたはPerconaに切り替えることです。または、MySQLだけでなくPostgreSQLも使用できるアプリを使用している場合は、Postgreに切り替えてください。実用的でない場合は。

5.7.13に更新して結果を監視するか、MariaDBまたはPerconaに切り替えるまで、データベースの最適化に時間を費やすことはありませんでした。 5.7.12の最適化/トラブルシューティングは、時間とリソースを無駄にするだけのブラックホールです。

1
Sean Wilson

具体的には、バグです 5.7.8以降のmemory/innodb/os0fileで過剰なメモリが使用されています 。

Ubuntuでは buntu16.04のmysqldデーモンの過剰消費RAM ）として追跡され、 Redditに関する議論 もあります。

0
colan