いつ/ dev / shm /を使用する必要があり、いつ/ tmp /を使用する必要がありますか？

いつ使用し/dev/shm/、いつ使用する必要があります/tmp/か？両方がUnicesに存在することに常に依存できますか？

/dev/shmは、バッキングストアにRAMを使用する一時ファイルストレージファイルシステム、つまりtmpfsです。IPCを促進する共有メモリ実装として機能できます。

ウィキペディアから：

最近の2.6 Linuxカーネルビルドは、/ dev / shmをramdisk形式の共有メモリ、より具体的には/ etc / default / tmpfsに定義された制限付きでメモリに保存される書き込み可能なディレクトリとして提供し始めました。  / dev / shmサポートは、カーネル構成ファイル内では完全にオプションです。  これは、FedoraおよびUbuntuディストリビューションの両方にデフォルトで含まれており、Pulseaudioアプリケーションで最も広く使用されています。             ^{（エンファシスが追加されました。）}

/tmpFilesystem Hierarchy Standardで定義されている一時ファイルの場所です。これには、ほぼすべてのUnixおよびLinuxディストリビューションが続きます。

RAMは、ディスク・ストレージよりも大幅に高速であるので、あなたができる使用/dev/shmの代わりに/tmpパフォーマンス向上のために、あなたのプロセスがI / O集約的であり、広範囲に一時ファイルを使用している場合、。

あなたの質問に答えるには：いいえ、あなたは常に/dev/shmメモリに縛られたマシンにではなく、存在することに常に頼ることはできません。を使用/tmpする非常に正当な理由がない限り、使用する必要があります/dev/shm。

これは、個別のマウントではなくファイルシステムの/tmp一部になる可能性がある/ため、必要に応じて拡大できることに注意してください。のサイズは/dev/shmシステム上の過剰なRAMによって制限されるため、このファイルシステムのスペースが不足する可能性が高くなります。

可能性のtmpfs高い順に：

┌───────────┬──────────────┬────────────────┐
│ /dev/shm  │ always tmpfs │ Linux specific │
├───────────┼──────────────┼────────────────┤
│ /tmp      │ can be tmpfs │ FHS 1.0        │
├───────────┼──────────────┼────────────────┤
│ /var/tmp  │ never tmpfs  │ FHS 1.0        │
└───────────┴──────────────┴────────────────┘

Linux固有のtmpfsマウントポイントとtmpfsである可能性のある定義済みディレクトリ（システム管理者およびディストリビューションのデフォルトによって異なります）について質問しているため、質問には2つの側面があります。

1. 良い習慣に基づいて、これらのディレクトリを使用する場合
2. tmpfsを使用するのが適切な場合

良い習慣

保守版（FHSの規則と一般的な使用法の混合）：

• 疑わしい場合は、を使用します/tmp。
• /var/tmpRAMに簡単に収まらないような大きなデータに使用します。
• 使用する/var/tmp（キャッシュのような）再起動しても維持することが有益であるデータのために。
• を/dev/shm呼び出すことの副作用として使用しshm_open()ます。対象読者は、無限に上書きされる境界付きバッファです。そのため、これは、コンテンツが揮発性であり、それほど大きくない長寿命ファイル用です。
• まだ疑問がある場合は、ユーザーがオーバーライドする方法を提供してください。たとえば、mktempプログラムはTMPDIR環境変数を尊重します。

実用的なエディション：

使用し/dev/shm、tmpfsのを使用することが重要であるとき/var/tmp、それはない、他に重要であるとき/tmp。

tmpfsが優れているところ

fsynctmpfsではノーオペレーションです。tmpfs（またはeatmydata）を使用していることに気付いた場合でも、このシステムコールは（IO）パフォーマンスの第一の敵です（そして、気にするならフラッシュの寿命も））fsyncを無効にするために、あなた（またはチェーン内の他の開発者）が何か間違ったことをしています。これは、ストレージデバイスへのトランザクションが目的に合わせて不必要にきめ細かく処理されることを意味します。パフォーマンスを維持するためにいくつかのセーブポイントをスキップしてもかまいません。また、SSDを持つことの最大の利点のいくつかは、トランザクションパフォーマンスの領域にあります。まともなSSDは、スピニングディスクが取り得るものと比較して、この世界の外で実行します（7200 rpm = 120 Hz 、他の通知がアクセスしている場合）、フラッシュメモリカードは言うまでもなく、このメトリックで大きく異なります（特に、SDカードクラスの評価などで評価されるシーケンシャルパフォーマンスとのトレードオフであるため）。気をつけて、

