☰

zfs 伝送性能

tag-icon • tag-icon solaris performance zfs
zfs 伝送性能

zfs ファイルシステムをバックアップしようとすると、奇妙なパフォーマンスの問題が発生します。

zfsファイルシステムの内容を100MB / s以上に圧縮できますが、zfs転送の転送速度はおそらく5MB / sです。ファイルシステムには5〜6個のスナップショットしかありません。タールには約1.5時間かかります。 zfs転送には12時間以上かかります！

どちらの場合も、ターゲットは別のプール内のファイルです。 （つまり、zfs send tank/myfs > /backup/myfs.zfsbackup 大tar -cf /backup/myfs.tar ./myfs）

最初は断片化だと思いましたが、それならタールもそれほど遅くないでしょうか？

全体的なディスクパフォ​​ーマンスは大丈夫ですが、実際にバックアップするのに時間がかかります。

私はx64ハードウェアでSolaris 11.4を実行しています。概念的には、この質問はLinuxのzfsに似ているかもしれませんが、Linuxの変形にはあまり慣れていません。

zfs sendの実行中に、約12分間、以下の回答で提供されたdtraceスクリプトを実行しました。

dtrace -i 'profile:::profile-1001hz /arg0/ { @[ stack() ] = count(); }'

結果をどのように解釈するのかわかりません。要約の 2 つの部分には、多数の zfs 呼び出しが含まれています。

      zfs`zfs_fletcher_4_native+0x79
      zfs`zfs_checksum_compute+0x181
      zfs`zio_checksum_compute+0x1d6
      zfs`zio_checksum_compute_dispatch+0x28
      zfs`zio_checksum_generate+0x59
      zfs`zio_execute+0xb4
      genunix`taskq_thread+0x3d5
      unix`thread_start+0x8
     1041

      unix`bcopy+0x55a
      genunix`uiomove+0xb3
      zfs`dmu_xuio_transform+0x83
      zfs`zfs_write+0x78a
      genunix`fop_write+0xf5
      genunix`vn_rdwr_impl+0x1f3
      genunix`vn_rdwr_uiov+0x63
      zfs`dump_buffer_flush+0x8e
      zfs`dump_buffer_append+0x85
      zfs`dump_bytes_impl+0x49
      zfs`dump_bytes+0x49
      zfs`dump_record+0x190
      zfs`dump_data+0x26a
      zfs`backup_cb+0x4b5
      zfs`traverse_visitbp+0x3df
      zfs`traverse_visitbp+0x8e4
      zfs`traverse_visitbp+0x8e4
      zfs`traverse_dnode+0x1dc
      zfs`traverse_visitbp+0x6d2
      zfs`traverse_visitbp+0x8e4
     1183

呼び出し数が最も多いのはCPUアイドル呼び出しのようです。

          unix`mach_cpu_idle+0x17
          unix`cpu_idle+0x2b7
          unix`cpu_idle_adaptive+0x19
          unix`idle+0x11e
          unix`thread_start+0x8
      1147665

          unix`mach_cpu_idle+0x17
          unix`cpu_idle+0x2b7
          unix`cpu_idle_adaptive+0x19
          unix`idle+0x11e
          unix`thread_start+0x8
      2462890

zfs転送中にドライブは忙しかったが、待ち時間なしでサービス時間はそれほど悪くないと思いました...

                    extended device statistics
    r/s    w/s   Mr/s   Mw/s wait actv wsvc_t asvc_t  %w  %b device
 157.0    0.0    4.9    0.0  0.0  1.6    0.0   10.5   0  77 c0t5000C500A22D9330d0
 154.0    0.0    4.9    0.0  0.0  1.7    0.0   11.0   0  82 c0t5000C500A232AFA6d0
 186.0    0.0    6.4    0.0  0.0  2.4    0.0   12.7   0  93 c0t5000C500A24AD833d0
 185.0    0.0    6.3    0.0  0.0  1.8    0.0    9.9   0  79 c0t5000C500A243C8DEd0

tar中のディスク使用量はr / s、サービス時間、％busyなどかなり似ているように見えますが、読み取ったデータ量は非常に異なります。

                    extended device statistics
    r/s    w/s   Mr/s   Mw/s wait actv wsvc_t asvc_t  %w  %b device
 158.0    0.0   33.3    0.0  0.0  1.9    0.0   11.9   0  86 c0t5000C500A22D9330d0
 190.0    0.0   31.9    0.0  0.0  1.6    0.0    8.3   0  75 c0t5000C500A232AFA6d0
 170.0    0.0   37.1    0.0  0.0  1.7    0.0    9.7   0  80 c0t5000C500A24AD833d0
 168.0    0.0   38.4    0.0  0.0  1.7    0.0   10.1   0  80 c0t5000C500A243C8DEd0

答え1

コマンドを実行すると、zfs send ...このdTraceコマンドを実行してカーネルが時間を費やしている場所を確認できます。

dtrace -i 'profile:::profile-1001hz /arg0/ { @[ stack() ] = count(); }'

コマンドを起動し、rootしばらく実行してクリックして停止するCTRL-Cと、数値が増加する順序でサンプリングされたすべてのカーネルスタックトレースがエクスポートされます。

したがって、見つかった最も一般的なスタックトレースは最後のスタックトレースになります。カーネルがほとんどの時間を過ごす場所がここです。

この情報は役に立つかもしれませんし、そうでないかもしれません。

または、次のファイルに保存できます。

#!/usr/sbin/dtrace -s

profile:::profile-1001hz
/arg0/
{
    @[ stack() ] = count();
}

私はdTraceがSolaris 10に初めて登場して以来、この小さなスクリプトを使用してきました。これはおそらく私が見た中で最も便利な単一のdTraceスクリプトです。なぜなら、「システムは実際に何をしていますか？」という質問に対する答えを教えてくれるからです。

関連情報