Solaris 11/OpenIndianaのtips集
-
- いいね！0
TAKI, Yasushi (瀧 康史)
@kohju
zfsのシステムにおいて、ログローテートでファイル圧縮は禁物。CoWなのでスナップショットとると、ディスクには非圧縮と圧縮の両方ができるよ。 #osoljp
2011-06-16 03:05:05
TAKI, Yasushi (瀧 康史)
@kohju
logrotateやlogadm、あるいはcronなどで圧縮などせず、zfsのcompressionをonにしましょう。 #osoljp
2011-06-16 03:05:43
TAKI, Yasushi (瀧 康史)
@kohju
zfsのsnapshotが取られてるシステムでは、ディスクが足りなくなったとしてもファイルはリムーブできないよ。CoWなのでファイルのremoveだってディスクをちょとつかうのです。snapshotを整理することからはじめよう！ #osoljp
2011-06-16 03:07:02
TAKI, Yasushi (瀧 康史)
@kohju
auto snapshotは（デフォルトでは）8割を越えると自動的に消える。でもディスクを8割り以上使うと、METASLABが最速一致から最良一致に変わるのでとってもおそくなるよ。ディスクには常に余裕を。 #osoljp
2011-06-16 03:08:45
TAKI, Yasushi (瀧 康史)
@kohju
なーんていうかんじで、コツコツZFSの運用ぷちtipsをtwitterで流しておくと、みんな便利なのかな？ #osoljp
2011-06-16 03:10:53
TAKI, Yasushi (瀧 康史)
@kohju
zfsのdedupは銀の弾ではない。zfsのdedupは書き込み時にリアルタイムに行われるため書き込み速度が劣化する。on/offはいつでもデータセット単位でできるので、重複が多く発生しそうな作業前にONにすると良い。 #osoljp
2011-06-20 11:10:23
TAKI, Yasushi (瀧 康史)
@kohju
zfsのdedupは銀の弾ではない。zfsのdedupは書き込み時にリアルタイムに行われるため書き込み速度が劣化する。on/offはいつでもデータセット単位でできるので、重複が多く発生しそうな作業前にONにすると良い。 #osoljp
2011-06-20 11:10:23
TAKI, Yasushi (瀧 康史)
@kohju
dedupはアロケートサイズでハッシュをつくり、書き込み時にハッシュテーブルを検索する。またハッシュテーブルがメモリ内に乗っている間は良いが溢れるとL2ARC→ディスクの順で追い出される。当然メモリが溢れると著しく速度劣化する。 #osoljp
2011-06-20 11:12:25
TAKI, Yasushi (瀧 康史)
@kohju
dedupはアロケートサイズでハッシュをつくり、書き込み時にハッシュテーブルを検索する。またハッシュテーブルがメモリ内に乗っている間は良いが溢れるとL2ARC→ディスクの順で追い出される。当然メモリが溢れると著しく速度劣化する。 #osoljp
2011-06-20 11:12:25
TAKI, Yasushi (瀧 康史)
@kohju
compressと異なりzfs recvの瞬間もdedupは効くので、仮想サーバ等のデータ転送時に一時有効する手もある。ハッシュ計算はcryptoadmで出力されるハード支援があれば速く、zfs get recordsizeで出力されるサイズが大きいと良い。 #osoljp
2011-06-20 11:17:40
TAKI, Yasushi (瀧 康史)
@kohju
compressと異なりzfs recvの瞬間もdedupは効くので、仮想サーバ等のデータ転送時に一時有効する手もある。ハッシュ計算はcryptoadmで出力されるハード支援があれば速く、zfs get recordsizeで出力されるサイズが大きいと良い。 #osoljp
2011-06-20 11:17:40
TAKI, Yasushi (瀧 康史)
@kohju
recordsizeが大きい＝処理単位が大きい、ハッシュ計算単位が大きい・・・ので、ハッシュテーブル検索の量が減るのが原因。ただしアロケートの時の無駄なバッファが増えるので、逆に容量節約にならないデメリットも。 #osoljp
2011-06-20 11:19:35
TAKI, Yasushi (瀧 康史)
@kohju
recordsizeが大きい＝処理単位が大きい、ハッシュ計算単位が大きい・・・ので、ハッシュテーブル検索の量が減るのが原因。ただしアロケートの時の無駄なバッファが増えるので、逆に容量節約にならないデメリットも。 #osoljp
2011-06-20 11:19:35
Noriyasu Sakaue
@nslope
ZFSでfilesystemのsnapshotをとった後、snapshotの中身を確認したい場合、マウント先直下に.zfsというディレクトリができる。 #osoljp
2011-06-22 21:12:01
Noriyasu Sakaue
@nslope
.zfs/snapshot/以下にとったsnapshotがreadonlyでmountされている。ファイル単位で戻したい場合とかはここからコピーすればOK #osoljp
2011-06-22 21:12:16
Noriyasu Sakaue
@nslope
ただし、.zfsディレクトリはsnapdirプロパティをvisibleにしないと(デフォルトはhidden)ls -aでも確認はできない。見えなくても移動することはできるのであんまり問題にはならないけど。 #osoljp
2011-06-22 21:12:39
Noriyasu Sakaue
@nslope
sharesmbプロパティをonにするとCIFSサーバが起動し、そのfilesystemが公開対象になる。 #osoljp
2011-06-22 21:13:23
Noriyasu Sakaue
@nslope
この状態でsnapshotをとると、snapshotも公開対象になる（Windowsだと「以前のバージョン」のアレ）#osoljp
2011-06-22 21:13:38
Noriyasu Sakaue
@nslope
Time sliderと組み合わせると毎時、毎日、毎週、毎月のバージョン管理が簡単に出来上がる。 #osoljp
2011-06-22 21:13:55
TAKI, Yasushi (瀧 康史)
@kohju
zfs autosnapは便利だが、dataset数とautosnapが増えていくと、iostatの%bが100に張り付くほど遅くなることがある。zfs ver31以前のシステムでは顕著。IOパフォーマンスが低いシステムは、autosnapは必要最低限に #osoljp
2011-06-24 16:39:42
TAKI, Yasushi (瀧 康史)
@kohju
zfs ver26までは特定のzfsのスナップショットを消すのに、iostatの%bが100%に張り付くぐらい負荷を掛けることがある。こうなるとシステムにインパクトあるので削除時は注意すること（経験則では古すぎるスナップな気がするが理由はまだ未調査） #osoljp
2011-06-24 16:34:01