最近の変更サイトマップ

InnoDB File-Per-Tableモードではinnodb_data_home_dirは無視される

MySQL/MariaDBにinnodb_data_home_dirというシステム変数がある。InnoDBのデータファイル置き場を明示する変数だが、InnoDB File-Per-Tableモードでは指定値が無視される。File-Per-Tableモードとは、InnoDBのテーブル毎にファイルを作成するモードの事でinnodb_file_per_table変数で制御可能である。MySQL 5.6.6以降でデフォルト有効になったため、innodb_data_home_dirは事実上意味がなくなってしまった。

よって、File-Per-TableモードではZFSのrecordsizeprimarycacheをストレージエンジン毎に最適化する、という手法が取りにくくなった。(DBごとにフォルダが作成され、その中にInnoDBやMyISAMのファイルが混在することになるため。)自分のメモも兼ねて最適とされるパラメータを下表にまとめる。

ストレージエンジン recordsize primarycache
MyISAM 8kBall
InnoDB(データ) 16kBmetadata
InnoDB(ログ) 128kBmetadata

参考サイト

FreeBSD 11.2-RELEASEでZFSのトップレベルvdevの削除機能が取り込まれてた

OpenZFS Developer Summit 2018を眺めてたら、Device Removalなるスライドを発見。タイトルの通りvdevの取り外しに関する機能である。

ご存知の通りZFSでは、一度プールに組み込んだデバイスの削除に非常に厳しい制約がある。プールのスケールアップは極めて容易な一方、スケールダウンは事実上不可能だった。しかしDevice Removalによって、ミラー構成のvdev限定ではあるものの削除が可能となる。

嬉しい人には嬉しいと思われるこの機能、なんとFreeBSD 11.2-RELEASEで既に取り込まれてた。11.2Rのmanから説明を引用してみる。

Removes the specified device from the pool. This command currently only supports removing hot spares, cache, log devices and mirrored top-level vdevs (mirror of leaf devices); but not raidz.

スライドの方にしか書いてないけど、この機能でミラー構成トップレベルvdevを削除するには、各vdevのashiftが同量じゃないと駄目らしい。ashiftはvdev単位での設定なので、デバイス追加時は注意が必要。

RAID-Zでも使えるようになってほしいけど、実装面ではRAID-Z Expansion頼みかしら…?こっちの進捗具合はどうなってんだろうなー。去年のちょうど今ごろRAID-Z Expansionに関する記事を書いたものの、とんと続報がない。FreeBSD 12で実装見込みとのことだったが、十中八九間に合わないだろうなー。現時点で12.0Rは12月頭のリリース予定だし…。

SambaとZFSで大量のファイルを扱う時はcase-sensitiveの組み合わせを最適化する

同一フォルダに大量のファイルがあるとSambaが超遅くなる問題、自分なりの知見が得られたのでメモ。結果だけ知りたい人は最後までスクロールしてくだしあ。

まずはおさらい。

ことの発端は、数万個のファイルがあるフォルダをSambaのファイルサーバにコピーすると、速度が10kB/s前後まで低下する現象に見舞われた。速度はコピーが進むごとに低下し、比例してsmbdのCPU占有率が上がるというのが特徴。サーバ上で直接コピーすると何の問題もない。

調査を進めると、ファイル作成時Sambaはファイル名の重複チェックのため、作成先フォルダ内の全ファイル名を検査することが分かった。この時に行われるWindowsのファイル名規則(FS上は大文字/小文字を区別するが、一般的なファイルアクセス上は区別しないナンチャッテcase-preserving。この差はOSが吸収する。)と合わせるための、ファイル名を大文字ないし小文字に変換する処理がボトルネックのようだ。

プロファイルしたわけでもソースコードを見たわけでもないので確証はないが、公式ドキュメントに「ディレクトリに大量のファイルがある特殊なケースでは、case sensitiveをyesにせよ」(抄訳)と書かれており、ファイルコピーの進捗にあわせ指数関数的に速度が落ちる(CPU負荷が上がる)という挙動から、たぶん当たってると思う。

ではcase sensitive = yesにすれば万事解決かといえば、そうじゃない罠。

前述の通りWindowsはFS的にはcase-sensitiveだが、歴史的理由で表面的にはcase-insensitiveとして振る舞う。この仕様に胡坐をかき、ファイルパスを内部的に大文字or小文字に変換して扱うアプリケーションが少なくない。例えば、本来のファイルパスはC:\Data\FILE.datにもかかわらず、アプリケーション内部では c:\data\file.datとしてアクセスすることが往々にある(自分もそういう処理をつい書いちゃうんだけど(;'∀'))。ローカルのファイルに対してなら、これでも問題はない。

