Найти в Дзене
Цифровая Переплавка

💾 Почему swap “должен” быть в 2 раза больше RAM — и кто придумал эту догму

Если вы хоть раз ставили Linux или BSD в 90-е или начале 2000-х, вы точно видели это правило: swap = 2× RAM. Не обсуждается. Не объясняется. Просто “так надо”. А теперь выясняется, что это правило родом из 1980-х — времён SunOS и ранних BSD. И что оно было не законом физики, а скорее эмпирической эвристикой, которая со временем превратилась в IT-фольклор. История с “2× RAM” — это отличный пример того, как техническое ограничение эпохи магнитных дисков может пережить три десятилетия и дожить до SSD и 128 ГБ оперативки. Давайте разберёмся. На Stack Exchange обсуждают происхождение правила, и следы ведут в эпоху: 🖥 SunOS конца 80-х
🐚 ранних BSD (4.3BSD, 4.4BSD)
📜 документации FreeBSD 90-х В установочных мануалах SunOS 1989 года уже фигурирует рекомендация 2× RAM.
FreeBSD-инсталлятор требовал 2× RAM ещё в 1993 году. В статье МакКьюсика 1986 года о виртуальной памяти Berkeley UNIX говорится, что система была “настроена на режим, когда активная виртуальная память составляет 1.5–2× физичес
Оглавление

Если вы хоть раз ставили Linux или BSD в 90-е или начале 2000-х, вы точно видели это правило: swap = 2× RAM. Не обсуждается. Не объясняется. Просто “так надо”.

А теперь выясняется, что это правило родом из 1980-х — времён SunOS и ранних BSD. И что оно было не законом физики, а скорее эмпирической эвристикой, которая со временем превратилась в IT-фольклор.

История с “2× RAM” — это отличный пример того, как техническое ограничение эпохи магнитных дисков может пережить три десятилетия и дожить до SSD и 128 ГБ оперативки.

Давайте разберёмся.

Откуда вообще взялось это число

На Stack Exchange обсуждают происхождение правила, и следы ведут в эпоху:

🖥 SunOS конца 80-х
🐚 ранних BSD (4.3BSD, 4.4BSD)
📜 документации FreeBSD 90-х

В установочных мануалах SunOS 1989 года уже фигурирует рекомендация 2× RAM.
FreeBSD-инсталлятор требовал 2× RAM ещё в 1993 году.

В статье МакКьюсика 1986 года о виртуальной памяти Berkeley UNIX говорится, что система была “настроена на режим, когда активная виртуальная память составляет 1.5–2× физической”.

Вот вам и ключ: это была настройка алгоритмов VM, а не магическая константа.

Что происходило в тех системах

Чтобы понять 2×, нужно вспомнить, как работала виртуальная память в 80-е.

⚙️ не было overcommit в современном виде
⚙️ swap мог резервироваться заранее под анонимные страницы
⚙️ fork() дублировал адресное пространство процесса
⚙️ диски были HDD с огромным временем поиска (seek)

Представьте типичный сценарий:

👨‍💻 пользователь запускает процесс
🧬 процесс делает fork()
📦 система должна гарантировать, что есть место для потенциальной копии памяти

Если swap меньше RAM — вы рискуете просто не смочь корректно выполнить fork.

В эпоху без copy-on-write оптимизаций это было критично.

Почему именно 2×, а не 1.5× или 3×

Вот здесь начинается самое интересное.

Ответ, если убрать романтику, довольно приземлённый:

🧠 это была эмпирическая граница устойчивости
🧮 алгоритмы VM были “затюнены” под такую нагрузку
🧑‍🔧 это была простая рекомендация для администраторов
📢 “удвоить RAM” легко объяснить

1× выглядело рискованно.
1.5× — странно и “некрасиво”.
3× — уже перебор и трата диска.

2× — психологически удобное число. И достаточно безопасное.

Важный фактор: фрагментация swap

В эпоху HDD это было критично.

