何かの拍子に、Tomcat 7.0で動かしているサービスのタイムゾーンがUTCとして認識されるようになってしまった。マシンのRTCは昔からUTCで、OSのロケール≒タイムゾーンも以前からJSTで特に変更はしてないのだが…。

変わっちゃったもんは仕方ないんで、Tomcatのタイムゾーンを変更する方法を調べたところ、setenv.shでCATALINA_OPTS環境変数を弄ればいいらしい。setenv.shってどこにあんのよっていうと、/usr/local/apache-tomacat-7.0/bin/である。もっとも自分の環境（FreeBSD 10.3-RELEASE-p26/Tomcat 7.0.59）ではsetenv.shは無かったんだけど、startup.shを見るにsetenv.shがあれば読み込むように見えたので、新規で作ったら上手く行った。

setenv.shの中味は以下の通り。

export CATALINA_OPTS='-Duser.timezone=Asia/Tokyo'

あとはApacheとTomcatを再起動してやればおｋ。

とても今更なんですけどね、Mozilla謹製JPEGライブラリ群の一部、jpegtranによるJPEG最適化の効果に驚愕しとるわけです。

PENTAX K-1を買ってからというものPCのストレージの減り方が半端なく、そりゃJPEG+RAWで撮ってれば1シャッターにつき60MB前後の容量を食うので当たり前なわけでありますが、冗談抜きで空き容量が逼迫しとるんですわ。1TBのSSDうち820GBをデータ用に割り当ててるのに、現時点で残り2.3GBですよ。使用量のうち8割が写真であるからして、白羽の矢が立ったのがMozJPEGというわけ。（RAWが一番容量食ってるってツッコミはなしなんだぜ。）

とりあえず急場凌ぎで、画像の品質には一切影響を与えないjpegtranで最適化してみたら、縮むこと縮むこと。元の画像サイズが大きいことも相まって、1枚あたり1MB弱ほど小さくなった。論より証拠ってなもんでスクショをご覧頂こう。

圧縮データの最適化、つまり無劣化でここまで縮むんだから大したもんですよ。もっとも、演算能力や処理時間の制約が厳しいデジカメで生成されたJPEGデータなので、最適化の余地が大きかろう点は考慮の必要があるだろうが…。

画像右端の「算術符号」ってのは、-arithmeticオプションで最適化した結果である。ハフマン符号最適化（-optimizeオプション）より更に小さくなっており、その効果には目を見張るばかりだが、哀しい哉、特許の関係で算術符号でエンコードされたJPEGに対応したソフトは皆無…。試した範囲では、MacOS X v10.9のプレビュー.app、Photoshop CC 2015.5、Firefox 58のいずれにおいても表示する事ができなかった。フォトショとLightroomで使えれば、手元のデジタル写真ライブラリの容量削減に大きく寄与するんだがなー。口惜しい…。

ついでに言うと、-optimizeより-arithmeticの方が処理時間が短かったりするのよね。軽くて縮むとかどんだけだよ。本当に口惜しい……。MacBook Pro (Late 2013)での処理時間は↓こんな感じ。

・-optimizeの時
real    3m35.907s
user    3m22.685s
sys     0m11.282s

・-arithmeticの時
real    3m12.291s
user    2m57.712s
sys     0m11.897s

-copy allオプションを付ければJPEGに含まれるメタデータは全て引き継がれる。少なくともexiftoolで比較した限りでは、元ファイルと最適化後のファイルでExifの相違はなかった。

個人的には元ファイルのタイムスタンプも継承したかったので、下記のようなシェルスクリプトで処理した。

#!/bin/sh
 
TARGETDIR="$1"
OUTDIR="$1/out"
FILES=`find "$TARGETDIR" -maxdepth 1 -type f -name '*.JPG'`
 
echo `pwd`
 
mkdir -p $OUTDIR
for file in $FILES; do
	echo $file
	CTIME=`GetFileInfo -d "$file"`
	MTIME=`GetFileInfo -m "$file"`
	OUTFILE="$OUTDIR/$file"
	jpegtran -optimize -progressive -copy all "$file" > "$OUTFILE"
	#jpegtran -arithmetic -progressive -arithmetic -copy all "$file" > "$OUTFILE"
	SetFile -d "$CTIME" "$OUTFILE"
	SetFile -m "$MTIME" "$OUTFILE"
done

ご覧の通り、エラー処理とか何も入れてないので、元ファイルが無関係のファイルが無くなってもしらにゃい(´・ω・｀)。GetFileInfoとSetFileを使ってるのでXcodeを入れとく必要がある、つまりこのスクリプトはMac専用なんだぜ。