しかし、サーバの共有フォルダに対しては、アプリから渡されたファイルパスをそのまま渡しているようだ。故にサーバ側がその辺を考慮した処理になってないと、ファイルが見つからないという事になる。Sambaのcase sensitiveオプションは、まさにその辺の制御を設定するオプションなのだ。これをyesにするということは、\\Server\Data\FILE.datと\\Server\data\file.datは別のファイルと見なされる、ということだ。アプリからすれば、\\Server\Data\FILE.datが見つからないということになる。これでは使い物にならない。

ではどうするか。ZFSのcasesensitivityプロパティの登場だ。

お察しの通りその名の通りのプロパティで、デフォルト値はcasesensitiveである。これをcaseinsensitiveにしてやればいい。insensitiveという名付けではあるが、挙動としてはpreservingのようだ。ちなみに、mixedというのもあるが、使いどころがよくわからない挙動なので指定しない方が無難(一応、Windowsを想定した挙動らしいんだけど…)。

本プロパティはFS作成時にしか指定できないため、Windows共有用のFSを新規に作り、Sambaで共有フォルダに仕立て上げるのがよいだろう。

Sambaがファイル名をキャッシュせずファイル作成毎に全舐めしてしているのは、恐らく対象フォルダに対する変更をSamba側で検知する仕組みがないからだと思う。Sambaがファイルを作成しようとしたまさにその時、同名のファイルがサーバのローカルで作られたり、別のファイルがリネームされたりする可能性があるため、キャッシュではファイル名のユニーク性を担保できないのだろう。

一方、ファイルシステムレベルなら、そのような変更の検出とアトミック性・ユニーク性が保証された素敵な仕組みがあるハズだから、アプリ側でファイル名の全比較を行うより効率的なんじゃねっていう目論見。

結論としてはSambaとZFSで以下の設定を行うと幸せになれる。ZFSじゃない人はスマン…

  • ZFS
    • ファイル共有用にcasesensitivity=caseinsensitiveなFSを作る
      zfs create -o casesnsitivity=caseinsensitive ztank/path/to/cifs

  • Samba
    • ファイル名の扱いをcase-sensitiveにする

      case sensitive = yes
      case preserve = no
      short preserve case = no

ZFSが自動マウントされない時はzfs_enable="YES"になっているか確認する

FreeBSDで起動時にルートプール以外のZFSファイルシステムが自動マウントされない時は、/etc/rc.confzfs_enable=“YES”しているか確認する。この指定がなくとも、ルートプール=システムが入っているプールは自動マウントされるので、なかなか問題に気づきにくい。自動マウントされないFSのcanmountmountpointプロパティを見ても問題ないし、原因が判るまで苦労したんだぜ★

インストーラに頼らず、手動でFreeBSDをインストールした場合なんかは特に注意が必要だ。

今更ながらZFSはキャッシュのヒット率が超重要

この記事には技術的裏付けがない、個人の感想、雑感、推測がふんだんに含まれています。ご利用の際は用法・用量を守り正しくお使いください。

知人のNAS4Freeなファイルサーバが重い問題、Sambaが原因で一件落着かと思いきや解決してなかった。(こっちはこっちで別の問題が発生してたりするので別途書く予定。)

知人とやり取りしつつCPU, ネットワーク, ディスクI/O, その他諸々を継続的にモニタリングしてみると、どーにもディスクアクセスがボトルネックになっている事があるようで…。ファイルサーバのターミナルで直接cpしても、全然速度が上がらないのだ。対象のファイルは、50~200kBの数十万個のPNGを含む膨大なファイル群で、ファイルシステム的に結構厳しい条件ではあるものの、ストレージは仮にもHDD 2ペア×3セットからなるRAID10である。十数MB/sは出るだろうと思ってたが、実際には1MB/s以下になることさえある。

いくらなんでもオカシイだろうとzpool iostatしてみた結果がこちら。

               capacity     operations    bandwidth
