Percona pt-online-schema-changeのパフォーマンスが悪いのはなぜですか？

Question

テーブルをロックせずにmysqlスキーマに変更を加えるためにしばらくの間Percona OSCを使用していましたが、通常は大きなテーブル（〜380万行）に新しいカラムやインデックスを追加しました。数時間

しかし私が試した最後の更新は、完了するまでにさらに11時間の見積もりで、7時間（一晩、私たちの最も静かな時間に）実行した後にわずか40％しか完了しませんでした。 RedHatサーバー上で使用可能なメモリの4GBのすべてが使用されていました - 最近32GBから16GBにアップグレードしました。

ここで何が起こっているのですか？なぜ突然時間がかかったのですか？ percona/mysql /サーバが対応できないようなしきい値に達しましたか？パフォーマンスを改善するために調整できる設定はありますか？

テーブルには、32の列と12のインデックス（プライマリキーと2つのユニークインデックスを含む）があります。私はそれがたくさんあることを知っていますが、私が最近言っているように、それはうまくいったのです。

また、このテーブルには、drop_swapメソッドを使用して更新を設定するいくつかの外部キーがあります。

私が使用した完全なコマンドは以下のとおりであった：

pt-online-schema-change --execute --ask-pass --set-vars innodb_lock_wait_timeout=50 --alter-foreign-keys-method=drop_swap 
--alter "ADD is_current TINYINT(1) DEFAULT '1' NOT NULL" u=admin,p=XXXXXXX,D=xxxxx_live,t=applicant 

innodb_buffer_pool_sizeは現在、2147483648に設定されている - これは、増加すべきか？もしそうなら、どれくらい？ Webサーバー（apache/php/symfony）もこのボックスで実行されています。

この特定のテーブルで最後に行った変更は、1つのフィールドの照合順序をutf8_bin（他のフィールドはutf8_unicode_ci）に変更することでした。違いがありますか？

Answer 1

すべてのものが等しいとすると、何らかの種類のしきい値が超過した、または他のプロセスがデータベースをロードしているとします。 使用しているインデックスの数が多いです。 pt-oscは新しい空の変更されたテーブルを作成し、 "チャンク"でコピーを開始します。各チャンクにかかる時間は、（デフォルトで）0.5秒間持続するように動的に調整されます。 「プロセスリストを表示する」をチェックすると、誰がデータベースを圧迫しているのか、そしてより多くの洞察を得るためにpt-oscのチャンクサイズを確認できます。

Answer 2

このテーブルは、MB/GBでどれくらいの大きさですか？

InnoDBは、そのページをinnodbバッファプール（innodb_buffer_pool_size）にキャッシュします。これは、パフォーマンスにとって重要です。 4GB以上のRAMを持つ専用ホストでは、メモリの約70〜80％のガイドラインをInnoDBバッファプールに使用することを推奨します。その情報で

あなたのテーブルの論理的なサイズを収集するために、この記事にSQLを使用してインデックス

https://www.percona.com/blog/2008/03/17/researching-your-mysql-table-sizes/

MySQLインスタンス（InnoDBエンジンが）されている場合、あなたはすぐに伝えることができるでしょう飢えた記憶。

作業中のデータセットがメモリ内に収まっていても、キャッシュミスが発生する可能性が高い場合は、MySQLはディスクリソースにアクセスしてバッファプールにスワップするためにIOを実行する必要があります。 （IOは常にDB土地のPITAです）

pt-oscの仕事の性質は、テーブルの新しい修正コピーを作成し、元の行で新しいバージョンをバックフィルすることです。新しい行は、ツールが設定するトリガーを使用して挿入/更新または削除されます。この埋め戻しを実行するためには、（RAMでバッファプール内に存在しない）いくつかの点で、そのテーブル内のすべての行をタッチすると、テーブルの多くは寒いかもしれない持っているだろう。だから、基本的にマシン上には適度な量のRAMがありますが、実際にはInnoDBはその2GBしか見ていません。

あなたはそれをチューニングするためにあなたの側にいくつかの観察を取るために起こっているが、私はあなたがかなりバッファプールに割り当てられたメモリのレベルを上げることができることを期待するように、あまりにも、サーバー上で実行中のアプリケーションを持っています。また、あなたのRAMの多くは使用されていないが、ファイルシステムのキャッシュに割り当てられていると思います。

テーブルが数百mb（これは4mレコードと幅広いスキーマで疑わしい）の場合は、おそらくさらに深刻な問題がありますが、バッファプールのサイズが変更されるといくつかのより良いパフォーマンス。

また、それはあなたのinnodb_log_file_sizeがワークロードに合わせて調整されていることを確認する作業です。これは、MySQLがIOを延期できるように重要です。現在のサイズは何ですか？