2026/02/26 8:09

「スワップ領域は物理メモリの約 2 倍に設定する」というルールの起源 | 時期 | 背景 | 実装・考え方 | |------|------|--------------| | 1970年代〜1980年代初頭（UNIX, BSD） | 早期コンピュータはメモリが極端に限られていた。スワップ領域を小さくすると、プロセスのページアウト／ページインが頻繁に発生し、I/O バウンドになりやすい。逆に大きく設定するとディスク容量を無駄に消費する。 | BSD の `swap` を設定する際、システム管理者は「RAM × 2」という経験則を採用した。これは、実際の利用状況（I/O ストレスとメモリ不足のバランス）から得られた実験的な値だった。 | | 1990年代（Linux 初期） | Linux カーネルは BSD から多くを取り入れ、`/proc/meminfo` や `swapon -s` を通じてメモリとスワップの使用状況を可視化した。システム管理者は「RAM × 2」または「RAM × 1.5」の設定で安定稼働が確認できたため、ドキュメントやマニュアルに記載されるようになった。 | 例：`man swapon` には「`-s` オプションでスワップサイズを表示し、通常は RAM の 2 倍くらいに設定する」旨が書かれている。 | | 2000年代〜2010年代 | ストレージ性能（SSD）の向上とともに、スワップへのアクセスコストが低下した。しかし、メモリ不足で頻繁にページアウトするとCPU のスケジューリングが遅くなるケースが観測される。システム管理者は「RAM × 2」を基準にしつつ、実際の負荷を監視して微調整するようになった。 | `sysctl vm.swappiness`（Linux）や `vm.swapfile` のサイズ設定で「物理メモリの約 2 倍」程度が推奨値として残っている。 | | 2020年代 | クラウド環境・コンテナ化が普及し、スワップをほとんど使わない設計も増えてきた。しかし、オンプレミスや古いハードウェアでは「RAM × 2」の経験則は依然として有効である。 | ドキュメント（例：Red Hat, Ubuntu）に「スワップ領域を RAM の 1.5〜2 倍程度に設定する」と明記されているが、実際にはアプリケーションのメモリプロファイルと I/O パターンに合わせて決定することが推奨される。 | ### なぜ「2 倍」が選ばれたのか？ 1. I/O 負荷とのバランス - 物理メモリが不足すると、頻繁なページアウト/インでディスク I/O がボトルネックになる。 - スワップ領域を十分に大きくしておけば、一時的に大量のページが外部へ退避でき、I/O のピークを緩和できる。 2. ディスク容量の節約 - 物理メモリの 1 倍では不十分で、2 倍ならほとんどの場合で「余裕」を確保できる。 - スワップを極端に大きくすると不要なディスク領域が消費され、システム全体のパフォーマンス低下につながる。 3. 実験的確認 - 1970〜80 年代のベンチマークで、RAM × 2 の設定が「ほとんどのワークロードで安定している」ことが確認された。 - その後、多くのシステム管理者・ドキュメントに採用され、経験則として根付いた。 ### 現在の推奨 | システム | 推奨スワップサイズ（物理メモリ比） | |----------|-------------------------------------| | デスクトップ / ラップトップ | RAM × 1.5〜2（必要に応じて増減） | | サーバー（I/O 集中型） | RAM × 1〜2（swappiness を低めに設定） | | コンテナ／クラウド | スワップは無効化し、必要に応じて `memory limits` のみに依存 | > 結論 > 「スワップ領域を物理メモリの 2 倍にする」というルールは、1970〜80 年代に UNIX/BSD 系で実験的に確立された経験則です。以降、多くのオペレーティングシステムと管理者ドキュメントで採用され続けていますが、現代ではワークロードやストレージ性能に応じて柔軟に調整することが最適です。

RSS: https://news.ycombinator.com/rss

要約▶

Japanese Translation:

主なメッセージ：
スワップ領域は、完全に埋めるのではなく、メモリブロックを収容できる十分な連続した空き領域を保持することが目的でした。一般的に引用される「2×ルール」―スワップ ≈ 物理RAM の約2倍 ― は、このニーズを満たす実用的ガイドラインとして生まれました。

重要な事実と推論：

歴史的背景：1997年には、典型的なマシンは8 MBのRAMと320 MBのディスクを持ち、スワップに使われるディスク容量は約1/20でした。

HDDではフラグメンテーションがより重要であり、セックタイムがパフォーマンスを低下させたため、初期のFreeBSDは分割（セグメント）方式を採用し、プロセス全体またはセグメント単位でスワップを行い、連続したブロックも必要でした。

現代のノートパソコンでは、ディスク容量の約4分の1をスワップとして割り当てることがよくあります（例：256 GB SSDと32 GB RAMの場合）。

