web-dev-qa-db-ja.com

Solaris 11にアップグレードしてから、RAMが30GBであるにもかかわらず、私のARCサイズは一貫して119MBを目標としています。何？どうして？

Solaris 11がリリースされる前に、Solaris 11ExpressでNAS/SANボックスを実行しました。ボックスは、D2700が接続されたHPX1600です。全部で、12x 1TB 7200 SATAディスク、12x 300GB 10k SASディスクは別々のzpoolにあります。合計RAMは30GBです。提供されるサービスはCIFS、NFS、iSCSIです。

すべてが順調で、次のようなZFSメモリ使用量グラフがありました。

約23GBのかなり健全なアークサイズ-キャッシュに使用可能なメモリを利用します。

しかし、それが出たとき、私はその後Solaris11にアップグレードしました。さて、私のグラフは次のようになります。

arc_summary.plの部分的な出力は次のとおりです。

System Memory:
     Physical RAM:  30701 MB
     Free Memory :  26719 MB
     LotsFree:      479 MB

ZFS Tunables (/etc/system):

ARC Size:
     Current Size:             915 MB (arcsize)
     Target Size (Adaptive):   119 MB (c)
     Min Size (Hard Limit):    64 MB (zfs_arc_min)
     Max Size (Hard Limit):    29677 MB (zfs_arc_max)

915MBで座っている間、それは119MBを目標としています。 30GBで遊ぶことができます。どうして？彼らは何かを変えましたか？

編集

明確にするために、arc_summary.plはBenRockwoodのものであり、上記の統計を生成する関連行は次のとおりです。

my $mru_size = ${Kstat}->{zfs}->{0}->{arcstats}->{p};
my $target_size = ${Kstat}->{zfs}->{0}->{arcstats}->{c};
my $arc_min_size = ${Kstat}->{zfs}->{0}->{arcstats}->{c_min};
my $arc_max_size = ${Kstat}->{zfs}->{0}->{arcstats}->{c_max};
my $arc_size = ${Kstat}->{zfs}->{0}->{arcstats}->{size};

Kstatエントリがあり、それらから奇妙な値を取得しています。

編集2

アークサイズをarc_summary.plで再測定しました-これらの数値をkstatで確認しました：

System Memory:
     Physical RAM:  30701 MB
     Free Memory :  26697 MB
     LotsFree:      479 MB

ZFS Tunables (/etc/system):

ARC Size:
     Current Size:             744 MB (arcsize)
     Target Size (Adaptive):   119 MB (c)
     Min Size (Hard Limit):    64 MB (zfs_arc_min)
     Max Size (Hard Limit):    29677 MB (zfs_arc_max)

私が驚いたのは、ターゲットサイズが119MBであるということです。グラフを見ると、Solaris 11がインストールされて以来、まったく同じ値（cactiによると124.91M、arc_summary.plによると119M-違いは1024/1000の丸めの問題だと思います）をターゲットにしています。カーネルがターゲットサイズを別のものにシフトするためにゼロの努力をしているように見えます。現在のサイズは、システム（大）のニーズがターゲットサイズと戦うにつれて変動しており、平衡状態は700〜1000MBのようです。

それで、質問はもう少し指摘されました-Solaris 11がARCターゲットサイズを119MBに設定するのが難しいのはなぜですか、そしてそれを変更するにはどうすればよいですか？何が起こるかを確認するために最小サイズを上げる必要がありますか？

kstat -n arcstatsの出力を http://Pastebin.com/WHPimhfg に貼り付けました

編集3

わかりました、今は奇妙です。私はflibflobがこれを修正するパッチがあったと述べたことを知っています。私はまだこのパッチを適用しておらず（まだ内部サポートの問題を整理しています）、他のソフトウェアアップデートも適用していません。

先週の木曜日、箱が墜落した。のように、すべてに完全に応答するのをやめました。再起動すると正常に戻りましたが、グラフは次のようになります。

問題は解決したようです。

これは今では適切なララランドのものです。私は文字通り何が起こっているのか分かりません。 :(

zfssolaris-11
9
growse

残念ながら、私はあなたの問題を解決することはできませんが、ここにいくつかの背景情報があります：

  • ARCのターゲットサイズは修正値ではないようです。 Solaris 11マシンでも同じ問題が発生し、再起動するたびに、ある時点でターゲットサイズが約100〜約500MBの値でロックされているように見えます。

  • http://mail.opensolaris.org/pipermail/zfs-discuss/2012-January/050655.html で説明されているように、少なくとも3人の他の人が同じ問題に直面しています。

  • 「MyOracleSupport」（ https://support.Oracle.com ）に関する未解決のバグレポート（7111576）もあります。サーバーが有効なサポート契約を結んでいる場合は、サービスリクエストを提出し、そのバグを参照する必要があります。現在のところ、バグ修正はまだ進行中のようです...

それ以外にできることはあまりありません。 zpool/zfsバージョンをまだアップグレードしていない場合は、古いSolaris 11 Expressブート環境でブートして、Oracleが問題を修正するSRUをリリースすることを最終的に決定するまで実行してみてください。

編集：パフォーマンス低下の問題については上記で説明したので、すべては何をしているかによって異なります。 Solaris 11 11/11にアップグレードして以来、Solaris 11NFS共有でひどい待ち時間が発生しています。ただし、お使いのシステムと比較すると、スピンドルが比較的少なく、期待どおりに機能するARCおよびL2ARCキャッシングに大きく依存しています（この問題により、L2ARCが適切なサイズに成長しないことにも注意してください）。これは確かに誤って解釈された統計の問題ではありません。

ARC/L2ARCにあまり依存していなくても、ddを使用して大きなファイル（通常はRAMに収まる）を複数回読み取ることで再現できる可能性があります。 ）。ファイルを最初に読み取るときは、同じファイルを連続して読み取るよりも実際に高速であることに気付くでしょう（ばかげたARCサイズと無数のキャッシュエビクションのため）。

編集：これで、この問題を解決するIDRパッチをOracleから受け取ることができました。システムがサポートされている場合は、CR 7111576のIDRパッチを要求する必要があります。このパッチは、SRU3を搭載したSolaris 1111/11に適用されます。

4
nlx-ck

彼らはkstatsを変更しました。

Oracle Solaris 11は、zfs：0：arcstatsから次の統計を削除しました。

  • evict_l2_cached
  • evict_l2_eligible
  • evict_l2_ineligible
  • evict_skip
  • hdr_size
  • l2_free_on_write
  • l2_size recycle_miss

そして、以下をzfs：0：arcstatsに追加しました。

  • buf_size
  • meta_limit
  • meta_max
  • meta_used

したがって、これは基本的にスクリプトの問題である可能性があります。

1
juwi