Вопрос об объёме памяти обычно решают округлением вверх до ближайшего популярного числа. Такой подход работает, но плохо объясняет, почему одна система с шестнадцатью гигабайтами держится уверенно, а другая с тем же объёмом упирается в потолок. Разница определяется не самим числом, а тем, сколько данных приложения держат одновременно активными и что происходит, когда это количество превышает физический объём.
Что происходит при нехватке
Операционная система не сообщает приложению об исчерпании памяти сразу. Вместо этого она начинает вытеснять на накопитель страницы, к которым давно не обращались. Пока вытесняются действительно холодные данные, эффект незаметен. Проблема начинается, когда вытесненная страница снова требуется: процессор получает исключение отсутствия страницы, поток останавливается, страница читается с диска обратно, и только после этого выполнение продолжается.
Разница в порядках величин здесь решает всё. Обращение к оперативной памяти занимает десятки наносекунд, обращение к твердотельному накопителю — десятки микросекунд, к механическому диску — миллисекунды. Между памятью и SSD разница примерно в тысячу раз, между памятью и жёстким диском — в сотни тысяч. Когда система входит в режим постоянного вытеснения и подкачки, она тратит на ожидание диска больше времени, чем на вычисления. Внешне это выглядит как замирания интерфейса, рывки в игре при подгрузке локации, отклик на клик через несколько секунд. Загрузка процессора при этом низкая — он ждёт.
Ключевое свойство этого перехода — он резкий. Пока объёма хватает, добавление гигабайтов не даёт ничего; как только не хватает, нехватка одного гигабайта роняет отзывчивость несопоставимо сильнее, чем могла бы дать любая прибавка частоты. Поэтому объём и скорость находятся не на одной шкале: сначала закрывается объём, и только потом имеет смысл разговор о частоте и таймингах.
Как оценить потребность по характеру задач
Полезнее считать не по типу пользователя, а по классам нагрузки. Первый класс — фоновая среда: сама операционная система, драйверы, кэш файловой системы, мессенджеры, браузер с десятком вкладок. Это несколько гигабайт, и цифра растёт от версии к версии, потому что браузерные вкладки давно стали полноценными приложениями со своими процессами.
Второй класс — рабочее приложение с ограниченным набором данных: офисные документы, разработка средних проектов, лёгкая обработка фотографий. Здесь потребление предсказуемо и обычно укладывается в единицы гигабайт сверх фона.
Третий класс — приложения, чей аппетит определяется размером обрабатываемых данных, а не самим приложением. Работа с видео высокого разрешения, крупные растровые композиции со множеством слоёв, трёхмерные сцены, виртуальные машины, локальные базы данных, компиляция больших кодовых баз в много потоков. У этого класса потребность растёт линейно с размером задачи, и никакого универсального числа для него не существует: гигабайты считают от объёма материала.
Игры занимают промежуточное положение. Их потребление ограничено сверху тем, что разработчик закладывал в требования, но к этому добавляется фон, оверлеи и браузер, который редко закрывают.
Практическая методика проще любой таблицы: открыть диспетчер задач в момент типичной работы и посмотреть не на процент, а на два числа — сколько занято физически и каков объём зафиксированных обязательств. Если второе регулярно превышает первое с заметным запасом, система уже опирается на подкачку.
Когда объём перестаёт давать выигрыш
После того как весь рабочий набор помещается в память и подкачка прекратилась, свободные гигабайты не ускоряют ничего. Они не превращаются в производительность: система использует излишек под дисковый кэш, что помогает при повторном чтении одних и тех же файлов, но эффект несопоставим с переходом из режима подкачки в нормальный.
Именно на этом участке начинает работать скорость. Когда объёма достаточно, разница между медленным и быстрым комплектом проявляется в задачах, где процессор постоянно обращается к памяти за новыми данными: встроенная графика, обработка потоков, часть игровых сцен с большим числом объектов. Порядок выигрыша здесь — единицы и первые десятки процентов, а не кратный разрыв, который даёт устранение подкачки.
Есть и третий фактор, который часто перевешивает оба: конфигурация каналов. Один модуль вдвое большего объёма даёт тот же объём, что два вдвое меньших, но работает в одноканальном режиме и теряет половину пропускной способности. Поэтому при равном бюджете гигабайтов пара модулей почти всегда предпочтительнее одного. Характеристики модулей и их взаимодействие с платой разобраны в разделе про оперативную память.
Запас на будущее и его цена
Аргумент о запасе имеет смысл, но не безграничный. Ставить сразу вдвое больше нужного разумно, если плата имеет всего два слота и последующее расширение потребует полной замены комплекта. Если слотов четыре, можно занять два и оставить место — правда, с оговоркой, что через год докупить точно такие же модули будет сложно, а смешивание разных партий добавляет собственных проблем.
Отдельный сценарий — серверные и рабочие конфигурации, где объём определяется числом одновременно работающих виртуальных машин или размером набора данных в памяти. Там действуют другие ограничения: число слотов на сокет, поддержка модулей с коррекцией ошибок, допустимая нагрузка на канал. Особенности этой ветки собраны в разделе о памяти с коррекцией ошибок.
Сводя воедино: объём — это порог, а не шкала. Ниже порога система работает в разы медленнее возможного независимо от остальных характеристик; выше порога дополнительные гигабайты нейтральны, и дальнейший выигрыш ищут в числе каналов, частоте и задержках.
