犬でも分かるrsync(2): バックアップの性能

前回の記事で、rsyncによるバックアップがとても便利であることは理解できましたと思いますが、バックアップに要する時間はとても気になるところです。今回は、いろいろオプションを変えながら、バックアップの性能を評価してみたいと思います。

測定環境

rsyncのバックアップの性能を測定するのは、ウチにある2台のミニPCです。この2台を1GのEth SWで接続してリモートバックアップをします。

ミニPCの仕様は以下の通り。

ホスト名	base0	base1
機種	NINISFORUM GK41	GMKtec Nucbox G3
CPU	Celeron J4125(2.0GHz, 4cores)	Celeron J4125(2.0GHz, 4cores)
Mem	8GB DDR4	8GB DDR4
SSD	M.2 2280 256GB SATA SSD	M.2 2280 256GB SATA SSD
LAN	1000Mbps LAN	1000Mbps LAN

Eth SWの仕様ですが、tp-linkのTL-SG108Eという 10/100/1000Mbps x 8portのスイッチです。

基礎性能は以下の通りです。ネットワーク性能、ほぼ理論性能(1000Mb/s)近く出ちゃっていますね。IO性能は、SATA3.0の理論性能は6.0Gb/sですが実効性能は約600MB/sと言われています。この環境では約400MB/sということで、こんなものなのでしょうね。

ネットワーク性能(base0-base1間, iperf3)	938Mb/s (117MB/s)
IO性能(ddコマンド, 1Mx1024回の書き込み)	約 400 MB/s

フルバックアップの性能を測定する

アーカイブモードでフルバックアップ(これが基本)

base0の/usr と /var を、base1の/backup 配下にバックアップしてみました。/usrをバックアップする場合は、以下のように実行しています。処理時間はtimeコマンドで計測し、転送量は send の値を使うことにしました。

	/usr	/var
転送量(send)	4,640,728,735 bytes	104,618,292,573 bytes
処理時間	45.9 sec	892.4 sec
性能	96.3 MB/s	111.8 MB/s

ネットワーク性能が117MB/sなので、今回の環境におけるrsyncによるリモートバックアップの性能は、ネットワーク性能がボトルネックなのでしょうね

「-z または –compress」による圧縮転送を試す

「-z または –compress」を指定すると、バックアップ対象のデータを圧縮してから転送することができます。しかし、データ圧縮はCPUで処理するのでCPU性能も要求されます。

以下は、/usr を圧縮なしとありで、リモートバックアップした場合の性能比較です。

	圧縮なし	圧縮あり( -z オプション)
転送量(send)	4,640,728,735 bytes	1,903,011,804 bytes
処理時間	45.9 sec	67.7 sec
性能	96.3 MB/s	26.8 MB/s

転送量は 1/2.43に圧縮していますが、圧縮のCPU処理が足を引っ張って、圧縮なしの場合よりも性能が劣化するという結果になっています。ネットワーク帯域がもっと小さかったり、圧縮率がもっと大きい場合なら、効果があるかもしれません。

ローカルバックの性能

ところでローカルバックアップの場合はどのくらいになるのでしょうか? base0上で、/usrを/backup/usr1にフルバックアップをとってみたら、処理時間は 37.9sec でした。性能としては 116.8 MB/s です。思ったより、リモートバックアップとの差がありませんでした。今回の環境ではSSDが1枚なので、バックアップ時のReadとWriteのI/Oが競合するからなのではないかと思います。

差分バックアップの性能を測定する

差分バックアップの性能測定は2つの方法を試しました。
ひとつ目はチェックサムなし。通常のアーカイブモードでのバックアップ方法です(オプションはフルバックアップのときと同じ)。更新の有無は最終更新時刻(mtime)で判定します。

2つ目はチェックサムあり。「-c または –checksum」オプションを追加します。

以下は、 /usr をフルバックアップを取得した直後で、差分バックアップを実行したときの処理時間です。更新したファイルはないので、正確には差分(更新の有無)チェックするのにかかった時間となります。

	チェックサムなし	チェックサムあり
転送量(send)	2,780,862 bytes	4,144,274 bytes
処理時間	1.8 sec	21.8 sec
フルバックアップの処理時間との比較	3.9%	47.5%

チェックサムありで差分バックアップを取得する場合は、ファイルの更新がない場合でも、フルバックアップの約半分の処理時間がかかるということですね。ファイルの更新があれば、更新されたファイルの差分データを転送する時間も加わります。いやあ～、重い、重いなー。

リモートバックアップの高速化

リモートバックアップを高速化できるかどうかは、どこがボトルネックかに依存するので、システム構成によってケースバイケースだと思っています。従って、基礎性能を測定した上で、いろいろとリモートバックアップの方法を試してみるのが良いと思います。

リモートバックアップを並列処理する

並列処理すると言っても、rsyncのプロセスは、マルチスレッドでもマルチプロセスでもないので、複数のrsyncコマンドを同時に実行して、並列処理することになります。

