FreeBSD 11.3Rでdailyバックアップシステムを復旧させましたが，数日間，運用していて特にトラブルもなく動いていました。そのため，すっかり油断していたのですが，ふと気がついたらnfsdが止まっていて，当然のようにdailyバックアップサーバーをマウントしている通常運用のディスクサーバーが道連れになっていました。ディスクサーバーからはNFSでマウントしているファイルシステムにアクセスしない限り大きな問題はないのですが，うっかりdfとか叩くとそのままフリーズして危険ですし，そもそもバックアップがとれないので大問題です。
というわけで，dailyバックアップサーバーの/var/log/messagesを調べてみました。すると，
Oct 6 15:35:55 ysaye kernel: pid 681 (ntpd), jid 0, uid 0, was killed: out of swap space
Oct 6 15:40:39 ysaye kernel: pid 438 (devd), jid 0, uid 0, was killed: out of swap space
Oct 6 15:46:32 ysaye kernel: pid 765 (master), jid 0, uid 0, was killed: out of swap space
Oct 6 16:34:11 ysaye kernel: pid 644 (nfsd), jid 0, uid 0, was killed: out of swap space
ってな具合でnfsdが落ちていました。swapって16GBも確保しているのになぜ？という感じです。起動時のdmesgをみると，
Sep 20 09:43:07 ysaye kernel: warning: total configured swap (4194304 pages) exceeds maximum recommended amount (3026904 pages).
Sep 20 09:43:07 ysaye kernel: warning: increase kern.maxswzone or reduce amount of swap.
などというwarningも出ていました。物理メモリの量から管理できるswapの量が決められている感じですが，同じマザーボード＋メモリでFreeBSD 10.0Rを使ってweeklyバックアップサーバーとして使っていた時には特に問題はありませんでした。3GBというメインメモリがzfsを使うには厳しいことはわかっていますが，swapは関係ないよなぁ，と思ってしまいます。
問題の切り分けの仕方がよくわからないのですが，まず，out of swap spaceについて調べてみました。すると，こういうスレッドとかこういうスレッドがあって，どうやら，out of swap spaceじゃないのにそのようなメッセージを出力するようです。前者のスレッドでは，うちと同じように最初にntpdが血祭りに上げられているようで，なんだか恐ろしい感じです。
ただ，zfsが鬼ののようにメモリを喰うことは間違いないので，ひょっとしてzfsのarcキャッシュをswap領域に取ろうとして足りなくなっているのか，とも考えられます。また，out of swap spaceのメッセージはディスクサーバーがdailyバックアップサーバーのディスクをnfsマウントしてrsyncで書き込みをしているときに突発的に発生しています。
そこで，ディスクサーバー上でdailyバックアップにつかうスクリプトを走らせながら，dailyバックアップ上でtopコマンドでメモリーの様子をモニタしてみました。すると，案の定，swapはまったく使われていません。topの出力をよくみると，MemのWiredがほぼ物理メモリをフルに使っていて，ARCのTotalも物理メモリとほとんど変わらない値になっています。それでどうやって動いているんだ，という素朴な疑問はさておき，zfsがキャッシュ用のarcを大量に消費していることは間違いなさそうです。
どういうタイミングかわかりませんが，このようにしてみていると，突然
Oct 8 04:14:11 ysaye kernel: pid 5295 (ntpd), jid 0, uid 0, was killed: out of swap space
というようなメッセージがでてntpdが血祭りに上げられて死んでしまいます。
起動時のswap容量が大きすぎる，というメッセージに関しては，あまり情報が見つけられなかったのですが，ここにそれらしいことが書かれています。kern.maxswzoneの設定を変えても何も改善しない，ということですが，
sysctrl -a | grep kern.maxswzone
とするとわかるようにこの変数には0が設定されていて，たぶん上限は設定されていないのだと思います。それにもかかわらず，
sysctrl -a | grep vm.swzone
vm.swzone: 51457368
と出てくるということは，上限の有無にかかわらず，swap管理用には51MBしか使われていないのだと思われます。
というわけで，swapからみのメッセージががいっぱいあるにも関わらず，問題はswap領域にはなさそうです。
なんて紛らわしいのでしょう。
swapの疑いがすっきりしたというわけでもないのですが，これ以上，swap関係を調べても無理そうなのでzfsに疑いの目をむけます。そもそも，物理メモリが3GBでzfsなんて使うな，って言われるとその通りなのですが，そうはいっても，もう，ECC付きのDDRメモリなんてもはや手にはいりません。手持ちのメモリではタイミングがあわず起動できなかったのです。
結局のところ，zfsをrootにインストールして起動させるのがお手軽になったからといって/boot/loader.confでのzfsまわりのメモリ使用量のチューニングをしなくてよい，というわけじゃない，ということのようです。物理メモリが3GBであればそれにあわせてちゃんと設定しろ，ってことですね。weeklyバックアップサーバーとしてFreeBSD 10.0Rをインストールしたときはちゃんとloader.confにメモリ使用量の上限を設定していましたので，およそそれにならって設定しておくことにします(設定値はいろいろと変えてます)。
/boot/loader.confにもともと書かれている，
zfs_load="YES"
の下に
vfs.zfs.arc_max="1G"
vm.kmem_size_max="1500M"
を追加して，zfsのarcの最大量を1 GBに制限して，カーネルが使うメモリも1.5 GBに制限して残りをその他のアプリケーションが使えるようにしました。nfsdとかntpdとかたいしてメモリを食わないアプリケーションしか使っていないのでたぶんこれで十分だろう，と思っています。ひょっとしたら，zfs.arcの上限を1.5 GBにして，kmemを1 GBにしたほうがよいのかもしれません。
とりあえず，これでdailyバックアップサーバーを再起動したうえで，ディスクサーバー上で日々のバックアップ用スクリプトを走らせてメモリの消費量をtopでモニタします。すくなくともARCのTotalは1 GB程度に抑えられていて物理メモリいっぱいまで行くことはなさそうな感じです。ただ，MemのWiredはほぼ物理メモリいっぱいまでいっちゃうので，本当にこれでよいのかどうかよくわかりません。
しばらく，これで様子を見て，これでもnfsdが血祭りに上げられるようであれば，OSを10.4Rにダウングレードしたほうがよいかもしれません。
メモリさえいっぱいあれば済むような話なのでなんとも無駄なことをやってます。
phpのバージョンアップ
気をつけてアップデートしているようにしていたのですが，9月は忙しく，サーバーのメンテを怠っていました。そういう時に限って職場のネットワーク管理者のスキャンに引っかかって毎度のことながらword pressのバージョンアップをせよ，と怒られてしまいました。
一瞬でできるのでやれば終わりなのですが，ダッシュボードをみると，恐ろしいことにPHP5.6は古すぎるから7.3にせよ，というメッセージが出ていました。メジャーバージョンアップはやりたくないのですが，php56はもはやFreeBSDのpkgのバイナリからも，portsからも消滅しています。後のメンテナンスを考えると7.3に上げておくしかありません。いまさら，7.2ってのもないだろう，ということで重い腰を上げました。
基本的にはここにある情報を参考にしました。
もう，よくわからないので目をつぶって作業する感じです。
1. apacheを停止。
/usr/local/etc/rc.d/apache24 stop
2. pkg delete php56\-\* としてphp56をまとめて削除。
3. pkg delete mod_php56
4. pkg install XXXXで片端から7.3系をインストールします。XXXXに対応するのは以下の通り。
php73-7.3.9
php73-curl
php73-ftp
php73-gd
php73-hash
php73-mbstring
php73-mysqli
php73-tokenizer
php73-xml
php73-zip
php73-zlib
mod_php73
5. /usr/local/etc/apach24/httpd.confは勝手にphp7を読み込むように
LoadModule php7_module libexec/apache24/libphp7.so
が追加されています。ついでに，
AddHandler php7-script .php
も追加しておきます。
6. apacheを起動してwordpressがちゃんと動いているか確認します。
いろいろと動かないプラグインがでてきますが，とりあえず，/usr/local/www/htdocs/wp-content/plugins/の下にあるディレクトリの名前をリネームして起動しないようにすると，とりあえずwordpressの本体だけは起動します。それでいいのか，って話もあるのですが，場当たり的対応としてはしょうがないと諦めてしまいます。
一瞬でできるのでやれば終わりなのですが，ダッシュボードをみると，恐ろしいことにPHP5.6は古すぎるから7.3にせよ，というメッセージが出ていました。メジャーバージョンアップはやりたくないのですが，php56はもはやFreeBSDのpkgのバイナリからも，portsからも消滅しています。後のメンテナンスを考えると7.3に上げておくしかありません。いまさら，7.2ってのもないだろう，ということで重い腰を上げました。
基本的にはここにある情報を参考にしました。
もう，よくわからないので目をつぶって作業する感じです。
1. apacheを停止。
/usr/local/etc/rc.d/apache24 stop
2. pkg delete php56\-\* としてphp56をまとめて削除。
3. pkg delete mod_php56
4. pkg install XXXXで片端から7.3系をインストールします。XXXXに対応するのは以下の通り。
php73-7.3.9
php73-curl
php73-ftp
php73-gd
php73-hash
php73-mbstring
php73-mysqli
php73-tokenizer
php73-xml
php73-zip
php73-zlib
mod_php73
5. /usr/local/etc/apach24/httpd.confは勝手にphp7を読み込むように
LoadModule php7_module libexec/apache24/libphp7.so
が追加されています。ついでに，
AddHandler php7-script .php
も追加しておきます。
6. apacheを起動してwordpressがちゃんと動いているか確認します。
いろいろと動かないプラグインがでてきますが，とりあえず，/usr/local/www/htdocs/wp-content/plugins/の下にあるディレクトリの名前をリネームして起動しないようにすると，とりあえずwordpressの本体だけは起動します。それでいいのか，って話もあるのですが，場当たり的対応としてはしょうがないと諦めてしまいます。