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

キャッシュは、データを格納するコンポーネントであるため、そのデータに対する将来のリクエストに迅速に対応できます。キャッシュに格納されたデータは、以前の計算の結果、または他の場所に格納されたデータの複製である可能性があります。

1
スラブオブジェクトが自動的に回収されないのはなぜですか
更新:4.9。*ではこの問題は発生していません。*いつ修正されたかはわかりません。 完全なシステムバックアップの後、毎日、echo 2 > /proc/sys/vm/drop_caches再生可能なスラブオブジェクトを解放するまで、さまざまなプログラムが読み取りエラーで失敗しています。 たとえばsudo apt-get update、バックアップ後の出力は次のとおりです。 $ sudo apt-get update Hit http://ftp.ca.debian.org unstable InRelease Hit http://ftp.ca.debian.org experimental InRelease Ign http://dl.google.com stable InRelease Get:1 http://ftp.ca.debian.org unstable/contrib amd64 Packages/DiffIndex [7,819 B] Hit http://dl.google.com stable Release.gpg Hit http://ppa.launchpad.net wily InRelease Get:2 http://ftp.ca.debian.org unstable/non-free amd64 Packages/DiffIndex [6,577 B] Hit http://dl.google.com stable Release …


3
ページキャッシュに100%ページインされたファイルが別のプロセスによって変更されるとどうなりますか
ページキャッシュページが変更されると、ダーティとマークされ、ライトバックが必要になることがわかりますが、次の場合はどうなりますか。 シナリオ: 実行可能ファイルであるファイル/ apps / EXEは、ページキャッシュに完全にページインされ(そのページはすべてキャッシュ/メモリにあり)、プロセスPによって実行されています 連続リリースは、/ apps / EXEをまったく新しい実行可能ファイルに置き換えます。 前提1: プロセスP(および古い実行可能ファイルを参照するファイル記述子を持つ他の人)は、メモリ内の古い/ apps / EXEを問題なく使用し続け、そのパスを実行しようとする新しいプロセスが取得されると仮定します新しい実行可能ファイル。 仮定2: ファイルのすべてのページがメモリにマップされていない場合、ファイルのページを置き換えるページフォールトが発生するまで問題はなく、おそらくセグメンテーション違反が発生すると仮定しますか? 質問1: ファイルのすべてのページをvmtouchのようなものでロックすると、シナリオはまったく変わりませんか? 質問2: / apps / EXEがリモートNFS上にある場合、違いはありますか?(私は仮定しない) 2つの仮定を修正または検証し、2つの質問に答えてください。 これが、ある種の3.10.0-957.el7カーネルを備えたCentOS 7.6ボックスであると仮定しましょう。 更新:さらに考えてみると、このシナリオは他のダーティページシナリオと何の違いもないのではないかと思います。 新しいバイナリを書き込むプロセスは、すべてページングされているため、すべてのキャッシュページを読み取り、すべてのキャッシュページを取得し、それらのすべてのページがダーティとしてマークされると仮定します。ロックされている場合、参照カウントがゼロになった後、コアメモリを占有する無駄なページになります。 現在実行中のプログラムが終了すると、他のものはすべて新しいバイナリを使用すると思われます。それがすべて正しいと仮定すると、ファイルの一部のみがページインされる場合にのみ興味深いと思います。