📀 swap размещался на вращающемся диске
⏳ случайные I/O были дорогими
📦 требовались относительно непрерывные блоки

Когда swap был недостаточного размера, он быстрее фрагментировался, и система начинала бесконечно перекачивать страницы памяти между RAM и диском, практически замирая в работе.

Большой swap:

📉 уменьшал риск того, что системе не хватит непрерывных (последовательных) участков диска для записи выгружаемых страниц памяти.
📈 увеличивал устойчивость при перегрузке

Это не про “заполнить swap”.
Это про “чтобы он не развалился, когда всё плохо”.

Но сегодня-то зачем 2×

Вот тут начинается самое забавное.

Современные системы:

🧠 имеют десятки гигабайт RAM
⚡ используют SSD
🔄 используют механизм copy-on-write — когда память при копировании процесса фактически не дублируется сразу, а копия создаётся только в момент изменения данных.
📦 используют продвинутую (гибкую и умную) политику overcommit — то есть более точно управляют тем, сколько виртуальной памяти можно выделить сверх объёма физической RAM.
🧮 используют сжатый swap (например, zswap или zram) — когда страницы памяти перед выгрузкой на диск сначала сжимаются, а иногда и вовсе хранятся в сжатом виде прямо в RAM, уменьшая нагрузку на накопитель.

На машине с 64 ГБ RAM рекомендация 128 ГБ swap выглядит абсурдно.

В большинстве реальных сценариев:

💡 swap почти не используется
💡 он служит “амортизатором”, а не рабочей областью
💡 2–8 ГБ swap часто достаточно

В контейнерных средах и вовсе swap может быть отключён.

Почему правило живёт до сих пор

Вот тут уже социология.

📚 старые мануалы переписывались десятилетиями
🧑‍🏫 админы передавали знания устно
📦 инсталляторы копировали старые рекомендации
🧘 правило давало “спокойствие”

Это типичная ситуация, когда правило продолжают повторять просто потому, что “так принято”, уже не вникая, зачем оно вообще появилось.

Не потому что правило было глупым.
А потому что контекст исчез, а цифра осталась.

Личное мнение

Я считаю, что история с 2× RAM — отличный урок инженерного мышления.

Любая рекомендация:

🧠 должна быть привязана к эпохе
⚙️ зависит от архитектуры ОС
📀 зависит от типа накопителя
📊 зависит от нагрузки

В 1989 году 2× было разумным стартовым значением.
В 2026 году — это почти всегда избыточно.

Сегодня подход должен быть другим:

📈 мониторинг реального использования
📊 анализ page-in/page-out
⚙️ настройка swappiness
🧠 понимание нагрузки (workload)

Swap — это не магическая страховка.
Это инструмент балансировки.

Ирония в том, что правило не было строгим

Никто в BSD не писал: “Всегда 2×, иначе смерть”.

Это была эвристика для “чтобы не было проблем у новичков”.

Но со временем эвристика стала догмой.

Именно так рождается IT-фольклор.

Вывод

Правило “swap = 2× RAM” не является физическим законом.
Это историческая настройка под алгоритмы виртуальной памяти 80-х годов.

Оно:

🖥 родилось в эпоху SunOS и BSD
📀 учитывало ограничения HDD
🧠 отражало поведение fork() и ранней VM
📚 стало мемом администраторов

Сегодня его стоит воспринимать как исторический артефакт, а не как обязательное требование.

И если у вас 32–64 ГБ RAM — возможно, вам вообще не нужен большой swap.

Инженерия — это не следование ритуалам.
Это понимание контекста.

Источники

🔗 Обсуждение на Stack Exchange:
https://retrocomputing.stackexchange.com/questions/32492/origin-of-the-rule-that-swap-size-should-be-2x-of-the-physical-memory

🔗 Статья с разбором:
https://telegra.ph/Pochemu-my-do-sih-por-verim-v-mif-o-2x-obyoma-RAM-dlya-fajla-podkachki-02-26