ブリッジネットワーク接続の仮想マシンがあり、その通信がCiscoのCatalystスイッチを通るネットワーク構成の時は、スイッチのポートセキュリティ設定に気をつけなければならない。さもないと仮想マシンが通信できなくてハマる。VMとLAN内の物理マシンとでARP RequestとReplayは通っており、互いのARPテーブルは正しく作られているように見えるのに通信が出来なくて超ハマる。3ヶ月くらい悩んでた…（ヽ´ω`）

port-securityが有効なポートでは、最初に通過したMACアドレス以外のフレームが破棄される。

ここで、ブリッジ接続の仮想マシンのフレームは、物理マシンが繋がってるポートに流れる事になる。つまり、1ポートに対して複数のMACアドレスが関連付けられるわけだが、port-securityが有効だと最初の通信のMACアドレスしか有効にならない。それは殆どのケースで物理マシンのMACアドレスになるので、VMは一切通信出来なくなるという寸法。逆にいえば、物理マシンの通信ならOKなので、NATでVMの通信を物理マシンの通信に変換してやれば通信できるということだ。実際、NAT接続でなら通信出来てた。

対策方法は次の3つ。

1. port-securityを無効化する
2. 信頼するMACアドレスを静的に追加する
3. 学習するMACエントリの上限を引き上げる（デフォルトでは1個）

自宅ネットワークならport-security無効化が簡単で影響も殆どないかと。

この問題を調べてる時に、ブリッジ接続が上手くいかないと嘆いているロシアのフォーラムを見つけたんだけど、結局使ってるホスティング業者を変えたら動いた！って結末だったので、恐らくダメだった方の業者のスイッチで似たようなセキュリティ設定になってたんだろうと思う。

原因がわかって全てが繋がった感じ。通信だけにね(´・∀・｀ )

• Catalystスイッチ - ポートセキュリティ
• DAI（Dynamic ARP Inspection）とは
• FreeBSD 11.1 Release, bhyve и сетевой мост if_bridge - forum.lissyara.su

仮想マシンのストレージ形式について、一般的にはイメージファイルよりもzvolの方が適していると言われている。ホストのファイルシステムレイヤを通過したファイル上にゲストのFSレイヤを通したFSを構築するよりかは、zvol（の薄いレイヤしか通らない）のブロックデバイスをゲストのFSレイヤに渡した方が効率が良さそう、ってのは理屈としても合っている。

以前から実際に速度比較しようと思いつつ、ようやく実行に移せた。環境は以下の通り。

• ホスト
  • FreeBSD 11.1-RELEASE-p1
  • VirtualBox 5.2.0
    • CPU: Xeon E5-2648Lv3 1.8GHz 12C24T
    • RAM: 64GB
    • SSD: Intel DC S3500 480GB
      • SATA 3接続
      • ZFSのLZ4で透過圧縮している
• ゲスト
  • Windows 7 Ultimate (x64)
    • CPU: 4コア
    • RAM: 8GB
    • SSD: VirtIO 40GB

ゲストのストレージを、同一内容のイメージファイルとzvolデバイスとで切り替えてCrystalDiskMark 6.0.0で速度を計測した。なお、イメージファイルからzvolへの変換は以下のコマンドで行った。

VBoxManage clonehd /path/to/vms/Windows/HDD.vmdk /path/to/vms/HDD.raw --format RAW
zfs create -V 40G zvm/zvols/Windows
dd if=/path/to/vms/Windows/HDD.raw of=/dev/zvol/zvols/Windows bs=4096
VBoxManage internalcommands createrawvmdk -filename /path/to/vms/Windows/zvol.vmdk -rawdisk /dev/zvol/zvols/Windows

おろ、殆ど変わらんがな…(´・ω・`)。シーケンシャルR/W共にSATA 3の上限ぶっちぎっちゃってるし、ホストのキャッシュが効いちゃってる？

というわけで、VirtualBoxの「ホストのI/Oキャッシュを使う」オプションを切って再計測。

すごく、、、速いです………。こりゃZFSのキャッシュが効いてるなー。確認してみるとARCで4.8GB持ってるしなー。ベンチ中にtopで見てるとARCがもりもり増えてくし。

ついでにイメージファイルをHDDに置いた時のベンチも取ってみた。

うっは2.5インチHDDとは思えぬ速さwwwww

zpool iostatの結果を見るに、ランダムライトはZFS側でまとめられ、ほぼシーケンシャルライトとしてHDDに書き出されているようだ。

               capacity     operations    bandwidth
pool        alloc   free   read  write   read  write
----------  -----  -----  -----  -----  -----  -----
zhome2      1.33T  1.38T      1    922   153K   105M
  mirror    1.33T  1.38T      1    922   153K   105M
    ada3p1      -      -      0    861  25.5K   105M
    ada2p1      -      -      0    875   127K   107M