1
コンテンツを優先してファイルのメタデータをキャッシュするようにLinuxを構成する方法は?
ファイルシステムメタデータのキャッシュにほとんどのRAMを使用するようにシステムを設定したいと思いますが、読み取り/書き込みキャッシュとファイルのプリフェッチに適度な量だけを使用します。理想的には、実際にファイルを開くまでディスクをスピンアップせずに(RAMに収まる限り)ファイルシステムを閲覧できるようにしたいと思います。 詳細は次のとおりです。 自家製のファイルサーバーがあります。約9TBのLVMボリュームに5つのディスクがありますが、RAMは4GBしかありません。サーバーはファイルを提供するために他のことをほとんど行わないため、RAMのほとんどはキャッシュに使用されます。(「無料」は、キャッシュに使用される3.9Gのうち3.4Gを報告します。) サーバーは私の寝室にあり、すべてのディスクが回転していると、静かなときに迷惑になるほどのノイズが発生します。(シークノイズではなく、単なる回転ノイズです。ディスクはさまざまなメーカーやモデルのものであり、回転速度のわずかな違いが干渉の原因になると思います。サブヘルツ周期のわずかなノイズ。)だから、私はほとんどの時間ディスクをスピンダウンするようにサーバーを設定しました。 もちろん、ファイルマネージャーでフォルダーを開いたときにディスクがスピンダウンした場合、そのフォルダーを持つディスクのいずれかがスピンアップするまでに遅延があります。それは大したことではありません。しかし、LVMが別のディスク上の各サブフォルダーのメタデータを拡散した場合、私が見ている場所によっては、連続して数回発生する可能性があります。 私は、Linuxのほとんどがキャッシュをファイルの内容で満たし、おそらくプリフェッチされたデータでいっぱいになっていると思います。キャッシュは、スムーズな再生を保証するために数MBを超えるとあまり役に立ちません。映画を見ただけなら、もうすぐまた見ないでしょう。私の場合、数MBを超えると、プリフェッチが発生してもまったく役に立ちません。 しかし、ほとんどのファイルシステムメタデータ、少なくとも既にアクセスした部分をキャッシュできるようにするには、4GBで十分だと思うでしょう。睡眠。 ファイルを開くときにまだ遅延がありますが、それでも問題ありません。「クリック; 待ちます。クリック; 待ちます。クリック; 待ちます。演奏する; 「クリック」で視聴します。クリック; クリック; 演奏する; 待ちます。見る"。前者は非常にイライラします。後者はほとんど期待されています。 ノート: 問題があれば、カーネルは3.2、OSはDebian、ボリュームはlvm2、FSはext4です。 スピンダウンの唯一の理由は、夜間の騒音です。それ以外の場合、サーバーは継続的に実行されます。(私はそれを妥当な低消費電力にしました。)スピンダウンの遅延は時刻によって異なります。 ハードディスクはメディア専用です。OSは、別の(小さな)フラッシュドライブ上にあります。(これは、スピンアップの遅延がデータに起因するものであることを意味します。何らかの理由で何かが必要だったというだけではありません/usr。どうにかして問題を解決できる場合は、数GBを節約できます。 パフォーマンスに対する合理的な影響は大したことではありません。とにかく、ディスクは私のネットワークよりも高速です。

2
Linuxがメモリキャッシュがいっぱいになったときにパージするのはなぜですか?
512 MBのRAMと1日あたり数千の訪問者に(ほとんど静的な)コンテンツを提供するnginx / php-fpm / mysqldを備えたCentOSを実行しているVPSのメモリグラフは次のようになります。 (これらはx軸上の日です) ご覧のとおり、キャッシュとバッファの領域では非常に急激です。メモリキャッシュは不規則な間隔で消去されます(責任のあるcronジョブを除外します)。常にではありませんが、通常は、それ以上大きくならない場所でパージされます。時にはほぼ完全にクリアになることもあれば、途中までしかクリアされないこともあります。 これらのパージの背後にあるロジックを理解しようとしています。メモリキャッシュがクリアされると、ファイルデータがはるかに長くキャッシュされ、通常よりも多くのメモリを使用する他のプログラムが表示されないことが予想されます。 これは通常の動作ですか、何か不足していますか? 更新:メモリのアップグレードによりグラフが安定したようです。まだ小さな低下が見られますが、アップグレード前ほど重要な場所はありません。
14 linux  memory  cache 