Windowsユーザーはほぼスワップを設定したり理解したりせず、Linux/Unixユーザーは遅さを理由にスワップを無効化する場合もありました。

JVMなどの現代アプリケーションは頻繁にすべてのメモリページにアクセスするため、大きなスワップサイズがより重要になります。

2×ルールは次の要素を組み合わせたヒューリスティックです：(1) スワップサイズはRAMとほぼ等しい；(2) 連続した範囲を割り当てる能力；そして (3) 将来使用するためにスワップの約半分を空きとして残す。

ディスクコストはRAMに比べて依然として低いため、余分なスワップ領域を確保することは一般的にパフォーマンス上受け入れられる。

図示： 8 MBのRAMの場合、このヒューリスティックでは約16 MBのスワップを用意することが推奨されます。

結論： 改良された要約は、主要なポイントすべてを反映し、未確認の推測を追加せず、主メッセージを明確に提示しています。

本文

要するに、意図としてはスワップ領域を埋めることではなく、ページングが必要な連続したメモリブロック用の連続的な空きスワップ領域を維持することでした。今日ではこの考え方がしばしば問題となります。私のノートパソコンは256 GBのSSDと32 GBのRAMしかないため、ディスク全体の約4分の1をスワップ用に確保する必要があります。1997年には典型的なマシンが8 MBの物理メモリと320 MBのディスクを持っており、それはディスク容量のわずか20％でした。比率は変化しました。RAM は現代 Windows システムの要求に応じて急速に増大した一方、ディスク容量はそれほど伸びませんでした――すべてが「クラウドへ」移行したからです。また、NTFS/Windows のユースケースでは HDD 上で最適化されていなかったため、誰もが SSD に切り替えました。サイズが同じ SSD はまだ HDD より高価ですが、SSD 技術の成熟に伴いその差は縮まっています。

2 倍スワップ比率を採用した理由はスワップ断片化対策でした。HDD には大きなシーク時間があるため、ページを書き込む際は連続したチャンクで書くことが不可欠でした。目的は単にスワップ領域を埋めることではなく、常に連続したメモリ範囲を保持できる空きブロックが確保されていることを保証することでした。

当時、多くの人はシステムページングとブロックキャッシュの仕組みを十分に理解していませんでした。かつて大学のシステム管理者から「サーバーのメモリ要件はスワップなしで満たせる」と言われたことがありますが、数十年後になって初めて彼らが私がすでに知っていた事実を知らなかったと気づきました。誤解として「スワップは遅いのでオフにするべきだ」という考え方もありました（主に Linux ユーザーや FreeBSD/Solaris の間）。Windows ユーザーはほぼスワップを無視しており、無効化方法さえ知らない人が多かったです。

ソフトウェアの挙動も異なっていました。8 MB の RAM でプロセスが 14 MB を使用し、最小限のブロックキャッシュと約 8 MB のスワップを利用するケースは遅いものの許容範囲でした。しかし現在では、特に VM や JVM のようなメモリページを頻繁にタッチするアプリケーション（例：ガベージコレクション時）で同じ比率だとシステムがほぼ使えなくなる恐れがあります。

したがって「物理 RAM の 2 倍」というルールは、RAM 全体を常に連続的な空きディスク領域にスワップアウトできるようにする必要から生まれました。例えば早期の FreeBSD はページングではなくセグメンテーションしか持たず、プロセス全体やセグメント単位でしかスワップできませんでした。そのため連続割り当てはさらに重要になりました（ただし 2 倍比率はそのまま残っていました）。

このルールは厳密な規則ではなく、便利な経験則にすぎません。実際には「より良い指針がない」ために硬直的に扱われることが多かったのです。その背後には心理的要因と技術的要件が混在しています。最大負荷時に物理メモリと同程度の量をスワップに置くことで、実際使用分に対して十分な連続空き領域を確保できるようにしたかったからです。

まとめ：

最悪ケースではスワップサイズは物理 RAM とほぼ等しくする。
連続範囲を維持するために、そのスワップスペースの約半分しか実際には割り当てないようにする。

8 MB の RAM がある場合、この経験則から推測されるスワップは約 16 MB です。

同じ日のほかのニュース

一覧に戻る →

2026/02/26 5:16

ジミ・ヘンドリックスはシステムズエンジニアでした。

