差分

このページの2つのバージョン間の差分を表示します。

--- os:zfs_tips [2020/01/17 10:58] – atime と空き容量の話を追記した yuichiro
+++ os:zfs_tips [2022/09/13 11:33] (現在) – [atime は off に] yuichiro
@@ 行 14: / 行 14: @@
 そのため、後から自分で追加したプールに対して設定が必要となります。
+ただし、 zroot/var/mail だけは atime on に設定されます。tcsh などがメールの到着をチェックするためです。
 ==== プールには必ず空き容量を確保すること ====
 ZFS は Copy On Write が基本です。
-ファイルを削除する場合でもディレクトリの書き換えが発生する分、コピーが発生します。
+ファイルを削除する場合でもメタデータやディレクトリの書き換えが発生する分、コピーが発生します。
 このときコピーできるだけの容量がプールになければファイルを削除することができません。
 もし、プールを 100% 使い切ってしまうと、それはリードオンリーになることと同じ意味を持ちます。
@@ 行 31: / 行 32: @@
 パーティションがないほうが性能面では有利になりますが、その差はわずかです。
-長年運用を続けたあとにハードディスクを故障で交換する際にセクタ数まで含めて同じハードディスクが
+長年運用を続けたあとにハードディスクを故障で交換する際にセクタ数まで含めて同じハードディスクを入手できるかどうかは分かりません。
-入手できるかどうかは分かりません。
 おそらくより大容量のモデルを購入することになるでしょう。
 その場合、予めパーティションを作成しておけば、同じサイズにパーティションを切り直すだけで、
@@ 行 38: / 行 38: @@
 余ったパーティションを他の用途に使うこともできます。
 ディスク障害から復旧したら後日、プールサイズの拡張などを検討すればよいのです。
+==== ARC の使用量を知る ====
+ZFSのプールがあれば top(1) が ARC のサマリを表示します。
+以下に表示のサンプルを示します。
+<code>
+ARC: 2864M Total, 884M MFU, 1793M MRU, 1696K Anon, 34M Header, 150M Other
+M Compressed, 4466M Uncompressed, 2.16:1 Ratio
+</code>
+それぞれの項目の意味は次の通りです。
+^ 項目 ^ 内容 ^
+| Total | ARC全体のデータ量 |
+| MFU | 最もよく使われるデータとして保持している量 |
+| MRU | 最も間近に使われたデータとして保持している量 |
+| Anon | 一時的なデータとして保持している量 |
+| Header | ヘッダのデータ量 |
+| Other | その他のデータとして保持している量 |
+| Compressed | 圧縮した状態で保持しているデータ量 |
+| Uncompressed | 圧縮前のデータ量 |
+| Ratio | 圧縮率 |
 ==== ARC サイズの制限  ====
@@ 行 44: / 行 67: @@
 つまり 8GB のメモリを搭載した環境では 7GB まで ARC に使われる可能性があります。
-これを制限するパラメータが sysctl の vfs.zfs.arc_max です。
+これを制限するパラメータが sysctl の vfs.zfs.arc.max ((13.0-RELEASE より前は vfs.zfs.arc_max でした))です。
 アプリケーションにどの程度メモリを空けて置きたいのかを考えて、ARC を制限しましょう。
@@ 行 50: / 行 73: @@
 <code>
-sysctl vfs.zfs.arc_max=4294967296
+sysctl vfs.zfs.arc.max=4294967296
 </code>
@@ 行 114: / 行 137: @@
 zfs のバックアップにスナップショットを send & recv するのは定番とも言えますが、
 ファイルシステムの使用量が大きくなるとバックアップに時間がかかるようになります。
-ひょっとかするとネットワークの不調などで途中で止まってしまうことがあるかもしれません。
+ひょっとするとネットワークの不調などで途中で止まってしまうことがあるかもしれません。
 その場合、最初からやり直すのはとても辛いため、途中からやり直すことができます。
@@ 行 133: / 行 156: @@
 ２回目以降の zfs send にはトークンのみを渡して、ファイルシステム名は渡しません。
 zfs recv の受け側は必要に応じて ssh や nc などを利用するとネットワーク経由でバックアップすることができます。