pool        alloc   free   read  write   read  write
----------  -----  -----  -----  -----  -----  -----
zdata       4.56T  6.31T  5.65K    435  25.5M  4.94M
zdata       4.56T  6.31T  7.43K      0  32.7M      0
zdata       4.56T  6.31T  5.44K      0  24.1M      0
zdata       4.56T  6.31T  6.20K      0  27.3M      0
zdata       4.56T  6.31T  6.44K      0  28.4M      0
zdata       4.56T  6.31T  5.81K    398  26.6M  3.89M
zdata       4.56T  6.31T  4.36K    215  34.8M  10.8M
zdata       4.56T  6.31T  2.76K    391  12.5M  3.47M
zdata       4.56T  6.31T  3.58K      0  19.7M      0
zdata       4.56T  6.31T  3.65K      0  20.1M      0
zdata       4.56T  6.31T  3.15K      0  17.7M      0
zdata       4.56T  6.31T  4.05K      0  19.0M      0
zdata       4.56T  6.31T  2.59K    343  14.6M  3.15M
zdata       4.56T  6.31T  3.66K      0  19.6M      0
zdata       4.56T  6.31T  4.99K      0  32.5M      0
zdata       4.56T  6.31T  2.93K      0  19.1M      0
zdata       4.56T  6.31T  6.38K      0  28.4M      0
zdata       4.56T  6.31T     3K    344  13.6M  2.99M
zdata       4.56T  6.31T  3.86K      0  17.9M      0
zdata       4.56T  6.31T  3.77K      0  16.9M      0
zdata       4.56T  6.31T  3.72K      0  16.8M      0
zdata       4.56T  6.31T  2.91K    226  13.3M  2.39M

読み込み操作数(operations)と読み込み量(bandwidth)の割に、書き込み量が著しく少ない。コピーと並行してSambaへ断続的なアクセスがあるってことを差し引いても全然スループットが出てない。つーか、書き込み量とネットワークに出ていく量を合わせても全然読み込み量に足らん罠。

大量の読み込みoperationsが走ってても、いい感じに処理できてる時は↓こんな感じで順当にbandwidthが上がる。CIFSによるリクエスト分がそのまま処理されてネットワークに流れていっている。

               capacity     operations    bandwidth
pool        alloc   free   read  write   read  write
----------  -----  -----  -----  -----  -----  -----
zdata       4.70T  6.17T  15.3K    638  64.8M  7.06M
zdata       4.70T  6.17T  23.8K      0   101M      0
zdata       4.70T  6.17T  20.4K      0  85.9M      0
zdata       4.70T  6.17T  23.6K      0  98.7M      0
zdata       4.70T  6.17T  18.4K      0  76.5M      0
zdata       4.70T  6.17T  7.06K    720  30.1M  8.41M
zdata       4.70T  6.17T  16.6K      0  70.0M      0
zdata       4.70T  6.17T  13.7K      0  57.7M      0
zdata       4.70T  6.17T  18.1K      0  77.3M      0
zdata       4.70T  6.17T  16.7K    536  72.3M  6.52M
zdata       4.70T  6.17T  7.63K     80  32.5M   376K
zdata       4.70T  6.17T  12.3K      0  52.7M      0
zdata       4.70T  6.17T  9.78K      0  42.4M      0
zdata       4.70T  6.17T  11.8K      0  51.0M      0
zdata       4.70T  6.17T  9.32K    586  40.4M  6.41M
zdata       4.70T  6.17T  9.47K      0  40.6M      0
zdata       4.70T  6.17T  11.6K      0  49.2M      0
zdata       4.70T  6.17T  12.1K      0  51.8M      0
zdata       4.70T  6.17T  5.05K      0  22.2M      0
zdata       4.70T  6.17T  4.88K    579  22.1M  6.61M

rsyncでディスク内コピーを行うと更に悲惨で、びっくりするほど速度が出ない。ネットワーク(1000BASE-T)越しの別マシンにzfs sendし、そいつとrsyncで同期した方が早いっていうね…。すわ、断片化か!?と思ったけど、プールは半分以上空いてるしちょっと考えにくい。

あれこれ考えてるうちに、ZFSはキャッシュのヒット率が重要って事を思い出した。1フォルダに大量の細かなファイルがあるって事は、その分メタデータ処理が重いと考えられる。とすれば、メタデータを使いまくってそうなrsyncで速度が出ないってのも説明が付く………気がしなくもない。

zfs-statsを入れてキャッシュのヒット率を見てみたら、なんと2割を切ってるじゃないの。キャッシュに乗り切らなかったメタデータに毎度アクセスしに行くために、read operationsの割にbandwidthが上がらなかったのかしら…?

とりあえずarc関連のカーネル変数を調整したところ、いい感じでキャッシュヒットするようになった。問題のプール内のディレクトリ間でrsyncした時の結果が↓これ。

キャッシュヒット率が90%ほどに改善し、書き込みも12MB/s程出ている(zdata iostatは1秒毎、vfs.zfs.txg.timeout=5である)。

start.txt · 最終更新: 2016-05-07 17:46 by Decomo
CC Attribution-Noncommercial-Share Alike 3.0 Unported
www.chimeric.de Valid CSS Driven by DokuWiki do yourself a favour and use a real browser - get firefox!! Recent changes RSS feed Valid XHTML 1.0