web-dev-qa-db-ja.com

スナップショットの数が増えると、LXD ZFSスナップショットの作成が遅くなる

Ubuntu 18.04 LTS-ループバックZFSを使用したLXD Ubuntuの起動（約400MB）

# lxc launch ubuntu:16.04 test -s ianzfspool

（同じianzfspoolを使用するアイドル状態のマルチGBコンテナーがもう1つあります。）プールに多くのスペースがあります。

# zpool list                                    
NAME         SIZE  ALLOC   FREE  EXPANDSZ   FRAG    CAP  DEDUP  HEALTH  ALTROOT
ianzfspool  99.5G  13.7G  85.8G         -     2%    13%  1.00x  ONLINE  -

lxcを使用してループし、アイドルテストコンテナ（400MB）のスナップショットを作成すると、最初のスナップショットが数秒で作成されます。 lxcスナップショットの数が増えると（現在は1,200を超えています）、作成に数分かかります。現在の日付を数秒ごとに/ tmpのファイルに入れるテストコンテナーで実行しているスクリプトがあるため、スナップショットごとにコンテナーで変更されるファイルが1つあります。それ以外の場合、コンテナはほとんどアイドル状態です。最初のlxcスナップショットは約25Kを使用しました。現在のスナップショット（1,200スナップショット後）は66Kを使用しています。 （2,470個のスナップショットの後、それぞれ115Kを使用し、7,500個のスナップショットの後、それぞれ293Kを使用します。）

#!/bin/sh -u                                                                   
# Create snapshots of the Ubuntu test container.
count=0
while : ; do
    count=$(( count + 1 ))
    cp=$( printf "%05d" $count )
    lxc snapshot test snap$cp
    echo "$0: done $cp" >/tmp/icount.txt
done

編集1：私は現在約2,470個のlxcスナップショットを作成しており、各新しいスナップショットは作成に約4分かかり、約115Kを使用しています。 zfs snapshotを使用する代わりに、lxc snapshotを呼び出してコンテナのスナップショットを直接取得すると、2,470個の既存のスナップショットであっても、スナップショットの所要時間は1秒未満です。直接zfsスナップショットは、（115Kではなく）20Kのみを使用します。 zfs listの実行には1〜2秒しかかかりません。 lxc listの代わりにzfs listを実行すると、現在、2,470の既存のスナップショットで4分以上かかります。そのため、スナップショットの作成とリストのスローダウンはZFSではなく、LXDで行われます。実際、lxdプロセス自体は4,253 CPU秒を使用し、このスナップショット作成実験でこれまでのところ3.9GのVSIZEを持っています。

lxcスナップショット作成スクリプトを一時停止し、直接zfsスナップショットを作成するループ用のスクリプトを作成し、3日間でlxcよりも多くのスナップショットを作成しました。約3,000の直接ZFSスナップショットの後にそれを一時停止しました。

lxc listを再実行しましたが、もちろん2,471 lxcスナップショットしか表示されませんが、4分ではなく40秒で実行されました。別のlxc snapshotを作成したところ、4分ではなく49秒しかかかりませんでした。何が変わった？直接zfsスナップショットの束を作成すると、何らかの形でlxcスナップショットの作成と一覧表示が高速化されましたか？ lxcスナップショットは、直接zfsスナップショットよりも作成に時間がかかりますが、lxcスナップショットの作成により改善されました（4分から49秒）。

ZFSスナップショットの作成を、10,000個の直接ZFSスナップショットが作成されるまで進めました。 （つまり、このテストコンテナの2,472 lxcスナップショットと10,000のダイレクトzfsスナップショットがあります。）lxc listは40秒ではなく90秒かかり、lxc snapshotは100秒かかります秒（49ではなく）。 ZFSを直接使用することは、LXDを使用するよりも2桁高速です。

編集2：再起動後、LXDスナップショットの作成が高速化されました。 lxc snapshotループを使用して7,470個のスナップショットを作成していますが、各スナップショットの作成には約30秒かかり、サイズは293Kです。 lxc listは45秒かかります。 zfs listは105秒かかり、17,507行の出力（10,000の直接ZFSスナップショットを含む）を生成します。 zfs snapshot ianzfspool/containers/test@iansnap10001を直接（LXD経由ではなく）実行するのにかかる時間は0.5秒未満です。LXD経由よりもはるかに高速です。

LXDスナップショットの作成が遅くなる理由と、速度を上げる方法に関するドキュメントはどこにありますか？ （ZFSスナップショットを備えたLXDが信じられないほど安かった場合、5分ごとにスナップショットを実行し、約1週間（2,016スナップショット）保持することを望んでいました。LVMスナップショットはパフォーマンスが低下することを読みました。 、しかし、私が読んだことはZFSでのLXDについて同じことを言っていません。LXDをバイパスしてZFSスナップショットを使用することができると思いますが、なぜそうする必要があるのですか？

ホスト上のlxdプロセスは多くのCPUを使用しており、大きくなっています（1,200スナップショット後）：

  PID VSTACK   VSIZE   RSIZE  PSIZE   VGROW   RGROW SWAPSZ   MEM  CMD        1/8
10663   132K    3.7G    1.1G     0K      0K      0K  2580K   14%  lxd
performancezfslxdsnapshot
1
Ian D. Allen

私はlxd snapshotの経験がないので、できることはその実装について推測し、ZFSスナップショットの詳細を伝えることです。

ZFSスナップショットは、進行中の読み取りおよび書き込みにオーバーヘッドが追加されないように設計されています。 （既に述べたように、LVMスナップショットは書き込み増幅の形でパフォーマンスのペナルティを追加します。）これを実現するために、ZFSにはtxg_syncと呼ばれる内部操作があり、これは最近のすべての非同期IOのバッチ書き込みのようなものです。 10秒ごとに自動的に発生し、ファイルシステム構造が変更されたとき（スナップショットを撮るときなど）に発生します。これにより大量のIOが発生するため、理論的には輻輳による同時同期書き込みの速度低下を引き起こす可能性があります（ただし、同期書き込みが優先されるはずです）。ただし、ファイルシステムにはほとんど何も書き込まれていないようです（おそらく、プールの残りの部分にはそれ以上の書き込みは行われていません）。

私の推測では、実際にはメタデータの読み取りが遅くなっているようです。理論的には、lxd snapshotはZFSスナップショットを取得して続行できますが、これには一定の（一定のIOロード）時間が必要です。ただし、その操作中にすべてのスナップショットをリストしようとすると（zfs listと同等）、それはすべてのスナップショットのメタデータの全体の読み取りを含むことを推測しています。スナップショットの数に比例して増加します。それが当てはまるかどうかを確認するには、ファイルシステムでzfs snapshotを直接計時し、ファイルシステムとそのスナップショットでzfs list -t allを実行して、どれがもう一方よりも長くかかるかを確認します（ 2番目のものでなければなりません）。

ZFSコミュニティではこれは既知の問題ですが、多くのディスク上のメタデータ構造を変更して改善する必要があり、この多くのスナップショットを保持することは非常に珍しいため、修正が困難です。 lxdがスナップショット操作を実行するためにすべてのスナップショットをリストすることを避けるために一生懸命努力した場合、問題を解決できると思います。

または、5分ごとにスナップショットを作成することもできますが、比較的迅速に削除し、5m、10m、15m、30m、1h、2h、3h、6h、12h、24hなどのスナップショットのみを保持します。これにより、ウィンドウが必要になる可能性が高いときに、ウィンドウの解像度が高くなり、lxd snapshotの速度が低下することもありません。

1
Dan