JuiceFSはMySQLの物理バックアップに非常に適しています。詳細については、公式ドキュメントを参照してください。最近、ある顧客がテスト中にxtrabackup --prepare、バックアップ検証のデータ準備（）プロセスが非常に遅いと報告しました。JuiceFSが提供するパフォーマンス分析ツールを使用して、パフォーマンスのボトルネックをすばやく見つけました。XtraBackupのパラメーターとJuiceFSのマウントパラメーターを継続的に調整することで、1時間以内に元の時間の1/10に短縮されました。この記事では、パフォーマンス分析と最適化のプロセスレコードを共有して、IOパフォーマンスを分析および最適化するためのリファレンスを提供します。
データの準備
SysBenchツールを使用して、サイズが約11GiBの単一テーブルデータベースを生成し、データベーステーブルのパーティションを10に設定します。通常のデータベースの読み取りおよび書き込みシナリオをシミュレートするために、データベースはSysBenchを介して毎秒50リクエストのプレッシャーでアクセスされます。このプレッシャーの下で、データベースによってデータディスクに書き込まれるデータは8〜10MiB/の範囲です。 s。次のコマンドを使用して、データベースをJuiceFSにバックアップします。
# xtrabackup --backup --target-dir=/jfs/base/
各データ準備操作のデータが完全に同じであることを確認するために、JuiceFSのスナップショット機能を使用して、/jfs/baseディレクトリ/jfs/base_snapshot/ます。各操作の前に、前のデータ準備操作のデータが削除され、新しいスナップショットが生成されます。
デフォルトのパラメータを使用する
# ./juicefs mount volume-demoz /jfs
# time xtrabackup --prepare --apply-log-only --target-dir=/jfs/base_snapshot
合計実行時間は62秒です。
JuiceFSは、操作ログoplogのエクスポートをサポートし、oplogを視覚的に表示できます。xtrabackup --prepare操作を実行する前に、新しい端末を開いてサーバーに接続し、コマンドラインで入力します
# cat /jfs/.oplog > oplog.txt
oplogログの収集を開始し、xtrabackup --prepare操作。操作が完了したら、oplog.txtをローカルにダウンロードし、JuiceFSが提供するoplog分析ページ（ https://juicefs.com/oplog/）にアップロードします。
oplogを視覚化します。
これは、この図のさまざまな要素の意味の概要です。私たちのoplogの1つには、タイムスタンプ、スレッドID、ファイルシステム操作関数（読み取り、書き込み、fsync、フラッシュなど）、操作期間などが含まれています。左側の数字はスレッドIDを表し、横軸は時間を表し、さまざまな種類の操作がさまざまな色でマークされています。
部分的な画像を拡大表示します。色が異なると、操作の種類が異なり、一目でわかりやすくなります。
この操作に関係のないいくつかのスレッドを除外します。データ準備プロセスでは、4つのスレッドが読み取りを担当し、5つのスレッドがデータの書き込みを担当し、読み取りと書き込みが時間的にオーバーラップします。
XtraBackupのメモリバッファを増やす
XtraBackupの公式ドキュメントを参照すると、データの準備は、埋め込まれたInnoDBを使用してバックアップデータセットに対してクラッシュリカバリを実行するプロセスです。
この--use-memory オプション、組み込みInnoDBのメモリバッファーサイズを増やします。デフォルトは100MBですが、4GBに増やしました。
# time xtrabackup --prepare --use-memory=4G --apply-log-only --target-dir=/jfs/base_snapshot
実行時間は33秒に短縮されました。
読み取りと書き込みが重なっておらず、処理が完了した後、データがメモリに読み込まれ、ファイルシステムに書き込まれていることがわかります。
XtraBackup読み取りスレッドの数を増やします
バッファを増やすことにより、時間が半分に短縮され、読み取りプロセス全体に時間がかかります。各読み取りスレッドは基本的にいっぱいであることがわかり、さらに読み取りスレッドを追加しようとしています。
# time xtrabackup --prepare --use-memory=4G --innodb-file-io-threads=16 --innodb-read-io-threads=16 --apply-log-only --target-dir=/jfs/base_snapshot
実行時間は23秒に短縮されました。
読み取りスレッドの数が16（デフォルトでは4）に増え、読み取り操作が約7秒に短縮されました。
JuiceFSは非同期書き込みを可能にします
前のステップでは、読み取り操作時間を大幅に最適化しましたが、書き込みプロセスにかかる時間がより明確になりました。oplogを分析すると、書き込み操作でfsyncを並列化できないため、書き込みスレッド数を増やしても書き込み効率が向上しないことがわかります。実際の操作プロセスでは、書き込みスレッド数を増やして検証しました。したがって、ここでは詳しく説明しません。同じファイル（同じファイル記述子）へのoplog書き込み操作のパラメーター（オフセット、書き込みデータサイズ）を分析し、ランダムな書き込み操作が多数あることを確認すると、JuiceFSをマウントするときに--writebackオプションを有効にできます。データの書き込み最初にローカルディスクに書き込み、次にオブジェクトストレージに非同期で書き込みます。
# ./juicefs mount --writeback volume-demoz /jfs
# time xtrabackup --prepare --use-memory=4G --innodb-file-io-threads=16 --innodb-read-io-threads=16 --apply-log-only --target-dir=/jfs/base_snapshot
時間は11.8秒に下がりました。
書き込みプロセスは約1.5秒に短縮されました。
読み取りスレッドの読み取り操作はまだ比較的集中的であることがわかります。読み取りスレッドの数を継続的に増やしようとしています。InnoDB読み取りスレッドの最大数は64であり、直接64に調整します。
# time xtrabackup --prepare --use-memory=4G --innodb-file-io-threads=64 --innodb-read-io-threads=64 --apply-log-only --target-dir=/jfs/base_snapshot
実行時間は11.2秒で、基本的には以前と同じです。
読み取りスレッドの読み取り操作は比較的まばらであることがわかります。スレッドによって読み取られるデータ間に依存関係があるため、完全に並列化できず、読み取り時間を短縮できなくなります。スレッドの数を増やして処理します。
JuiceFSのディスクキャッシュを増やします
前のステップでは、読み取りスレッドの数を増やすことで読み取りプロセスの効率を改善しましたが、データの読み取りの待ち時間を短縮することによってのみ、読み取りプロセスの時間を短縮できます。
JuiceFSは、読み取り操作の処理で先読み機能とキャッシュアクセラレーション機能を提供します。次に、JuiceFSのローカルキャッシュを増やすことで、読み取り操作のレイテンシを短縮しようとします。
JuiceFSのローカルキャッシュを高効率クラウドディスクからSSDクラウドディスクに変更し、キャッシュサイズを1Gから10Gに変更します。
# ./juicefs mount --writeback volume-demoz --cache-size=10000 --cache-dir=/data/jfsCache /jfs
# time xtrabackup --prepare --use-memory=4G --innodb-file-io-threads=64 --innodb-read-io-threads=64 --apply-log-only --target-dir=/jfs/base_snapshot
実行時間は6.9秒に短縮されました。
キャッシュのパフォーマンスを向上させ、キャッシュスペースを増やすことで、読み取り操作時間の消費がさらに削減されます。
この時点で要約しましょう。oplogを分析することで、常に最適化できるポイントを探し、データ準備プロセス全体を62秒から6.9秒に段階的に短縮します。効果は次の図でより直感的に表示されます。
データベースデータの量を増やす
上記の操作は、良好な結果を得るためにパラメーターを継続的に調整することにより、11Gなどの比較的小さなデータセット用に最適化されています。比較として、同じ方法で約115Gの10のパーティションを持つ単一テーブルデータベースを生成します。バックアップ操作は、SysBenchを使用して1秒あたり50リクエストで実行されます。
# time xtrabackup --prepare --use-memory=4G --innodb-file-io-threads=64 --innodb-read-io-threads=64 --apply-log-only --target-dir=/jfs/base_snapshot
このプロセスには74秒かかりました。
読み取りと書き込みはまだ分離されていることがわかります。
データ量が約10倍になると、対応する準備時間も10倍になります。これは、バックアップ（xtrabackup --backup）プロセスに必要な時間が10倍に拡大され、SysBenchによるデータベースへのプレッシャーが変わらない状態で、バックアッププロセス中に生成される時間xtrabackup_logfileも元の10倍になるためです。データの準備は、データファイル内のすべてのデータ更新をデータファイルxtrabackup_logfileにマージすることです。データサイズが10倍になっても、1つのログを更新する時間は基本的に同じであることがわかります。これは上の図からも確認できます。データサイズが大きくなった後も、準備プロセスはデータの読み取りと書き込みの2つの明らかなプロセスに分割され、設定された4GBのバッファサイズで十分であることを示します。それでもメモリ内で実行され、ファイルシステムに更新されます。
要約する
比較的単純なツールであるSysBenchを使用して初期データを構築し、データベースを特定の圧力まで継続的に更新して、データバックアップ中のデータベース操作シナリオをシミュレートします。JuiceFSのoplogを使用して、データ準備プロセス中にバックアップデータにアクセスするXtraBackupの読み取りおよび書き込み特性を観察し、XtraBackupおよびJuiceFSのパラメーターを調整して、データ準備プロセスの効率を継続的に最適化します。
実際の本番シナリオでは、状況はSysBenchシミュレーションよりもはるかに複雑です。上記の線形関係は必ずしも厳密には当てはまりませんが、oplogを分析することで最適化できるポイントをすばやく見つけ、キャッシングを継続的に調整し、 XtraBackupとJuiceFSの同時実行のアイデアは一般的です。
パラメータ調整プロセス全体には約1時間かかります。このプロセスでは、oplog分析ツールが大きな役割を果たし、システムパフォーマンスのボトルネックをすばやく特定して、最適化のためのパラメータをターゲットに合わせて調整できるようになりました。このoplog分析機能も役立ちます。発生したパフォーマンスの問題をすばやく見つけて分析できます。
それが役に立ったら、私たちのプロジェクトJuicedata / JuiceFSに従ってください！（0ᴗ0✿）