+==== dedup は安易に使わないこと ====
+dedup はファイルの中の重複箇所を自動的に検出し、zfsのブロック単位でまとめてくれる便利な機能ですが、反面ハッシュ値の保持や比較に多くのリソースを使用します。
+dedup では1つのハッシュを保持するのに320bytesを消費するため、例えば1ブロック128kbで2TBのデータを保持したとすると5GBのメモリを使用します。
+<code>
+,147,483,648 KB / 128 = 16,777,216 blocks
+* 16,777,216 = 5,368,709,120 bytes = 5GB
+</code>
+もちろん、この値はARCとは無関係です。
+そして全ての書き込みでハッシュ値との比較処理が走ります。
+資源面、性能面ともに多くのリソースを必要としますので、通常は使わないほうが良いです。
+また、dedup を有効にした後に書き込まれたファイルは常に dedup 用のハッシュ値を保持するようになります。
+dedupを無効にしてもその後に書かれたファイルに対してハッシュ値の比較が行われなくなるだけで既に書き込まれたファイルは dedup の対象となります。
+完全に無効化するにはファイルを再度コピーする必要があります。
+もちろん、上記のリソースを確保した上で dedup を使用することには何の問題もありません。
+==== swap ボリュームについて ====
+zfs ではプールからブロックデバイスを生成する機能があるため、これを swap として利用することができます。
+しかし、swap はメモリが逼迫したときに使用されるものですので、そもそも大量にメモリを使う zfs で swap を賄うのは矛盾した状態を生み出します。
+例えば、zfs の ARC が増大しアプリケーションが使えるメモリが少なくなったために
+swap を使用するような場合、swap に書き込みが行われることで更に ARC を使用しますます使えるメモリが減ることにつながります。
+swap を zfs 上に取るのは便利ではありますが、あまり得策とは言えません。
 ==== PostgreSQL ====
+=== atime ===
+atime は off にしましょう。理由は前述の通りです。
 === record size ===
@@ 行 184: / 行 237: @@
 </code>
-==== MySQL ====
+==== MySQL (innodb) ====
+=== atime ===
+atime は off にしましょう。理由は前述の通りです。
+=== record size ===
+データ用とログ用に2つのファイルシステムを用意します。
+データ用には recordsize=16k を、ログ用はデフォルトの recordsize=128k を設定します。
+^ 用途 ^ recordsize ^
+| データ用 | 16k |
+| ログ用 | 128k (default) |
+innodb はデータの読み書きを一度に 16k ずつ行うため、それに合わせます。
+ログ用は追記のためデフォルトのままでかまいません。
+=== log bias ===
+innodb でもログを先行書き込みしますので zfs でログを書き込む必要はないとも言って良いでしょう。
+データ用のファイルシステムに対し logbias=throuput を設定し zfs のログの書き込みを OFF にします。
+ログ用については失われると困るため、デフォルトのまま logbias=latency が良いでしょう。
+^ 用途 ^ logbias ^
+| データ用 | throuput |
+| ログ用 | latency (default) |
+=== primary cache ===
+MySQL もアプリケーション側で必要なデータをメモリ内にキャッシュします。
+こちらを十分に効かせれば ZFS でキャッシュさせる必要性は低くなりますので、
+primarycache=metadata を設定し、メタデータのキャッシュのみを行うようにします。
+データ用、ログ用、どちらにも言えます。
+^ 用途 ^ primarycache ^
+| データ用 | metadata |
+| ログ用 | metadata |
+=== compression ===
+lz4 による圧縮は非常に高速に動作します。 圧縮率はそれほど良くはありませんが、半分程度に圧縮されれば、見た目のスループットは2倍に向上します。圧縮率が悪くても lz4 が高速に動作するためペナルティが少なく、設定するメリットは十分にあります。
+データ用、ログ用ともに compression=lz4 を設定しておくと良いでしょう。
+^ 用途 ^ compression ^
+| データ用 | lz4 |
+| ログ用 | lz4 |
+=== skip_innodb_doublewrite ===
+my.cnf に skip_innodb_doublewrite を設定し MySQL にデータを2回書く処理を止めさせます。
+これはもともと 16k のデータの内、半分の 8k だけはディスクに書かれたが残りの 8k は書かれていないようなタイミングで電源喪失などが発生した際にそれを検知するためのものです。
+Copy On Write の ZFS ではどのようなタイミングでもこういう事にはならないため、単純に OFF にすることができます。
+回の書き込みが1回に減る分、性能向上が期待できます。
+==== MySQL (MyISAM) ====
+=== atime ===
+atime は off にしましょう。理由は前述の通りです。
+=== record size ===
+MyISAM は一度に 8k ずつデータを読み書きしますので、recordsize=8k を指定します。
+ログ用にディレクトリを分けることができませんので、データ用に合わせます。
+=== primary cache ===
+MyISAM でもアプリケーション側で必要なデータをメモリ内にキャッシュします。
+primarycache=metadata で zfs の arc 使用量を制限し、アプリケーション側で使えるメモリを増やします。
+=== log bias ===
+データとログが同じファイルシステムに置かれるため、安全のためデフォルトのまま logbias=latecy にするのが良いでしょう。
+=== compression ===
+lz4 で得られるメリットは innodb と同じです。
-<未稿>