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スクリプトです。なぜなら、「システムは実際に何をしていますか？」という質問に対する答えを教えてくれるからです。