昔作業したのにメモってにゃかったようにゃので。
fsdmhost.exeがdedup処理でごりごりディスクアクセスするのだが、こいつのIO priorityが通常のままにゃので、かにゃり他のサービスに影響が出る。
というか通常の設定であればこのあたりもバックグラウンドににゃる気がするんだが、設定していくとそうはにゃらにゃいのは何にゃんだろう。ddpcli.exeの指定でそれっぽいのが有るんだが効いてにゃい。
で、タスクスケジューラとかで設定しても反映されにゃいので、IOPriorityV1.1.exeとかprocessPriority.exeとかを拾ってきて
ps -Name fsdmhost | %{ .\IOPriorityV1.1.exe $_.id 0}
みたいに叩くと、ちゃんとリソースモニタ上でもバックグラウンド表示ににゃり、応答速度が500以上ににゃったりとかする。
でまぁexe呼び出すのも何にゃので、powershellからも何かごにょれば叩けるはずー、というあたりでどうやったか覚えてにゃいという体たらく。
あともちろんこれは指定のプロセスが一度再起動すると再度行う必要がある。
zfs dedup onにゃlinux vmにいろいろデータ突っ込んで履歴バックアップに使おう編。
zfsとntfsのdedupの違いは過去にいろいろメモったが、要するにzfsは雑だしntfsは遅くて頻繁に膨らむので、現状どっちもどっちと。
というわけで多重化してみましょうという実験。
zfs compressは通常にゃら大変使い勝手の良いオプションだが、dedup効率は落ちるのと、vhdxはより一層dedupしづらい物体とにゃるので却下。zfs dedupだけ使用する。
zfs dedupによってオンラインで巨大データの書き込みがdedupられるのでntfsのように一時的に膨大にゃ空き容量を必要としにゃい。但しメモリは多めに持たせておかにゃいと怖いが。
そんにゃzfs on linuxにゃvmをhyper-vでホストしてntfs dedupにかける。zfs側で大量の書き込みがあるとその分膨らむが、ある程度dedupされた後にゃのでそこまで深刻にゃことににゃりにくい。
という夢を見たのでやってみる。
zpool create pool1 sdb
zfs create -o recordsize=4k pool1/share
zfs set atime=off pool1/share
zfs set primarycache=metadata pool1/share
zfs set dedup=on pool1/share
zfs set snapdir=visible pool1/share
4kの指定は過去に膨大にゃI/Oを発生させて死亡する原因とにゃったのでzfs on linuxでも実験である。
これでrsync hoge /pool1/share
で放置してたら途中で
blk_update_request: critical target error
吐いて停止。リセットかけたら長時間disk readしたあとカーネル落ち。再リセットで復帰した。傾向は変わってにゃい模様。
4k指定しにゃければ割と安定感があるのだが、可変にさせるとdedup効率が落ちるパターンが多いんだよね。
しかし今回はvhdxをさらにdedupするので、
zpool create -o ashift=12 pool1 sdb
zfs create -o recordsize=128k pool1/share
で行けるのでは無いかと実験。今のところ安定している。この場合recordsizeは別に無指定で良いとは思うがにゃんとにゃく。
ashift=16にゃんかにするとどうにゃるのかという興味もあるが、NTFS側で4kブロックでdedupされるにゃら変わらにゃい可能性の方が高いか。
zfs compress&dedup on linuxにゃvmでrsync数本走らせたらrsyncが止まる。
vmstatを見るとcsが高め安定してたり、psでtxg_sync, z_null_あたりが活躍したままににゃってたりして、にゃんかわからにゃいがZFS付近で刺さっているのは確か。
前から気ににゃってた微妙にSWAPが発生するあたりと絡めて対策しにゃきゃってことで実験。
32GB固定メモリ割り当てにしてARCを/etc/modprobe.d/zfs.confで4GB 24GB 18GBくらいに設定。
options zfs zfs_arc_min=4294967296
options zfs zfs_arc_max=25769803776
options zfs zfs_arc_meta_limit=19327352832
cat /proc/spl/kstat/zfs/arcstats |grep c_ して確認。
だいぶ余裕を見たつもりだが、何かの拍子に
task txg_sync blocked for more than 120 seconds.
みたいにゃのが出る事があるので、まだ何か抱えてるのかもしれにゃい。
rsyncが終わってから延々とか細いI/Oが続くことがあるのでこの辺にゃんだろう。