logs            -      -      -      -      -      -
  mirror      40K  3.97G      0      0      0      0
    ada0p4      -      -      0      0      0      0
    ada1p4      -      -      0      0      0      0
----------  -----  -----  -----  -----  -----  -----

               capacity     operations    bandwidth
pool        alloc   free   read  write   read  write
----------  -----  -----  -----  -----  -----  -----
zhome2      1.33T  1.38T      2    932   277K   111M
  mirror    1.33T  1.38T      2    932   277K   111M
    ada3p1      -      -      0    919  50.4K   114M
    ada2p1      -      -      1    890   227K   110M
logs            -      -      -      -      -      -
  mirror      40K  3.97G      0      0      0      0
    ada0p4      -      -      0      0      0      0
    ada1p4      -      -      0      0      0      0
----------  -----  -----  -----  -----  -----  -----

               capacity     operations    bandwidth
pool        alloc   free   read  write   read  write
----------  -----  -----  -----  -----  -----  -----
zhome2      1.33T  1.38T      0    962   102K   119M
  mirror    1.33T  1.38T      0    962   102K   119M
    ada3p1      -      -      0    941   102K   117M
    ada2p1      -      -      0    965      0   120M
logs            -      -      -      -      -      -
  mirror      40K  3.97G      0      0      0      0
    ada0p4      -      -      0      0      0      0
    ada1p4      -      -      0      0      0      0
----------  -----  -----  -----  -----  -----  -----

               capacity     operations    bandwidth
pool        alloc   free   read  write   read  write
----------  -----  -----  -----  -----  -----  -----
zhome2      1.34T  1.38T      1    940   153K   113M
  mirror    1.34T  1.38T      1    940   153K   113M
    ada3p1      -      -      0    918  76.7K   113M
    ada2p1      -      -      0    906  76.7K   112M
logs            -      -      -      -      -      -
  mirror      40K  3.97G      0      0      0      0
    ada0p4      -      -      0      0      0      0
    ada1p4      -      -      0      0      0      0
----------  -----  -----  -----  -----  -----  -----

結論としては、イメージファイルでもzvolでも大差なさそう。ストレージ形式の差よりも、ZFSそのものの動作環境やチューニングの差の方が覿面に影響しそう。なので、好きな方を使えばいいんじゃないかな。俺は扱いやすいイメージファイルの方を選ぶんだぜ。

とりあえずZFSパネェ…。

(2017-11-25 追記)

ついでにbhyveでもやってみた。

ストレージは同一SSDだけど、計測環境は新規インストールのWindows 10なので厳密な比較にはならんけど。なお、ストレージはahci-hdで繋いでる。virtio-blkはWindowsでは現状未対応らしい。

ベンチ結果は左から、gzip-5のZFS上のイメージファイル、同zvol、lz4なzvol。

物理メモリ1.5GBのFreeBSD 11.1-RELEASE環境で、16GBのスワップを追加したら以下のメッセージが表示された。

warning: total configured swap (4194304 pages) exceeds maximum recommended amount (2994784 pages)
warning: increase kern.maxswzone or reduce amount of swap.

カーネルが扱えるサイズを超えるスワップを追加すると出るそうで。本事例だと、最大スワップサイズは2994784ページで、1ページ=4KiBなので約11.4GiBとなる。

この値はどこで決まるかと言えば、warningの2つ目で示されているkern.maxswzoneカーネルパラメータである。スワップ管理用メモリの最大バイト数を指定するパラメータで、11.1Rではスワップ約200MiBにつき1MiBが必要とのこと。特に指定しなければ、物理メモリの8倍のスワップを扱うのに十分な容量が確保される。

実際に確保された量は恐らくvm.swzoneパラメータの値。本事例では53904384バイトとなっており、計算するとwarning中の最大スワップサイズと概ね一致する。

というわけで、/boot/loader.confに次の一行を追加してみた。

kern.maxswzone="75464704"

値はまー適当。11.4GiBで53904384バイト必要なんだから、16GBなら1.4倍して一応4KiB単位に揃えた感じ。

これで再起動すればOK!

……のハズだったんだけど、なぜか値が反映されないの(´・ω・｀)。kern.maxswzoneには反映されるんだけど、肝心のvm.swzoneが変わってない。警告も相変わらず出る。kern.maxswzoneは名前の通り最大値を制限するものであって、スワップの最大サイズは物理メモリの8倍という制限は超えられないって事なのかしら…？これ以上はソース見ないとわからんな。

• loader(8)
• kern.maxswzone
• FreeBSD で swap デバイスを増やし続けると…: uyota 匠の一手