1
lshwとlscpuはキャッシュで一致しません-どちらが正しいですか?
キャッシュに関する詳細(特に、コア間で共有されているキャッシュと共有されていないキャッシュ)を見つけようとしており、不整合に陥っています。 sudo lshw 言う *-cache:0 description: L1 cache physical id: a slot: Internal Cache size: 64KiB capacity: 64KiB capabilities: synchronous internal write-back *-cache:1 description: L2 cache physical id: b slot: External Cache size: 8MiB capabilities: synchronous internal write-back しかし、lscpu主張 L1d cache: 32K L1i cache: 32K L2 cache: 256K L3 cache: …

3
LinuxにNFS共有上の1つのファイルのキャッシュを強制的にフラッシュさせるコマンドはありますか?
StackOverflowに関するこの質問に関連して、NFSキャッシュをフラッシュする方法や、LinuxにNFS共有上にあるファイルの最新のコピーを強制的に表示させる方法があるかどうか疑問に思っています。 4台のApacheサーバーがNFSを介して同じディレクトリをマウントし、1台のサーバーがファイルに変更を加えた場合、他のサーバーがその変更を確認するのに約5〜10秒かかります。このウィンドウ内でそのファイルに2番目の変更を加えると、最初の変更が上書きされる場合があります。 fstabファイルシステムのエントリは次のとおりです。 172.16.1.15:/home /media/home nfs vers=3,defaults,noauto,sync,acregmin=1 0 0 LinuxにNFS共有上の1つのファイルのキャッシュを強制的にフラッシュさせるコマンドはありますか?
14 nfs  cache 

1
バッテリーを搭載したラップトップでext4のバリアを無効化しても安全ですか?
マニュアルページにはbarrier、ext4 のオプションについて記載されています。 書き込みバリアは、ディスクへのジャーナルコミットの適切な順序付けを強制し、揮発性ディスク書き込みキャッシュを安全に使用できるようにしますが、パフォーマンスがいくらか低下します。ディスクが何らかの方法でバッテリバックアップされている場合、バリアを無効にするとパフォーマンスが安全に向上する場合があります。 バッテリー(およびSSD)を搭載したラップトップは、バッテリーバックアップディスクを搭載していると見なされますか?では、barrier=0ラップトップでext4を使用するのは安全ですか?

3
一時ファイル〜/ .cache / duplicity / tempのクリーンアップに失敗しました
Duplicityを実行すると、実行の最後に次のようなエラーメッセージが表示されることがよくあります。 Cleanup of temporary file /home/user/.cache/duplicity/9a169830d41477b2dbc3c5b32edd4e8a/duplicity-MEXhMY-tempdir/mktemp-StAkzj-1 failed 上記のディレクトリには、Duplicityを次に実行したときに削除されるファイルが10個ほど含まれています。 増分バックアップを実行しているときにこれが失敗することがある理由はありますか?私はそれに対するパターンを自分で見たことがなく、同じ問題に言及している他の人を見つけることができなかった。あるメーリングリストのある人は、彼のロケールがDuplicityに問題を引き起こしたと言ったことがあります。通常のノルウェー語ロケールからen-USに変更しようとしましたが、まだ問題が発生します。 これはDuplicityの単なる通常の操作ですか? 3つの異なるシステムで見る:2つのUbuntu 13.04 64ビットデスクトップと1つのUbuntu Server 13.04 64ビット。

2
RAMの30%は「バッファ」です。それは何ですか?
$ free -h total used free shared buff/cache available Mem: 501M 146M 19M 9.7M 335M 331M Swap: 1.0G 85M 938M $ free -w -h total used free shared buffers cache available Mem: 501M 146M 19M 9.7M 155M 180M 331M Swap: 1.0G 85M 938M の出力で「バッファ」を説明または説明するにはどうすればよいfreeですか? このシステムには(既知の)問題はありません。「バッファ」が「キャッシュ」とほぼ同じ高さであることを知って驚いただけです(155M対180M)。「キャッシュ」はファイルコンテンツのページキャッシュを表し、「キャッシュ/バッファ」の最も重要な部分になる傾向があると思いました。「バッファ」が何のためにあるのか、私にはよくわかりません。 たとえば、これをRAMの多いラップトップと比較しました。私のラップトップでは、「バッファ」の数値は「キャッシュ」よりも1桁小さい(200M対4G)。「バッファ」が何であるかを適切に理解していれば、小さなシステム上でバッファがなぜそれほど大きくなるのかを問い始めることができます。 man proc (私は陽気に古くなった「大」の定義を無視します): バッファ%lu …
12 linux  memory  cache 

