web-dev-qa-db-ja.com

Solaris ZFSボリューム：ワークロードがL2ARCに到達しない

RAIDコントローラーの背後に適度に高速なHDDを搭載したSolarisExpress 11マシンをセットアップし、デバイスを圧縮を有効にしたzpoolとしてセットアップし、ミラーログと2つのキャッシュデバイスを追加しました。データセットはESXで使用するためのFCターゲットとして公開されており、試してみるデータをいくつか入力しました。 L2ARCは部分的にいっぱいになりました（そして何らかの理由でもういっぱいになりませんでした）が、私はそれの使用をほとんど見ていません。 zpool iostat -vは、過去にキャッシュからあまり読み取られていないことを示しています。

tank           222G  1.96T    189     84   994K  1.95M
  c7t0d0s0     222G  1.96T    189     82   994K  1.91M
  mirror      49.5M  5.51G      0      2      0  33.2K
    c8t2d0p1      -      -      0      2      0  33.3K
    c8t3d0p1      -      -      0      2      0  33.3K
cache             -      -      -      -      -      -
  c11d0p2     23.5G  60.4G      2      1  33.7K   113K
  c10d0p2     23.4G  60.4G      2      1  34.2K   113K

L2ARC対応のarcstat.pl スクリプトは、現在のワークロードでL2ARCの100％のミスを示しています。

./arcstat.pl -f read,hits,miss,hit%,l2read,l2hits,l2miss,l2hit%,arcsz,l2size 5
read  hits  miss  hit%  l2read  l2hits  l2miss  l2hit%  arcsz  l2size
[...]
 243   107   136    44     136       0     136       0   886M     39G
 282   144   137    51     137       0     137       0   886M     39G
 454   239   214    52     214       0     214       0   889M     39G
[...]

最初に、L2ARCがすべてをストリーミング負荷として認識するように レコードサイズが大きすぎる の影響である可能性があると考えましたが、zpoolにはzfsボリュームしか含まれていません（私はそれらを「スパース」として作成しました） zfs create -V 500G -s <datasetname>）変更するレコードセットパラメータすらありません。

また、メタデータにレコードごとに200バイトのRAMを必要とするL2ARCに関する多くの概念を見つけましたが、これまでのところ、L2ARCがボリュームデータセット（512バイトの単一セクター）を持つ「レコード」と見なすものを見つけることができませんでした？ RAMメタデータの不足に悩まされていて、今のところ二度と読まれないがらくたでいっぱいになっているのではないでしょうか。

編集：インストール済みの2GBの上に8GBのRAMを追加するとうまくいきました-追加のRAMは幸いです32ビットインストールでも使用され、L2ARCは成長し、ヒットしています。

    time  read  hit%  l2hit%  arcsz  l2size
21:43:38   340    97      13   6.4G     95G
21:43:48   185    97      18   6.4G     95G
21:43:58   655    91       2   6.4G     95G
21:44:08   432    98      16   6.4G     95G
21:44:18   778    92       9   6.4G     95G
21:44:28   910    99      19   6.4G     95G
21:44:38  4.6K    99      18   6.4G     95G

おかげで ewwhite 。

solariszfssolaris-11zfs-l2arc
6
the-wabbit

システムにはもっとRAMが必要です。L2ARCへのポインタはRAM（ARC）に保持する必要があるので、約4GBまたは6GBのRAMは、利用可能な最大60GBのL2ARCをより有効に活用します。

これは、ZFSリストの最近のスレッドからのものです。

http://opensolaris.org/jive/thread.jspa?threadID=131296

L2ARC is "secondary" ARC. ZFS attempts to cache all reads in the ARC 
(Adaptive Read Cache) - should it find that it doesn't have enough space 
in the ARC (which is RAM-resident), it will evict some data over to the 
L2ARC (which in turn will simply dump the least-recently-used data when 
it runs out of space). Remember, however, every time something gets 
written to the L2ARC, a little bit of space is taken up in the ARC 
itself (a pointer to the L2ARC entry needs to be kept in ARC). So, it's 
not possible to have a giant L2ARC and tiny ARC. As a rule of thumb, I 
try not to have my L2ARC exceed my main RAM by more than 10-15x (with 
really bigMem machines, I'm a bit looser and allow 20-25x or so, but 
still...). So, if you are thinking of getting a 160GB SSD, it would be 
wise to go for at minimum 8GB of RAM. Once again, the amount of ARC 
space reserved for a L2ARC entry is fixed, and independent of the actual 
block size stored in L2ARC. The jist of this is that tiny files eat up 
a disproportionate amount of systems resources for their size (smaller 
size = larger % overhead vis-a-vis large files).
7
ewwhite