カテゴリー
FreeBSD Mac

netatalk3.1 が遅いのでなんとかしたい

無事に FreeBSD 上に ZFS+netatalk3.1 の環境が出来たものの、 OS X からアクセスすると異常に遅いのです。 どのくらい遅いかというと、 Mavericks な MacBook Pro 15″ Late 2011 で 1.4GiB 程度の Aperture Library をコピーするのに

  • 内蔵HDDのコピー 
    time cp -a benchmark.aplibrary test.aplibrary
cp -a benchmark.aplibrary test.aplibrary  0.23s user 3.89s system 4% cpu 1:25.86 total
  • afp でマウントした OS X Server の HFS+(Drobo) 
    time cp -a benchmark.aplibrary /Volumes/TimeMachine/tmp
cp -a benchmark.aplibrary /Volumes/TimeMachine/tmp  0.76s user 24.04s system 1% cpu 32:48.23 total
  • afp でマウントした OS X Server の HFS+(Mac mini の内蔵HDD) 
    time cp -a benchmark.aplibrary /Volumes/goro/work 
cp -a benchmark.aplibrary /Volumes/goro/work  0.71s user 22.70s system 2% cpu 14:06.93 total
  • afp でマウントした FreeBSD の ZFS 
    goro@sara:~/work/cptest$ time cp -a benchmark.aplibrary /Volumes/goro/Pictures
cp -a benchmark.aplibrary /Volumes/goro/Pictures  0.62s user 19.68s system 0% cpu 1:05:07.36 total
  • nfs でマウントした FreeBSD の ZFS(メタデータ無視なので参考記録) 
    time cp -rX benchmark.aplibrary ~/work/mnt
cp -rX benchmark.aplibrary ~/work/mnt  0.15s user 12.76s system 3% cpu 5:59.79 total

遅いと思ってた Drobo よりさらに遅いとか僕はどうしたら…。ということでせめて Drobo 並み(といっても今の倍のスピードか…)になることを目指して頑張ります。 頑張るとは言っても nfs では速いので、おそらくは netatalk3.1 のメタデータ周りが遅いのだろう、ということでテストもういっこ追加

  • afp でマウントした FreeBSD の ZFS(メタデータ無視) 
    time cp -rX benchmark.aplibrary /Volumes/goro/Pictures
cp -rX benchmark.aplibrary /Volumes/goro/Pictures  0.17s user 13.37s system 0% cpu 47:01.30 total

なん…だと…!? 確かにメタデータありでコピーするよりはマシであるとはいえ、それでも Drobo さんより遅いとは…。ちなみに tar で固めて、 tarball をコピーだとこんな結果でした。

  • tar で固める 
    time tar cf benchmark.tar benchmark.aplibrary
tar cf benchmark.tar benchmark.aplibrary  0.42s user 3.89s system 9% cpu 45.515 total
  • コピー 
    time cp -rX benchmark.tar /Volumes/goro/Pictures
cp -a benchmark.aplibrary /Volumes/goro/Pictures  0.58s user 18.47s system 1% cpu 25:24.90 total

ファイルが多いと遅い、という話なのかしらん?
ということで afp.conf を見てみると

[Homes]
        basedir regex = /Users
        spotlight = yes

そういえば 3.1 からの新機能だってんで勢いで Yes にしていた spotlight サポートが臭い、かな? ということでこれを切って /usr/local/etc/rc.d/netatalk restart して再度コピー実施。

time cp -a benchmark.aplibrary /Volumes/goro/Pictures
cp -a benchmark.aplibrary /Volumes/goro/Pictures  0.61s user 23.10s system 0% cpu 1:03:45.32 total

誤差だった…。この程度の差なら積極的に off にする理由はないなぁ。

改めて公式のドキュメントを眺めてみたのだけど、変更することでパフォーマンスを改善しそうなパラメータがなさそうな雰囲気。となるとやっぱり CNID をメモリに乗っけるしかないかなー、ということで実験。良い子のみんなは真似しないでね!

df -h /var/netatalk
 47M    /var/netatalk

テストだから 128M ぐらい準備すればいいかな

sudo mdmfs -s 128m md1 /mnt

と作って

sudo cp -a /var/netatalk /mnt
sudo mv /var/netatalk /var/netatalk.old
sudo ln -s /mnt/netatalk /var

とかして再度計測

time cp -a benchmark.aplibrary /Volumes/goro/Pictures
cp -a benchmark.aplibrary /Volumes/goro/Pictures  0.58s user 18.47s system 0% cpu 25:24.90 total

あっさりと Drobo より速くなりました…どんだけボトルネックなのよ CNID …。

であればやはり CNID をメモリなり SSD なりに置くというのが一番お手軽なチューニングですかね…もしくは CNID backend を他のサーバーに移しちゃう? どうせこのシステムはユーザー認証を OS X Server に依存してるので、  OS X Server に MySQL 立ててそこに置いちゃうというのも選択肢なのかも…。と、ここまで書いて md 使うより tmpfs 使うほうが FreeBSD 的みたいな雰囲気を感じたので再度実験。

sudo cp -a /var/netatalk /var/netatalk.old
sudo rm /var/netatalk
sudo mkdir /var/netatalk
sudo mount -t tmpfs tmpfs /var/netatalk
sudo cp -a /var/netatalk.old /var/netatalk

で tmpfs をマウントして

time cp -a benchmark.aplibrary /Volumes/goro/Pictures
cp -a benchmark.aplibrary /Volumes/goro/Pictures  0.59s user 19.16s system 1% cpu 25:44.52 total

誤差だな! が、 /etc/fstab に書ける分 tmpfs にしたほうがいいような気もする…。容量考えなくていいし(調子に乗ってると ZFS が死にます)

ということで、まとめると

  • CNID は SSD とかメモリに置くと快適(メモリに置くのはリスキーだけどな!)
    • CNID 置き場が遅いと afpd の動作は重くなる
  • netatalk 3.1 を使うなら spotlight yes のほうが幸せ(のような気がする)

…クラッシュが怖いけど、 tmpfs に CNID 置いて、定期的に HDD にコピーして多少の不整合には目を瞑る、というのが正解なのかなぁ(多分続く)

コメントを残す