タグ付けされた質問 「disk-cache」

2.6.31-302 x86-64カーネルでUbuntuを実行します。全体的な問題は、「キャッシュ」カテゴリにメモリがあり、それが上昇し続け、アプリケーションで必要な場合でも解放または使用されないことです。 だからここに私が「無料」コマンドから得たものがあります。一見したところ、これは普通のことではありません。 # free total used free shared buffers cached Mem: 7358492 5750320 1608172 0 7848 1443820 -/+ buffers/cache: 4298652 3059840 Swap: 0 0 0 誰かが最初に言うことは、「心配しないで、Linuxはそのメモリを自動的に管理する」ということです。はい、メモリマネージャがどのように機能するかを知っています。問題は、それが正しいことをしていないということです。ここで「キャッシュされた」1.4 GBは予約済みで使用できないようです。 Linuxに関する私の知識から、3 GBは「無料」であることがわかります。しかし、システムの動作はそうではないと言っています。使用量のピーク時に1.6 GBの実際の空きメモリが使い果たされると、より多くのメモリが要求されると（および最初の列の「空き」が0に近づくと）、OOMキラーが呼び出され、プロセスが強制終了され、問題が発生し始めますにもかかわらずで「無料」 - / +バッファ/キャッシュ行はまだ持っている約1.4 GB「無料」。 主要なプロセスのoom_adjの値を調整して、システムをひざまずかせないようにしましたが、それでも重要なプロセスは強制終了され、そのポイントには到達したくありません。特に、理論的には、ディスクキャッシュを削除するだけであれば1.4GBが「無料」のままです。 ここで何が起こっているのか誰にも分かりますか？インターネットには、Linuxの「無料」コマンドに関する愚かな質問と「なぜ空きメモリがないのか」が殺到しており、そのためこの問題については何も見つかりません。 私の頭に浮かぶ最初のことは、スワップがオフになっていることです。それについて固執するシステム管理者がいます。それらがバックアップされている場合、私は説明を受け入れます。これは問題を引き起こす可能性がありますか？ 実行後は無料echo 3 > /proc/sys/vm/drop_cachesです： # free total used free shared buffers cached …

24 linux  memory  memory-usage  disk-cache 

ユーザーデータは、2つのかなり大きな（1 PBを超える）OpenStack Swiftストレージクラスターに保存されます。それらをクラスターAおよびクラスターBとします。 さらに、そのデータとやり取りする必要があるPoPがいくつかあります。これらのPoPのサーバーは事実上ディスクレスです。つまり、ユーザーデータがサーバーに保存されたりダウンロードされたりすることはありません。PoPは、一般的な世界の地域（北米、南アフリカ、中央ヨーロッパなど）にグループ化できます。 一部のPoPは、任意のクラスターのSwiftエンドポイントからかなり離れているため、望ましくない遅延が発生します。これをある程度緩和するために、各リージョンにキャッシングゲートウェイサーバーをセットアップします。これにより、最も近いクラスターへのr / w要求がキャッシュされます。 現在、PoPのいずれかのクライアントは、Swift Object Storageをブロックデバイス（多かれ少なかれ）としてマウントするFUSEモジュールである、永続的にマウントされた迅速な仮想ファイルシステムによってユーザーデータにアクセスします。ただし、そもそもsvfsは安定しているわけではなく、将来的にはクライアントはNFS経由でキャッシュサーバーにアクセスする必要があります。 これは、目的のアーキテクチャの1つのブランチの図です。 +------------------+ +------------------+ NFS +------------------+ | Cluster A | SVFS | Region 1 Cache +----------> R1 PoP a Client | | +----------------> | | | |Persistent Storage| |Ephemeral Storage+----+ |Generates R/W Load| +-----------------++ +------------------+ | +------------------+ | | | +------------------+ …

14 nfs  network-share  openstack  disk-cache 

私は最近、SATAドライブに関する書き込みキャッシュ、NCQ、ファームウェアバグ、バリアなどについて読んでいますが、停電の場合にデータを安全に保つための最適な設定は何かわかりません。 私が理解したことから、NCQを使用すると、ドライブは書き込みを並べ替えてパフォーマンスを最適化し、どのリクエストが物理的に書き込まれたかをカーネルに通知できます。 書き込みキャッシュは、データが物理ディスクに書き込まれるのを待たないため、ドライブがリクエストをはるかに高速に処理できるようにします。 ここでNCQと書き込みキャッシュがどのように混在するかわかりません... ファイルシステム、特にジャーナリングされたものは、特定のリクエストがいつ書き留められたかを確認する必要があります。また、ユーザー空間プロセスはfsync（）を使用して特定のファイルを強制的にフラッシュします。fsync（）の呼び出しは、ファイルシステムがデータがディスクに書き込まれたことを確認するまで戻りません。 SASドライブでのみ見た機能（FUA、Force Unit Access）があります。これは、ドライブを強制的にキャッシュをバイパスし、ディスクに直接書き込みます。他のすべてについては、書き込みバリアがあります。これは、ドライブでキャッシュフラッシュをトリガーできるカーネルによって提供されるメカニズムです。これにより、重要なデータだけでなく、すべてのキャッシュが強制的に書き込まれるため、たとえばfsync（）を使用すると、システム全体が悪用されます。 ファームウェアのバグがあるドライブ、またはデータが物理的に書き込まれた時期について意図的に存在するドライブがあります。 これを言って..ドライブ/ファイルシステムを設定する方法はいくつかあります：A）NCQおよび書き込みキャッシュを無効にするB）NCQのみを有効にするC）書き込みキャッシュのみを有効にするD）NCQと書き込みキャッシュの両方を有効にする バリアが有効になっていると思います。ところで、実際に有効になっているかどうかを確認する方法は？ 電力損失の場合、ディスクへのアクティブな書き込み中に、ファイルシステムジャーナルとデータの両方でオプションB（NCQ、キャッシュなし）が安全であると推測します。パフォーマンスが低下する場合があります。 バリアまたはFUAを使用する場合、オプションD（NCQ + cache）は、fsync（）を使用するファイルシステムジャーナルおよびアプリケーションにとって安全です。キャッシュで待機していたデータにとっては悪いことであり、それを検出（チェックサム）するのはファイルシステム次第であり、少なくともファイルシステムが（願わくば）不安定な状態になることはありません。パフォーマンスに関しては、より良いはずです。 しかし、私の質問は立っています...私は何かが欠けていますか？考慮すべき他の変数はありますか？これを確認できるツールがあり、ドライブが正常に動作することはありますか？

13 filesystems  storage  disk-cache