1
「キャッシュされた」メモリは事実上無料ですか?
を実行cat /proc/meminfoすると、上部に次の3つの値が表示されます。 MemTotal: 6291456 kB MemFree: 4038976 kB Cached: 1477948 kB 私の知る限り、「キャッシュ」の値はLinuxシステムによって作成されたディスクキャッシュであり、アプリケーションがより多くのRAMを必要とするとすぐに解放されるため、MemFreeとCachedの両方がゼロになるまでLinuxがメモリ不足になることはありません。 残念ながら、 "MemAvailable"は/ proc / meminfoによって報告されません。これは、おそらく仮想サーバーで実行されているためです。(カーネルバージョンは4.4) したがって、すべての実用的な目的のために、アプリケーションで使用可能なRAMはMemFree + Cachedです。 その見方は正しいですか?
11 linux  memory  cache  meminfo 

2
プロセッサのL1およびL2キャッシュを無効にする方法は?
Ubuntu 14.04でL1キャッシュまたはL2キャッシュ(あるいはその両方)を無効にすることはできますか(できればPythonなどの高レベル言語で)。もしそうなら、どうですか? さらに、キャッシュを無効にすることは、アーキテクチャによって大きく異なりますか?もしそうなら、私はARM Cortex-A15にもっと興味があります。 編集 キャッシュを無効にする方法を調査しているときに、kernel.orgのドキュメントの / proc / sys / vm /にある「drop_caches」ファイルについて知りました 「これに書き込むと、カーネルはクリーンなキャッシュだけでなく、デントリやiノードなどの再利用可能なスラブオブジェクトも削除します。削除すると、メモリは解放されます。」 ... 「このファイルは、さまざまなカーネルキャッシュ(inode、dentries、pagecacheなど)の増大を制御する手段ではありません。これらのオブジェクトは、システムの他の場所でメモリが必要になったときに、カーネルによって自動的に再利用されます。」 これは私が探しているもののようには見えません。キャッシュを無効にするようには見えないだけでなく、仮想メモリはハードウェアではなくオペレーティングシステム内にあると考えました。私の目標は、キャッシュを無効にして、RAMなどの別の場所で目的のメモリを探す必要があることです。 編集 明確にするために、キャッシュを無効にするとシステムがどうなるかを理解しています。ただし、これは、安全性が重要なアプリケーションの信頼性を高めるために宇宙アプリケーションで使用される一般的な手法です。この現象を文書化したリソースを以下に示します。 キャッシュメモリを介して、組み込みソフトウェアの放射線による障害を低減 宇宙放射線環境におけるマイクロプロセッサの地上放射線試験のガイドライン トピックに関する本さえあります: エレクトロニクスにおける電離放射線効果:メモリからイメージャへ
10 linux  ubuntu  python  arm  cache 

1
dm-cacheによって何がキャッシュされているかを知る方法は?
私はかなり長い間、dm-cacheをうまく使用しています。次に、現在キャッシュにあるファイルを確認します。dm-cacheはファイルではなくブロックで機能することを理解していますが、上記のファイルシステムがあるため、理論的にはこれをキャッシュされているファイル(の一部)に変換できるはずです。 もちろん、私は実用的な解決策を気にします:現在dm-cacheにあるものをどのようにリストできますか?
10 linux  cache  ssd 


2
検索/ lsキャッシング
初めて実行したとき、findまたはlsディレクトリで実行したときのように、作業に時間がかかるようです。しかし、その後は毎回、ディレクトリのコンテンツのリストがどこかにキャッシュまたはインデックスされているかのように高速です。 コンピュータの再起動後もこのキャッシュを保持する方法はありますか?
10 find  ls  cache 

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.