web-dev-qa-db-ja.com

mysqldumpが進行中の場合、ユーザーはシステムの実行速度が遅いと不平を言う

MYSQLデータベース（ibdata1）のサイズは73 GBで、Windows 2008 O/SでINNODBテーブルの専用データベースサーバーとして実行するように構成されています。 mysqldumpを使用してバックアップを実行していますmysqldump --skip-opt --quick --single-transaction --create-options --extended-insert --disable-keys --add-drop-table --complete-insert- set-charset-圧縮--log-error = Proddb0635.err -u root -pjohndoe Proddb>\devNas\devNas\sqlbackup\LIVE\db\Proddb0635.sql

バックアップファイルProddb0635.sqlは、データベースサーバーとは別のサーバーに保存されます。 RAMは12 GBです。INNODBバッファープールのサイズは6 GBです。追加のmem.poolは32 MBです。クエリキャッシュサイズは2 GBです。ネットバッファー長は16 M最大パケットサイズは1 GBです。

mysqlのバージョンは5.0.67です。

バックアップが実行されていない場合、ユーザーはパフォーマンスに満足しています。

バックアップの実行中にINNODBバッファープールのヒット率が100％に近い高い値になっています。保留中の読み取りまたは保留中の書き込みはありません。 innodb wait freeは0です。CPU使用率は高くありませんmin 9％からmax 15％クエリキャッシュヒット率は、mysqlbackupの実行の有無にかかわらず、約40％と低くなっています。現在、Windowsタスクマネージャーは、10 GBのRAMが使用されていることを表示しています。2GBのRAMを使用してクエリキャッシュを増やす必要がありますか？mysqlld-ntは9.2を使用していますRAMのGB、およびmysqldumpは5 MBのRAMを使用しています。また、-compressオプションの有無にかかわらず、ダンプファイルのサイズは同じであることに注意してください。

INNODBバッファープールのサイズを減らす必要がありますか？

ありがとう

mysqlbackupmysqldumpmysql-5
9
dbachacha

Windowsには既知の問題があり、大きなファイルを別のサーバーにプッシュすると、すべてのメモリがユーザープロセスではなくシステムキャッシュに割り当てられることになります。タスクマネージャーの[物理メモリ（MB）]セクションで、システムキャッシュに割り当てられているメモリの量を確認できます。

これは、ローカルディスクにバックアップし、リモートマシンにそのファイルをプルさせることで解決できます。

8
mrdenny

ここでは、状況に応じて、mysqldumpのパフォーマンスの向上について私が考えていることをいくつか示します。コマンドは次のとおりです。

mysqldump --skip-opt --quick --single-transaction --create-options --extended-insert --disable-keys --add-drop-table --complete-insert --set-charset --compress- -log-error = Proddb0635.err -u root -pjohndoe Proddb>\devNas\devNas\sqlbackup\LIVE\db\Proddb0635.sql

最初に気づくのは、出力をファイルシステムにリダイレクトしていることです。 「devNas」と表示されているので、これはNetwork Attached Storageであると想定します。私はNASのファンですが、個別の物理的に接続する必要がありますNIC本番環境からtraffic。帯域幅を飽和させていない可能性がありますが、それでも競合します。--quickフラグは、保持する代わりにすべての行をフラッシュするため、これはさらに問題になりますメモリ内。

次に目にするのは、-compressを起動したことです。 -hスイッチを使用していないため、mysqlをローカルで実行しているようです。これは、このコンテキストでは不要なローカルCPUを使用する場合があります。 --compressは必要ですか？mysqldumpクライアントとmysqlサーバー間のデータのみを圧縮し、ファイルの内容は圧縮しません。

次に、-single-transactionフラグを使用していることを確認します。これは、mysqldumpの一部としてすべての選択をテストするため、余分なCPUが発生します。

これはパフォーマンスとは関係ありませんが、MyISAM（ manual ）でのみ機能する--disable-keysを使用しています。

Mysqldumpをオフラインのホストからリモートで実行し、ダンプファイルをNAS完了後にに移動して、この操作をできるだけ多く実行する）を試すことができます。可能な限りバンド

7
randomx

観測＃1

ここでは、InnoDBに対してmysqldumpを実行するときに注意する点があります。

InnoDBバッファープールに存在するダーティページは、最初にディスクにフラッシュする必要があります。 mysqldumpは、ダーティページがまだあるInnoDBテーブルのフラッシュをトリガーします。

innodb_max_dirty_pages_pct というサーバーオプションがあります。デフォルト値は75がMySQL 5.5であり、バージョン5.5より前のMySQLでは90です。実稼働環境では、この数をデフォルト値のままにしても問題ありません。

InnoDBバッファープールに多数のダーティページがあるかどうかを確認するには、次のコマンドを実行します。

SHOW GLOBAL STATUS LIKE 'Innodb_buffer_pool_pages_dirty';

ところでこれから示すようにページは16Kです：

SHOW GLOBAL STATUS LIKE 'Innodb_page_size';

InnoDBとmysqldumpの場合、2つの状況でこの数を減らすことができます。

CIRCUMSTANCE 1：永久に0に設定します

これをmy.iniに追加するだけです。

[mysqld]
innodb_max_dirty_pages_pct=0

これにより、InnoDBバッファープールは無駄のない、平均的なものになります。ダンプされているInnoDBテーブルをフラッシュするステップは、mysqldumpが操作する前に、可能な限り少数のダーティページ（おそらく0）をフラッシュする必要があるため、迅速です。

唯一の欠点は、トラフィック量の多いDBからmysqldumpを実行する場合、ダーティページをより頻繁にフラッシュするため、書き込みI/Oがわずかに増加する可能性があります。これを実行することにより、mysqlをrestartnigせずにそうであるかどうかを判断できます。

SET GLOBAL innodb_max_dirty_pages_pct = 0;

設定を12〜24時間のままにします。書き込みパフォーマンスが許容できる場合は、問題ありません。そうでない場合は、次のように設定してください：

SET GLOBAL innodb_max_dirty_pages_pct = 90;

CIRCUMSTANCE 2：mysqldumpの約1時間前に0に設定します

SET GLOBAL innodb_max_dirty_pages_pct = 0;

Mysqldumpを実行する

SET GLOBAL innodb_max_dirty_pages_pct = 90;

観測＃2

Mysqldumpオプションとして -complete-insert があります。これにより、VALUES句の前のすべてのINSERTステートメントに列名が埋め込まれます。 --extended-insertを使用しても、挿入される行のバッチごとにmysqldumpに送信される列名があります。 --complete-insertを削除することで、mysqldumpに送信されるバイト数を減らすことができます。

[〜＃〜]推奨[〜＃〜]

スレーブとしてセットアップできる別のWindowsサーバーがある場合は、本番マシンからではなく、そのスレーブからmysqldumpを実行します。

2
RolandoMySQLDBA