/dev/shm バッキングストアにRAMを使用する一時ファイルストレージファイルシステム、つまりtmpfsです。これは、IPC を容易にする共有メモリの実装として機能します。
ウィキペディアより:
<ブロック引用>最近の 2.6 Linux カーネル ビルドでは、RAM ディスクの形式で共有メモリとして /dev/shm を提供するようになりました。より具体的には、/etc/default/tmpfs で定義された制限でメモリに格納される、誰でも書き込み可能なディレクトリとして提供するようになりました。 /dev/shm のサポートは、カーネル構成ファイル内では完全にオプションです。 Fedora と Ubuntu の両方のディストリビューションにデフォルトで含まれており、Pulseaudio アプリケーションで最も広く使用されています。
/tmp Filesystem 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 つの側面があり、他の回答では強調が異なります:
<オール>さまざまな tmp ディレクトリの適切な使用
古代のファイルシステム階層標準と Systemd がこの問題について述べていることに基づいています。
- 疑わしい場合は、
/tmpを使用してください . /var/tmpを使用 再起動後も保持する必要があるデータ。/var/tmpを使用 RAM に簡単に収まらない大きなデータの場合 (/var/tmpと仮定) 空き容量が多い – 通常 公正な仮定）/dev/shmを使用shm_open()を呼び出す副作用としてのみ .対象読者は、際限なく上書きされる制限付きバッファです。したがって、これは、コンテンツが揮発性であり、それほど大きくない長期保存ファイル用です。/dev/shmは絶対に使用しないでください 一般的にnoexecマウントされているため、(あらゆる種類の) 実行可能ファイル用 .- それでも不明な場合は、ユーザーがオーバーライドできる方法を提供してください。驚きを最小限に抑えるために、
mktempのようにしますTMPDIRを尊重します 環境変数。
tmpfs の優れている点
tmpfs が本当に優れているところは、何よりも、回転するディスク上で非常に重大なパフォーマンスのバグを隠していることです。したがって、それを修正するオプションがある場合、これはもちろん tmpfs の不適切な使用です :
fsync tmpfs ではノーオペレーションです。この syscall は、ファイルに関連付けられたページ キャッシュをフラッシュするように OS に指示し、関連するストレージ デバイスの書き込みキャッシュをフラッシュするまでのすべての手順を実行します。その間、それを発行したプログラムがまったく進行するのをブロックします。これは非常に粗雑な書き込みバリアです。 .ストレージ プロトコルがトランザクションを念頭に置いて作成されていないという理由だけで、これは必要なツールです。キャッシングはそもそも、プログラムがストレージ デバイスへの書き込みが実際にどれほど遅いかを気にせずに、ファイルに対して数百万回の小さな書き込みを実行できるようにするために存在します。実際の書き込みはすべて非同期で、または fsync これは、書き込みパフォーマンスがプログラムによって直接感じられる唯一の場所です。
したがって、tmpfs (またはeatmydata) を使用して fsync を無効にする場合は、あなた (またはチェーン内の他の開発者) が何か間違ったことをしています。これは、ストレージ デバイスへのトランザクションが目的に対して不必要に細かく設定されていることを意味します。すべてのセーブポイントを極端に破壊してしまったので、パフォーマンスのためにいくつかのセーブポイントをスキップしても構わないと思っていることは明らかです。最善の妥協はめったにありません。また、SSD を使用することの最大の利点のいくつかがトランザクション パフォーマンスの領域にあるのは、ここにあります。回転するディスク (7200 rpm =7200 rpm =他にアクセスしていない場合は 120 Hz)。フラッシュ メモリ カードによって、この測定基準も大きく異なります (これはシーケンシャル パフォーマンスとのトレードオフであり、SD カード クラスの評価では後者のみを考慮しています)。非常に高速な SSD を使用する開発者は、ユーザーにこのユースケースを強制しないように注意してください!
ばかげた話を聞きたいですか？初めての fsync 教訓:私は、一連の Sqlite データベース (テストケースとして保持されている) を常に変化する現在の形式に定期的に「アップグレード」する仕事をしていました。 「アップグレード」フレームワークは、1 つのデータベースをアップグレードするために、多数のスクリプトを実行し、それぞれ少なくとも 1 つのトランザクションを作成します。もちろん、データベースを並行してアップグレードしました (強力な 8 コア CPU に恵まれたため、8 つを並行してアップグレードしました)。しかし、私が知ったように、並列化の高速化はまったくありませんでした (むしろ、わずかな ヒット ) プロセスが完全に IO バウンドだったためです。面白いことに、各データベースを /dev/shm にコピーするスクリプトでアップグレード フレームワークをラップします。 、そこでアップグレードし、ディスクにコピーして戻すと、100倍高速でした（それでも8つ並列で）。おまけに、PC は使えました データベースのアップグレード中も。
tmpfs が適切な場所
tmpfs の適切な使用法は、揮発性データの不必要な書き込みを避けることです。 書き戻しを効果的に無効にする 、設定 /proc/sys/vm/dirty_writeback_centisecs のように 通常のファイルシステムでは無限に。
これはパフォーマンスとはほとんど関係がなく、これに失敗しても、fsync を悪用するよりもはるかに小さな懸念事項です。ライトバック タイムアウトは、ページキャッシュ コンテンツの後にディスク コンテンツがどれだけ遅延して更新されるかを決定します。デフォルトの 5 秒は、コンピューターにとって長い時間です。 – アプリケーションはページキャッシュ内のファイルを必要なだけ頻繁に上書きできますが、ディスク上のコンテンツは 5 秒に 1 回程度しか更新されません。アプリケーションが fsync でそれを強制しない限り、つまり。この時間内に、アプリケーションが小さなファイルを何回出力できるかを考えてみてください。すべてのファイルを fsync することが、はるかに大きな問題になる理由がわかります。
tmpfs が役に立たないこと
- 読み取りのパフォーマンス。データがホットな場合 (tmpfs に保持することを検討した方がよい場合)、いずれにせよページキャッシュにヒットします。違いは、ページキャッシュにヒットしない場合です。その場合は、以下の「tmpfs sux の場所」に進んでください。
- 短命のファイル。これらは、ページキャッシュで一生を過ごすことができます (dirty として) ページ) 書き出される前に。
fsyncで強制しない限り もちろんです。
tmpfs sux の場所
冷やす データ。スワップからファイルを提供することは、通常のファイルシステムと同じくらい効率的であると考えたくなるかもしれませんが、そうでない理由がいくつかあります:
- 最も単純な理由:現在のストレージ デバイス (ハードディスクまたはフラッシュ ベース) が、適切なファイル システムによってきちんと整理されたかなりシーケンシャルなファイルを読み取ること以上に気に入っているものはありません。 4KiB ブロックでのスワッピングは、それを改善する可能性は低いです。
- 隠れたコスト:交換 . Tmpfs ページが汚れている — ファイルにバックアップされた clean とは対照的に、ページキャッシュから削除するには (スワップするために) どこかに書き込む必要があります すぐにドロップできるページ。これは、メモリを競合する他のすべてのものに対する追加の書き込みペナルティです。これらの tmpfs ページの使用とは別の時点で別の何かに影響を与えます。
よし、これが現実だ。
tmpfs と通常のファイルシステムはどちらも、ディスク上のメモリ キャッシュです。
ファイルシステムはディスクの特定の領域を使用するバッキングストアであるため、tmpfs はメモリとスワップスペースを使用します。どちらもファイルシステムのサイズに制限はありません。十分なスワップスペースがあります。
違いは、データがディスクに書き込まれるタイミングにあります。 tmpfs の場合、メモリがいっぱいになった場合、またはデータがすぐに使用される可能性が低い場合にのみ、データが書き込まれます。 OTOH のほとんどの通常の Linux ファイルシステムは、ディスク上に多かれ少なかれ一貫性のあるデータ セットを常に保持するように設計されているため、ユーザーがプラグを抜いてもすべてが失われることはありません。
個人的には、クラッシュしないオペレーティング システムと UPS システム (例:ラップトップのバッテリー) に慣れているので、ext2/3 ファイルシステムは 5 ～ 10 秒のチェックポイント間隔で偏執的すぎると思います。 ext4 ファイルシステムは 10 分間のチェックポイントでより優れていますが、ユーザー データは 2 番目のクラスとして扱われ、保護されません。 (ext3も同じですが、5秒のチェックポイントがあるので気が付きません)
この頻繁なチェックポイントは、/tmp であっても不要なデータが継続的にディスクに書き込まれていることを意味します。
その結果、(スワップファイルを作成する必要がある場合でも) /tmp に必要な大きさのスワップ領域を作成し、その領域を使用して必要なサイズの tmpfs を /tmp にマウントする必要があります。
/dev/shm は絶対に使用しないでください。
ただし、非常に小さな (おそらく mmap された) IPC ファイルに使用していて、それが存在し (標準ではない)、マシンに十分なメモリ + スワップが利用可能であることが確実である場合を除きます。