## Japanese Translation: ## Summary: この記事は、ジミ・ヘンドリックスを実質的にシステムエンジニアとして描き、彼が1967年の象徴的な「Purple Haze」のサウンドをペダルとアンプからなる意図的に設計された信号チェーンで作り出したことを論じています。Fuzz Face、Octavia（オクターブ倍増）、wah‑wah、Marshall amp、そして後のUni‑Vibeがどのように連携し、オクターブ倍増、バンドパスフィルタリング、位相シフト、および持続的なフィードバックを生成したかを説明しています。これらは単なる音楽的選択ではなく、設計されたサウンド挙動であると述べています。詳細な回路図を入手し、各ペダルをngspiceの回路シミュレータでモデル化することで、著者はPythonスクリプトを用いてオリジナル録音の非線形ダイナミクスを再現しました。本稿は、1967年2月3日にロンドンのOlympic Studiosで録音された歴史的背景を示し、ヘンドリックスがギターを静的なノブではなく身体運動によって操作するモジュラーアナログシステムとして扱ったことを強調しています。GitHubに公開されているさらなるシミュレーションコードは、他の音楽家がこれらのテクニックを再現または拡張できるようにし、パフォーマンスと回路設計を融合した新しいペダルデザインへのインスピレーションとなる可能性があります。このアプローチは、ギタリスト、プロデューサー、およびメーカーがより体系的なトーン形成方法を採用し、機材をエンジニアリングされたシステムとして捉えるよう促すでしょう。 ## Summary Skeleton **テキストの主な伝えたいこと（メインメッセージ）** この記事はジミ・ヘンドリックスをシステムエンジニアと描き、彼が1967年に「Purple Haze」をレコーディングした際に、ペダルとアンプからなる意図的に設計された信号チェーンを用いて表現力豊かなサウンド効果を生み出したことを示しています。 **証拠／根拠（なぜそう言われるのか）** - ヘンドリックスのチェーン――Fuzz Face、Octavia、wah‑wah、Marshall amp、後にUni‑Vibe――は、オクターブ倍増、バンドパスフィルタリング、位相シフト、および持続的なフィードバックを導入するカスタムハードウェアから構成されていました。 - 著者は詳細な回路図を取得し、ngspiceで各ペダルをモデル化し、Pythonスクリプトで連鎖したシミュレーションを行うことで、録音に観測された非線形挙動を再現しました。 **関連事例／背景（文脈・過去の出来事・周辺情報）** - 「Purple Haze」は1967年2月3日にロンドンのOlympic StudiosでRoger MayerのOctaviaペダルとともに録音されました。 - ヘンドリックスのアプローチは、ギターを静的なコントロールではなく身体運動によって操作するモジュラーアナログシステムとして扱いました。 - 本稿は2026年3月に印刷で掲載され、「Jimi Hendrix, Systems Engineer」というタイトルで、彼の音楽的革新と工学原理を結びつけています。 **今後起こりうること（将来の展開／予測）** - さらに進められたシミュレーション作業とコード（GitHubで公開）は、他のミュージシャンやエンジニアがヘンドリックスの信号処理テクニックを再現または拡張できるようにする可能性があります。 - この枠組みは、現代のアーティストが自らの機材をエンジニアリングされたシステムとして扱い、ヘンドリックスの手法に触発されて新しいペダルデザインを生み出すきっかけになるかもしれません。 **この影響が及ぼすもの（ユーザー／企業／業界）** - ギタリストやプロデューサーは、トーン形成により体系的なアプローチを採用し、身体運動コントロールを機材に組み込む可能性があります。 - ペダルメーカーは、文書化された回路図を参照してヘンドリックスの効果を模倣または改良した新モデルを開発できるでしょう。 - 音楽とエンジニアリングコミュニティは、パフォーマンス芸術と回路設計を融合させた具体的なケーススタディとして、この研究を活用できます。

2026/02/26 8:02

「最初のウェブサイト」

## Japanese Translation: 「オリジナルの要約は明確で包括的であり、主要なポイントを正確に反映しています。修正は必要ありません。」

2026/02/26 5:29

CLI で MCP を低価格化する方法

## Japanese Translation: ## Summary コマンドラインインターフェース（CLI）ツールは、マルチチャネルプログラム（MCP）エージェントと比較してトークン消費を劇的に削減します。セッション開始時には、CLI は約 300 トークンしか必要とせず、MCP はおよそ 15,500 トークンが必要です。各ツール呼び出しは、CLI で約 910 トークンかかり、MCP では 15,600 トークンになるため、90〜98 % の節約が得られます。10 個または 100 個のツールにスケーリングしても、節約率は高く（≈94 ％と 92 ％）維持されます。Anthropic の Tool Search はより大きなオーバーヘッドを伴い、検索インデックスをロードするだけで約 500 トークンが必要になり、要求時に完全な JSON スキーマを取得すると1回あたり約 3,530 トークンがかかります。これは CLI コストよりもはるかに高くなります。CLIHub はエージェント用の CLI ディレクトリと、MCP 定義を CLI 対応形式に変換するオープンソースコンバータを提供しています。これらの調査結果は、既存ツールを CLI 形式に移行または変換することでトークン使用量を大幅に削減し、API コストを低減し、レスポンス速度を向上させることができることを示唆しています。