FreeBSDのネットワークチューニングについて調べてると「random harvestを最適化せよ」という指示が随所で出てくる。ネットワークなのに乱数？と不思議に思って調べたメモ。ここで書くことは、全て一次ソースのrandom(4)とrandom_harvest(9)に書いてあり、FreeBSD 12.1-RELEASE時点での情報である。
まずはrandom harvestについて。
FreeBSDは乱数を返すスペシャルファイル/dev/randomを持つが、通常、その実態は擬似乱数生成器となっている。つまり数式で求められた確定的な乱数っぽい数値を返しているに過ぎず、乱数っぽさの維持にはエントロピーの質が重要となる。FreeBSDでは、エントロピーの収集のことをrandom harvestと呼んでいるようだ。良質なエントロピーを育み利用する、という感じなので“harvest”はなかなか的を射た呼び方だと思う。
そのエントロピー収穫先を制御するのがkern.random.harvest.maskカーネル変数というわけ。
値は収穫先ごとのビットフラグで、1ならエントロピー源として使う、0なら使わないことを意味する。10進数のマスク値を見ても良くわからないので、エイリアスであるmask_symbolicやmask_binを見た方がいいだろう。うちの環境では以下のとおりだった。
$ sysctl kern.random kern.random.fortuna.minpoolsize: 64 kern.random.harvest.mask_symbolic: PURE_RDRAND,[UMA],[FS_ATIME],SWI,INTERRUPT,NET_NG,NET_ETHER,NET_TUN,MOUSE,KEYBOARD,ATTACH,CACHED kern.random.harvest.mask_bin: 00000010000000111111111 kern.random.harvest.mask: 66047 kern.random.random_sources: 'Intel Secure Key RNG'
mask_binがmask値の2進数表現、mask_symbolicがmaskを更に読みやすくしたシステムで利用可能なエントロピー源の一覧で、[]で囲まれた収穫先は使われていないことを意味する。FreeBSD 12.1-RELEASE時点で、24個のエントロピー源が定義されているようだ(sys/sys/random.h)。
ご覧の通りNET_ETHERもエントロピー源として使われている。それがなぜネットワーク性能に影響するかというと、エントロピー収穫の際のロック競合が少なくない影響を及ぼしているとのことだ。とりわけ、10ギガビット以上の高速ネットワークではバカにならないそうで。なるほどねー。
ZFSは2010年頃のPool Version 21で重複排除機能(dedup)を備えたが、本機能の使用は長らく禁忌とされてきた。というのも、Chr〇meも真っ青のレベルでメモリを馬鹿食いするからだ。ZFSの他の機能同様、dedupも有効にした後の書き込みから機能するため、当初は問題なく動いてるように見える。が、徐々にメモリが使われて行き「なんか重いなぁ…」と気付いた時には既に遅し、メモリが枯渇しているのである。慌ててdedup=offにしても、既に重複排除された分は効き続けるため、メモリは減ったままというオマケ付き。dedup地獄から抜け出すには、メモリを増設するかスワップを大量に割り当て、既存の重複排除が解除されるのをひたすら耐えるしかない。
そんな訳でdedupの実用は難しかったのだけども、メモリ16GBは人権宣言から1年、フッ化水素騒動も何のその、メモリ価格は下落を続け個人でメモリ1TBも現実的となってきた昨今、そろそろdedupを解禁しても良いのではないか。
FreeBSD Mastery: ZFSによると、dedupはデータ1TBあたり概ね5GBのメモリを消費するそうだ。うちの自宅サーバはメモリ64GBでメインのプールは8TBなので、dedupを有効にしてもお釣りがくる計算だ。ならば人柱よろしくdedupっちゃおうじゃないの。ちなみに、同書にはdedupメモリ消費量のより詳しい見積もり方法が書いてある。気になる人は買って読んでください。
dedupを有効にするプールzhomeは以下のような感じ。8TBのHDDを2本(ada5とada6)のミラー構成としている。改めてみるとファイルシステム名のつけ方が酷いな…。
$ zpool status zhome
pool: zhome
state: ONLINE
scan: scrub repaired 0 in 0 days 02:21:29 with 0 errors on Thu Oct 24 11:57:54 2019
config:
NAME STATE READ WRITE CKSUM
zhome ONLINE 0 0 0
mirror-0 ONLINE 0 0 0
ada5p1 ONLINE 0 0 0
ada6p1 ONLINE 0 0 0
logs
mirror-1 ONLINE 0 0 0
nvd0p3 ONLINE 0 0 0
nvd1p3 ONLINE 0 0 0
cache
nvd0p7 ONLINE 0 0 0
errors: No known data errors
$ zpool list zhome
NAME SIZE ALLOC FREE CKPOINT EXPANDSZ FRAG CAP DEDUP HEALTH ALTROOT
zhome 7.27T 1.22T 6.04T - - 2% 16% 1.00x ONLINE -
$ zfs list -r zhome
NAME USED AVAIL REFER MOUNTPOINT
zhome 1.22T 5.81T 96K /zhome
zhome/R 1.21T 5.81T 88K /zhome/R
zhome/R/home 1.21T 5.81T 1.21T /usr/home
zhome/ROOT 15.5G 5.81T 96K /zhome/ROOT
zhome/ROOT/nextcloud 6.78G 5.81T 6.78G /mnt/nextcloud
zhome/ROOT/vm 8.69G 5.81T 88K /zhome/ROOT/vm
zhome/ROOT/vm/virtcurrency 8.69G 5.81T 8.69G /zhome/ROOT/vm/virtcurrency
とりあえずホームディレクトリが置いてあるzhome/R/homeでdedupを有効にしてみる。
# zfs set dedup=skein zhome/R/home
dedup=onではなくdedup=skeinなのは、チェックサムアルゴリズムとしてSkeinを使いたいから。
dedupは標準でSHA-256を使うようになっているが、manを見る限りSkeinはSHA-256/SHA-512より安全かつ高速で、更にプール固有のソルトを用いるためハッシュ衝突攻撃にも強いらしい。「sha512は何からの理由で高速なskeinが使えないシステムで使う」とも書いてあるので、基本はskeinで良さそう。
その後、別プールにあるISOイメージやらインストーラやらが詰まってる493GBのフォルダを、dedup有効のプールにコピーした結果が以下。
$ zpool list zhome NAME SIZE ALLOC FREE CKPOINT EXPANDSZ FRAG CAP DEDUP HEALTH ALTROOT zhome 7.27T 1.64T 5.62T - - 3% 22% 1.11x ONLINE -
重複排除率が1.11xってのは……たぶん2.00xならdedupで実使用量が半分になったって事だろうから、(重複排除できたサイズ)=(1-(1/DEDUP))*(元のサイズ) なので48GBほど排除できた感じっすかね？
この時のメモリ使用量の変化は下図のとおり。
ARCサイズはloader.confでvfs.zfs.arc_max=“20G”として20GBに制限している。dedup前はARCを20GBフルに使ってるのに対し、dedup後は15GBになっていることから、dedup用のハッシュキャッシュはARCから確保されるっぽい？
データ493GBでハッシュ5GBって冒頭の概算の2倍消費しとるやんけ！と思ったが、Skeinは512bitハッシュなので比率で考えたら見事に概算通りの結果となった。そう考えると、メモリ64GB程度ではdedupを使うにはまだ心許ない感じがするなぁ……（何というオチ）。ちなみに、将来dedupのメモリ消費量が削減される可能性があるっぽい。
まぁ、せっかくdedup有効にしてみたんだし、しばらく運用してみよう。NVMeなSSDも載ってるので、最悪そっちに大容量スワップ作れば何とかなるだろう。
(2020-01-06 追記)
dedup有効後、6日ほど経ったのでtopを見てみたら、ARCが20GBに戻ってた…。ARCからハッシュキャッシュから取られる訳ではなさそう？ちゃんと調べてみないと分かりませんな……。
last pid: 26323; load averages: 0.21, 0.20, 0.17 up 71+13:01:17 22:29:52
51 processes: 1 running, 50 sleeping
CPU: 0.8% user, 0.0% nice, 0.3% system, 0.0% interrupt, 98.9% idle
Mem: 295M Active, 1465M Inact, 25G Wired, 35G Free
ARC: 20G Total, 11G MFU, 6802M MRU, 1530K Anon, 369M Header, 1446M Other
17G Compressed, 24G Uncompressed, 1.43:1 Ratio
Swap:
FreeBSDのcpコマンドは拡張ファイル属性を一切コピーしない。FreeBSD 12.0-RELEASE-p4で確認。すなわち、現時点ではFreeBSDでcpすると拡張ファイル属性が失われる。
「-pオプションを付ければいいんじゃね？」と思ったあなた、あまーい！cpのmanにある通り、-pオプションはファイルの変更日時、アクセス日時、フラグ、パーミッション、ACL、UID、GIDしか保持しない。
ここに拡張ファイル属性付きのファイルhasxattr.txtがあるじゃろ。
$ ls -al total 42 drwxr-xr-x 2 Decomo Decomo 3 10月 22 00:11 . drwxr-xr-x 56 Decomo Decomo 190 10月 21 23:43 .. -rwxr--r-- 1 Decomo Decomo 0 10月 21 23:49 hasxattr.txt $ lsextattr user * hasxattr.txt OpusMetaInformation DOSATTRIB
そしてcp -pするじゃろ。
$ cp -p hasxattr.txt hasxattr_cp-p.txt
拡張ファイル属性を表示すると…
$ lsextattr user * hasxattr.txt OpusMetaInformation DOSATTRIB hasxattr_cp-p.txt
＼(^o^)／
ファイラーで表示させてみても見事にコピーした方は拡張ファイル属性が消えている（オレンジ色のカラーラベル情報がOpusMetaInformationっていう拡張ファイル属性に保存されてる）。
拡張ファイル属性好きとしては悲しい…。
sysutils/coreutilsに入ってるGNU cpならどうだと試してみるも、つれないお返事…
$ gcp --preserve=xattr hasxattr.txt hasxattr_gcp.txt gcp: 拡張属性を保護できません。cp が xattr サポートなしで作成されています
rsync -Xやmvでは拡張ファイル属性が保持される。
$ rsync -X hasxattr.txt hasxattr_rsync.txt $ mv hasxattr.txt hasxattr_mv.txt $ lsextattr user * hasxattr_cp-p.txt hasxattr_mv.txt OpusMetaInformation DOSATTRIB hasxattr_rsync.txt OpusMetaInformation DOSATTRIB
調べてたら、FreeBSD/Linux/MacOSのコマンド別に拡張ファイル属性の対応状況が書いてある素敵なぺージを発見。
Extended attributes: the good, the not so good, the bad.
それにしても、coreutilsのビルドオプションでgcpの拡張ファイル属性対応を選べるようにして欲しいなぁ…。
graphics/pecl-imagickをインストールしようとFreshPortsでportの情報見てたら、“Package flavors”なる項目があるのに気付いた。
ハンドブックによれば、Flavorsとは1つのportに複数のバリエーションを持たせる方法とのこと。多くの機能といくらかのパッケージ依存関係を持つノーマルバージョンと、最低限の機能と依存関係しかない軽量バージョンの2つのFlavorをportに持たせるとか、GUIツールキット毎にFlavorを分けるとか、そういう使い方を想定しているようだ。
2017-11-30にリリースされた仕組みで、どうやらPythonモジュール関連portsの整理かなんかで導入された雰囲気（一次情報を追ったわけではないので当てずっぽう。同日にpy36-*のportsは全てFlavor化されpy-*に統合されている）。
件のpecl-imagickについて言えば、php71/php72/php73とPHPのバージョンごとにFlavorが用意されている（2019-08-15現在）。Flavorの有無はそれぞれのportのディレクトリでmake pretty-flavors-package-namesとすると確認できる。
$ cd /usr/ports/graphics/pecl-imagick $ make pretty-flavors-package-names php73: php73-pecl-imagick-3.4.4 php71: php71-pecl-imagick-3.4.4 php72: php72-pecl-imagick-3.4.4
Flavorの指定はmakeでFLAVOR変数に渡せばおｋ。
# make FLAVOR=php73
これはなかなか便利ですな。
以前は、lang/php71を使いたいのにPECL拡張モジュールのportはPHP 5.6向けになってて、PHP 7.1用には自前でpeclコマンド叩いて入れなきゃならないって事があったけど、Flavor使えばports/packagesにおんぶにだっこできて楽チン。
あ、書いてて思い出したけど、Flavor付きのportはFlavorごとにpackageが分かれる点は留意の必要あり。上のコマンド例で分かる通り、php73フレーバーでpecl-imagickをインストールした場合、パッケージ名はphp73-pecl-imagickとなる。
A5:SQL Mk-2を使って、実家からVPN経由で自宅鯖のMariaDBにアクセスしようとしたら「Access denied for user'xxxx'」と言われて繋がらなかった。デフォルトでは自ホストのクライアントからの接続しか許可してないらしいので、リモートクライアントからの接続を許可してみたメモ。丁寧なhttps://mariadb.com/kb/en/library/training-tutorials/basic-mariadb-articles/configuring-mariadb-for-remote-client-access/公式ドキュメントが用意されてるので、その通りに進めていくだけですけどね。
'my.cnfの[mysqld]''セクションに以下の2行を追加する。
[mysqld] skip-networking=0 skip-bind-address
ユーザーにリモート接続の権限を付加する。許可するホストとパスワードを追加してるっぽいので、接続元ごとにパスワードを変えられるっぽい？
GRANT ALL PRIVILEGES ON *.* TO 'root'@'172.16.%' IDENTIFIED BY 'new-password' WITH GRANT OPTION;
こんな感じで追加されてればおｋ。
> SELECT user,host FROM mysql.user; +--------------+-----------+ | user | host | +--------------+-----------+ | root | 127.0.0.1 | | root | 172.16.% | ←これ