ばかげた話を聞きたいですか？私の最初のfsyncレッスン：一連のSqliteデータベース（テストケースとして保存されている）を常に変化する現在の形式に定期的に「アップグレード」するという仕事がありました。「アップグレード」フレームワークは、1つのデータベースをアップグレードするために、少なくとも1つのトランザクションを作成する一連のスクリプトを実行します。もちろん、データベースを並行してアップグレードしました（強力な8コアCPUに恵まれたため、並行して8つ）。しかし、私が知ったように、プロセスは完全にIOバウンドであったため、並列化のスピードアップはまったくありませんでした（ややヒット）。陽気に、各データベースをコピーし/dev/shm、そこにアップグレードし、ディスクにコピーして戻すスクリプトでアップグレードフレームワークをラップすることは、100倍の速さでした（8が並行して）。おまけとして、PCは使えました データベースのアップグレード中にも。

tmpfsが適切な場合

tmpfsの適切な使用法は、揮発性データの不必要な書き込みを回避することです。通常のファイルシステムで無限に設定するなど、ライトバックを効果的に無効にし/proc/sys/vm/dirty_writeback_centisecsます。

これはパフォーマンスとはほとんど関係がなく、これに失敗してもfsyncを悪用するよりもはるかに小さな懸念です。ライトバックタイムアウトは、ページキャッシュコンテンツの後にディスクコンテンツがどれだけ遅延して更新されるかを決定します。 –アプリケーションはページキャッシュでファイルを必要な頻度で上書きできますが、ディスク上のコンテンツは約5秒に1回しか更新されません。アプリケーションがfsyncを使用して強制しない限り、そうです。この時間にアプリケーションが小さなファイルを何回出力できるかを考えてみてください。すべてのファイルをfsyncすることがはるかに大きな問題になる理由がわかります。

tmpfsがあなたを助けることができないもの

• 読み取りパフォーマンス。データがホットな場合（tmpfsに保存することを検討した方が良いでしょう）、とにかくページキャッシュにヒットします。違いは、ページキャッシュにヒットしない場合です。その場合は、以下の「Where tmpfs sux」に進んでください。
• 短いファイル。これらは、書き出される前に、ページキャッシュ内で（ダーティページとして）すべての寿命を過ごすことができます。fsyncもちろん強制しない限り。

tmpfs suxの場所

コールドデータを保持します。スワップからファイルを提供することは通常のファイルシステムと同じくらい効率的であると思われるかもしれませんが、そうでない理由はいくつかあります。

• 最も単純な理由：現代のストレージデバイス（ハードディスクまたはフラッシュベース）は、適切なファイルシステムによってきちんと整理されたかなりシーケンシャルなファイルを読むこと以上に愛するものはありません。4KiBブロックのスワッピングが改善されることはほとんどありません。
• 隠れたコスト：スワップアウト。Tmpfsページはダーティです - すぐにドロップできるファイルバックアップされたクリーンページとは対照的に、ページキャッシュから削除するには、スワップするためにどこかに書き込む必要があります。これは、メモリを奪い合う他のすべてに対する追加の書き込みペナルティです。これらのtmpfsページの使用とは異なる時間に何かに影響します。

さて、ここに現実があります。

tmpfsと通常のファイルシステムはどちらもディスク上のメモリキャッシュです。

tmpfsはバッキングストアとしてメモリとスワップスペースを使用します。ファイルシステムはディスクの特定の領域を使用します。どちらもファイルシステムのサイズに制限はありません。十分なスワップ領域があります。

