Текст опубликован в личном блоге и его автор не имеет отношения к администрации сайта
В последнее время блогосфера оверклокеров буквально пестрит апокалиптическими прогнозами о том, как файл подкачки «нещадно убивает» твердотельные накопители (SSD). Авторы пугают износом ячеек, потерей данных после двух месяцев простоя в шкафу и призывают либо скупать серверные объёмы оперативной памяти (ОЗУ), либо жёстко ограничивать виртуальную память, страдая от вылетов программ.
Но что делать, если у вас уже есть отличная игровая связка (например, Ryzen 7 5700X на плате B550), 32 ГБ оперативной памяти, базовый накопитель под систему и топовый PCIe 4.0-накопитель для тяжёлых задач? Типичный сценарий использования такого персонального компьютера: современные AAA-игры и локальный запуск искусственного интеллекта (ИИ) с компактными большими языковыми моделями (LLM) уровня 4B. При этом мониторинг показывает, что общее потребление ОЗУ в пике редко превышает 22 ГБ из 32 доступных.
Казалось бы, живи и радуйся. Но перфекционизм и бережливое отношение к железу не дают покоя. Позиция проста: мне не жалко ресурса самой операционной системы (ОС) — её переустановка в 2026 году занимает 10 минут. Мне не жалко пустующего объёма оперативной памяти. Но мне до слёз жалко ресурс SSD, который тратится на скрытые и абсолютно ненужные фоновые записи Windows. Давайте разберёмся, как заставить свободную оперативную память «гулять на все деньги» и превратить накопители в вечные читалки.
Сторонники теории «подкачка нужна всегда» правы лишь в одном: архитектура Windows действительно ленива. Даже если из 32 ГБ ОЗУ занято всего 14 ГБ, операционная система в скрытом фоновом режиме продолжает нагружать контроллеры SSD.
Происходит это в трёх сценариях:
Сброс пассивных служб. Windows постоянно выгружает «спящие» системные библиотеки и логи телеметрии из ОЗУ на диск, чтобы держать оперативную память пустой под гипотетические будущие задачи.
Commit Charge (резервирование виртуальной памяти). Тяжёлый софт, библиотеки CUDA от NVIDIA и скрипты Python при запуске локального ИИ запрашивают у ОС виртуальное адресное пространство «на всякий случай». Windows обязана зарезервировать под этот запрос гигабайты, дублируя их адреса в файле подкачки. Если подкачки нет вообще, софт может вылететь с ошибкой Out of Memory, даже если в системе свободно ещё 18 ГБ физической памяти.
Бесконечный кэш TEMP. Браузеры, лаунчеры игр и Discord ежесекундно переписывают мегабайты временных файлов.
Для обычного накопителя это не страшно. Но для бюджетного современного накопителя на горячем контроллере (например, InnoGrit IG5236) лишняя фоновая активность — это дополнительный нагрев. Хотя в простое и при умеренной нагрузке под хорошим радиатором его контроллер выдаёт отличные 54–59 °C, зачем нагружать его структуру тем, с чем обязана справляться ОЗУ?
Если игры и модели ИИ считываются с HP FX900 Pro на максимальной скорости PCIe 4.0 (а чтение ячейкам памяти никак не вредит), циклы перезаписи фонового мусора нужно полностью исключить.
Раз нам не жалко оперативную память, заберём у неё 8 ГБ под создание высокоскоростного RAM-диска — виртуального накопителя, расположенного прямо в чипах ОЗУ. Все данные на нём физически исчезают при выключении ПК, а скорость доступа измеряется десятками гигабайт в секунду при наносекундных задержках.
Шаг 1. Поднимаем RAM-диск
Используем бесплатную утилиту ImDisk Toolkit или OSFMount. Создаём виртуальный диск объёмом 8192 МБ и присваиваем ему букву R:. Теперь у нас есть сверхбыстрая «песочница», которая не имеет никакого отношения к физическим ячейкам флеш-памяти.
Шаг 2. Обманываем подсистему подкачки Windows
Полностью отключать файл подкачки, как советуют некоторые радикалы, нельзя — локальный ИИ и платформа CUDA начнут выдавать ошибки инициализации. Мы поступим умнее:
Заходим в свойства системы: sysdm.cpl → «Дополнительно» → «Быстродействие» → «Параметры» → «Дополнительно» → «Виртуальная память».
Полностью отключаем файл подкачки на системном и игровом дисках.
Выбираем созданный RAM-диск R:\ и жёстко задаём на нём фиксированный размер файла подкачки (например, 4096–6144 МБ).
Результат: Windows и Python-скрипты видят, что файл подкачки на месте, система работает стабильно, но физически вся виртуальная память вращается внутри ОЗУ. Нагрузка на контроллеры SSD в этот момент падает до абсолютного нуля.
Шаг 3. Эвакуация папок TEMP
Осталось перенаправить поток системного мусора. В том же окне свойств системы заходим в «Переменные среды» и меняем пути для переменных TEMP и TMP — как пользовательских, так и системных. Вместо стандартных адресов на диске C: прописываем путь R:\TEMP.
Посмотрим на получившуюся картину с точки зрения ресурса накопителей:
Игровой диск переведён в режим «элитарного архива». Данные на него записываются ровно один раз — при установке игры или скачивании весов новой нейросети. Во время работы идёт чистое чтение на скорости (например, 7400 МБ/с). Никаких фоновых перезаписей и лишнего нагрева контроллера InnoGrit. Память TLC в таком режиме становится практически вечной.
Системный диск спокойно хранит саму Windows, но полностью избавлен от циклической бомбардировки мелкими системными записями, логами и браузерным кэшем.
Оперативная память наконец-то занята делом. Вместо простоя свободные 18 ГБ ОЗУ работают буфером, защищая дорогостоящие накопители.
Беречь ресурс SSD путём покупки терабайтов ОЗУ «про запас» — сомнительная идея. Но если у вас уже есть 32 ГБ памяти, половина которой бесцельно пустует в ваших задачах, не использовать её для защиты накопителей — настоящее техническое преступление.
RAM-диск решает проблему скрытой записи раз и навсегда. Пусть Windows ломается, пусть кэш стирается при каждой перезагрузке — операционную систему не жалко. А вот сэкономленный ресурс флагманского SSD скажет вам спасибо долгими годами безотказной работы.