2並列

base0上で、/usr と同じ構成の /usr1を作成し、2並列で /usr と /usr1をbase1の/backupにリモートバックアップしたときの性能は以下の通りでした。今回のバックアップ対象の容量は/usrだけの場合の2倍です。差分チェックは、フルバックアップの直後に実行しているので、更新されたファイルのデータ転送はありません。

	フルバックアップ	差分チェック (チェックサムなし)	差分チェック (チェックサムあり)
転送量	9,281,606,292 bytes	5,711,183 bytes	8,437,995 bytes
処理時間	86.0 sec	2.3 sec	53.4 sec
性能	102.9 MB/s

3並列

以下は、同様にbase0で/usr, /usr1, /usr2 を作成し、3並列でbase1の/backupにリモートバックアップしたときの性能です。

	フルバックアップ	差分チェック (チェックサムなし)	差分チェック (チェックサムあり)
転送量	13,922,484,093 bytes	8,641,564 bytes	12,731,752 bytes
処理時間	123.8 sec	2.7 sec	68.2 sec
性能	107.3 MB/s

フルバックアップは2並列、3並列にしたことで少し性能が向上しています。やはりネットワーク性能がボトルネックになっているようです。チェックサムなしの差分チェックは、更新判定はmtimeで行うので負荷は軽く、並列化の効果はありそうです。但し、更新されたファイルがあれば、差分データの転送が発生するので、ネットワーク性能がボトルネックになるのではないかと思います。

チェックサムありの差分チェックは、チェックサムの作成処理がボトルネックになっているようですね。

sshの代わりにrsyncプロトコルを使ってデータ転送する

rsyncでリモートバックアップする際の通信はsshがデフォルトです。sshってデータを暗号化するからCPU負荷がかかると思い、rsyncプロトコルでリモートバックアップする方法を試してみます。

rsyncプロトコルのport番号はTCP 873番です。firewalldを運用している場合は、このportは遮断されている可能性がありますので、firewall設定で873番のportを許可するか、firewalldを停止してください(安全なネットワークなら)。
rsyncプロトコルを使ったリモートバックアップの手順は以下の通りです。

①バックアップ先のホストでrsyncをサーバとして起動する

起動する前に、設定ファイル /etc/rsyncd.conf を用意します。
バックアップはどうせroot権限で実行することが多いよね、ってことでuidとguidにはrootを指定しました。

次に、rsyncをデーモン起動します。

②バックアップ元ホストでrsyncコマンドによりバックアップを実行する

オプションの指定方法は同じですが、バックアップ先の指定方法が異なります。
コマンドの書式は以下の通り。

前述のバックアップと同じ仕様で、rsyncプロトコルを使ってバックアップするには以下のようにコマンドを実行します。

③バックアップ先ホストでrsyncデーモンをkillする

さて、このように実行したフルバックアップの性能はどうだったかというと。。。
処理時間は 65.7 sec、転送性能は 70.9 MB/s でした。
デフォルトの通信(ssh)でフルバックアップの性能が 96.3 MB/s なので、rsyncプロトコルのほうが遅いという結果になりました。理由はよく分かりません。。

チェックサムありの差分チェックが遅すぎる..

チェックサムありの差分バックアップは、ファイル内容をチェックサムで比較するので更新の判定が確実ですが、速度が遅すぎます。以下は、フルバックアップ直後の差分バックアップをチェックサムありで実行した結果です(ファイルの更新はないので、差分チェックに要した時間となります)。
試験環境1はbase0とbase1です。試験環境2はHDD x2台を有するサーバです。

	試験環境1	試験環境2
リモート or ローカル	リモート (1Gb Ethernet経由)	ローカル (HDD 1 から HDD 2)
ストレージ と IO性能	SATA SSD , 約400 MB/s	HDD x 2台, それぞれ 約 130 MB/s
バックアップ対象 と 容量	/usr , 4,640,728,735 bytes	/usr , 3,742,919,240 bytes
フルバックアップの時間 (性能)	45.9 sec (96.3 MB/s)	15.0 sec (237.7 MB/s)
差分チェック(チェックサムあり)の時間 (性能)	21.8 sec (203 MB/s)	22.5 sec (158.6 MB/s)

試験環境2で、性能がIO性能を超えてしまっているのは、ファイルシステムのキャッシュが働いているせいでしょうね。試験環境1では、差分チェックはフルバックアップの約半分ほどですが、試験環境2ではフルバックアップよりも長い時間がかかっています。IO性能がネックになっているのではないかと推測しています。

広告主へのリンク

ミニPCのお勧め

おウチでLinuxを勉強するのに、ミニPCはどうですか。
仮想環境(KVM)使えば、仮想マシンを複数起動できますし、とても安価にシステム構築の練習ができます。ミニPCはとっても静かで消費電力も小さいので部屋で常時起動させています。

このブログにおける関連リンク

・犬でも分かるrsync(1): rsyncの基本