違いは、データがディスクに書き込まれるタイミングです。tmpfsの場合、データが書き込まれるのは、メモリがいっぱいになりすぎた場合、またはデータがすぐに使用される可能性が低い場合のみです。OTOHのほとんどの通常のLinuxファイルシステムは、ディスク上にほぼ一定のデータセットを常に保持するように設計されているため、ユーザーがプラグを抜いてもすべてが失われることはありません。

個人的には、クラッシュしないオペレーティングシステムとUPSシステム（ラップトップバッテリーなど）を使用することに慣れているため、ext2 / 3ファイルシステムは5〜10秒のチェックポイント間隔では妄想的すぎると思います。ext4ファイルシステムは、ユーザーデータを2番目のクラスとして扱い、それを保護しないことを除いて、10分のチェックポイントで優れています。（ext3は同じですが、5秒のチェックポイントのため気付かないでしょう）

この頻繁なチェックポイント設定は、/ tmpであっても、不要なデータがディスクに継続的に書き込まれることを意味します。

そのため、/ tmpに必要な大きさのスワップスペースを作成し（スワップファイルを作成する必要がある場合でも）、そのスペースを使用して必要なサイズのtmpfsを/ tmpにマウントする必要があります。

/ dev / shmを使用しないでください。

ただし、非常に小さな（おそらくmmapされた）IPCファイルに使用していて、それが存在し（標準ではない）、マシンに十分なメモリ+スワップ以上の空きがあることが確実な場合を除きます。

一時ファイルには/ tmp /を使用します。共有メモリ（つまり、ファイルを介したプロセス間通信）が必要な場合は、/ dev / shm /を使用します。

/ tmp /が存在することを信頼できますが、/ dev / shm /は比較的最近のLinux専用のものです。

/ dev / shm（Linux 2.6以降の場合）を使用するもう1つのタイミングは、ディスクに書き込むことができるかどうかわからないため、保証されたtmpfsファイルシステムが必要な場合です。

私がよく知っている監視システムは、中央サーバーに送信するためのレポートを作成するときに一時ファイルを書き出す必要があります。実際には、何かがファイルシステムへの書き込みを妨げる可能性がはるかに高くなります（ディスク領域が不足するか、基盤となるRAIDの障害によりシステムがハードウェア読み取り専用モードになります）。 tmpfsが使用できなくなる（そしてボックスが死なない）ように、何かが利用可能なすべてのメモリをスパイラルする場合よりも、それについてです。このような場合、監視システムはRAMに書き込むことを好むため、ディスクが一杯になったか、ハードウェアが死んでいるか、死にかけているというアラートを送信できる可能性があります。

/ dev / shmは、共有仮想メモリシステム固有のデバイスドライバーとプログラムに使用されます。

仮想メモリにマップされる仮想メモリヒープを必要とするプログラムを作成する場合。これは2倍になるため、複数のプロセスまたはスレッドがそのメモリに安全にアクセスできるようにする必要がある場合。

実際には、ドライバーが特別なバージョンのtmpfsを使用しているからといって、それを汎用tmpfsパーティションとして使用する必要があるわけではありません。代わりに、一時ディレクトリ用に別のtmpfsパーティションを作成する必要があります。

すべてのマシン（すべてLinux Mintを実行）で最小8GBのPERLでは、/ dev /を使用して数百万の読み取りおよび書き込みを行うDB_Fileベース（ファイル内のデータ構造）の複雑なアルゴリズムを実行するのが良い習慣だと思いますシム

他の言語では、どこにでも一緒にいるわけではなく、ネットワーク転送の開始と停止を回避するために（クライアントサーバー環境のサーバーにあるファイルでローカルに作業します）、あるタイプのバッチファイルを使用して、ファイル全体（300〜900MB）を一度に/ dev / shmに出力し、/ dev / shmに出力してプログラムを実行し、結果をサーバーに書き戻し、/ dev / shmから削除します。

当然、RAMが少なければ、これはしません。通常、/ dev / shmのメモリ内ファイルシステムは、使用可能なRAMの半分のサイズとして読み取ります。ただし、RAMの通常の使用は一定です。そのため、2GB以下のデバイスでは実際にこれを実行できませんでした。言い換えれば、RAMには、システムでさえもうまく報告されないことがしばしばあります。