Сколько оперативной памяти нужно серверу: расчёт под 1С, виртуализацию и файловый сервер

«Возьмите с запасом» — самый дорогой совет в серверной закупке: он одинаково часто приводит и к переплате вдвое, и к нехватке через год. Разбираем методику расчёта под три типа нагрузки, объясняем, зачем нужна коррекция ошибок, и собираем чек-лист совместимости.

Память — единственный серверный ресурс, нехватка которого не замедляет систему постепенно, а обрушивает её резко. Пока объёма хватает, всё работает быстро. Когда перестаёт хватать, система начинает вытеснять данные на диск, и производительность падает не на проценты, а в разы — при том, что процессор при этом простаивает.

Отсюда и распространённый подход «возьмём побольше». Он работает, но стоит денег: серверная память заметно дороже обычной, и переплата вдвое на этой позиции — обычное дело. При этом простой расчёт занимает полчаса и даёт понятный ответ.

Ниже — методика для трёх типовых нагрузок, разбор того, что означают буквы в названии модулей, и список ограничений, из-за которых купленная память может просто не заработать.

Когда оперативной памяти не хватает, операционная система начинает выгружать то, что считает менее нужным, на диск. Формально система продолжает работать. Фактически обращения к данным замедляются на порядки, потому что диск в этой роли несопоставимо медленнее памяти даже в случае быстрых накопителей.

Практически это выглядит так: у пользователей всё «тормозит», администратор смотрит на загрузку процессора и видит спокойные цифры, потому что процессор действительно ждёт. Начинается поиск проблемы не там, где она есть, и нередко заканчивается покупкой более мощных процессоров, которая ничего не меняет.

Вторая сторона той же медали — переплата. Память покупается «на вырост» в объёме, который не будет использован за весь срок службы сервера, а через четыре года выясняется, что модули этого поколения уже никуда не переставить.

Разумный ориентир: считать под текущую нагрузку с коэффициентом на рост, и обязательно проверить, останутся ли свободные слоты под расширение. Второе часто важнее первого.

Любой расчёт строится слоями снизу вверх, и слои эти складываются.

Гипервизор или операционная система сервера. Базовый слой, который нужен просто чтобы машина работала. Он невелик, но не нулевой, и его регулярно забывают.

Службы инфраструктуры. Контроллер домена, файловые службы, служба резервного копирования, антивирусная консоль. Каждая — небольшой, но постоянный объём.

Прикладная нагрузка. Сервер баз данных, сервер приложений, терминальные сессии. Основная часть потребления.

Кэш и запас. Часть памяти система использует под кэширование, и это не расточительство, а то, за счёт чего всё работает быстро. Оставлять систему без свободной памяти нельзя.

Отсюда общее правило: считать нужно сумму слоёв, а не одно приложение, и закладывать свободный остаток. Сервер, у которого память занята на 95 %, — это сервер, который завтра начнёт вытеснять данные на диск.

Учётная система обычно состоит из двух частей — сервера приложений и сервера баз данных, — и они потребляют память по-разному.

Сервер баз данных использует память под кэш данных, и чем больше объём базы, тем больше он способен держать в памяти. Ориентир для расчёта: отталкиваться от размера рабочей части базы. Если база небольшая, разумно дать памяти столько, чтобы она помещалась целиком с запасом — тогда обращения к диску станут редкими. Для крупной базы это невозможно, и тогда считают по доле активных данных.

Сервер приложений потребляет по числу одновременно работающих пользователей и по характеру их работы. Оператор, который проводит документы, и экономист, который строит тяжёлые отчёты, различаются по потреблению в разы. Поэтому считают не по списочной численности, а по числу одновременных сеансов с разделением на профили.

Порядок действий: посчитайте размер рабочей базы, определите число одновременных сеансов, разделите пользователей на обычных и тяжёлых, сложите обе части, добавьте слой инфраструктуры и оставьте свободный запас. Отдельно проверьте пиковые периоды — закрытие месяца создаёт нагрузку, которой нет в обычный день, и считать нужно по пику.

Здесь логика другая: память распределяется между виртуальными машинами, и главный вопрос — сколько отдать каждой.

Базовая формула — сумма памяти всех машин плюс накладные расходы гипервизора плюс резерв. Но есть два уточнения, которые сильно влияют на результат.

Не раздавайте память по максимуму. Типовая ошибка — выделить каждой виртуальной машине «с запасом», потому что так спокойнее. В сумме это даёт двукратную переплату. Выделяйте по расчёту и наблюдайте за фактическим потреблением первые недели.

Оставьте место под отказ узла. Если виртуальные машины должны переехать на соседний сервер при аварии, у соседнего должен быть свободный объём под них. Это означает, что оба сервера в обычном режиме загружены не полностью — и это не потеря, а плата за отказоустойчивость.

Практический ориентир: закладывайте свободными не менее четверти общего объёма. Меньше — и любое непредвиденное событие, от всплеска нагрузки до временной второй копии базы, превращается в аварию.

Самый скромный по требованиям сценарий, и именно поэтому его часто переоценивают.

Файловой службе память нужна в основном под кэширование часто запрашиваемых файлов и метаданных. Объём хранилища при этом почти не важен: сервер с большим массивом и редкими обращениями требует немного. Ориентироваться нужно на число одновременных подключений и на то, насколько активно идёт работа с одними и теми же файлами.

То же касается контроллера домена, сервера печати, службы резервного копирования: каждая из них требует немного, но в сумме они дают ощутимый слой, который нужно посчитать.

Практическое замечание: если все эти службы живут на одном сервере вместе с 1С, считать нужно сумму, а не максимум. Это очевидно, но именно здесь возникает большинство ошибок при апгрейде существующего сервера.

Серверная память отличается от обычной не скоростью, а надёжностью и способностью работать в больших объёмах. Три параметра, которые нужно понимать при закупке.

ECC — коррекция ошибок. В любой памяти изредка происходят единичные сбои: бит меняет значение. В обычной памяти это приводит к непредсказуемым последствиям — от ошибки в расчёте до аварийной остановки. Память с ECC обнаруживает такие сбои и исправляет одиночные на лету.

Вопрос «нужна ли ECC» упирается в цену ошибки. Для домашнего компьютера сбой раз в несколько месяцев незаметен. Для сервера, который считает деньги и обслуживает всю компанию, тихое искажение данных — это худший вид отказа: он не виден и не воспроизводится. Поэтому в сервер ставится память с коррекцией ошибок, и обсуждать здесь особо нечего.

Registered (буферизованная). Такая память содержит промежуточный буфер, который снижает нагрузку на контроллер и позволяет ставить больше модулей на канал. Именно она позволяет набирать большие объёмы. Обычная небуферизованная память с ECC существует, но ограничена по суммарному объёму — её ставят в младшие платформы.

Ранги. Модуль может быть одноранговым или двухранговым. Это влияет и на производительность, и на то, сколько модулей поддержит платформа: у многих серверов ограничение задано не числом слотов, а суммарным числом рангов на канал.

Практический вывод для закупки: тип памяти определяется не вашим желанием, а платформой. Сервер поддерживает конкретный тип, и модуль другого типа в нём просто не запустится.

Самый частый сценарий неудачной закупки — модули куплены правильного объёма, но сервер с ними не стартует или работает медленнее ожидаемого.

Тип не тот. Буферизованная память в платформу, рассчитанную на небуферизованную, или наоборот. Не заработает.

Превышено число рангов на канал. Модули по отдельности поддерживаются, но в такой комбинации — нет. Проверяется по документации платформы, а не по здравому смыслу.

Нарушена схема заполнения слотов. У серверных платформ есть предписанный порядок установки модулей по каналам. При неправильном заполнении система стартует, но часть каналов работает не в полную силу, и производительность падает.

Смешаны разные модули. Память разного объёма, разных рангов или разной частоты в одном сервере: система обычно работает по худшему из параметров, а иногда не работает вовсе.

Не учтено ограничение процессора. Максимальный объём памяти задаётся не только платформой, но и установленным процессором. При одном процессоре в двухпроцессорной платформе часть слотов физически не обслуживается.

Отсюда правило: подбирать память нужно по списку совместимости конкретной платформы, а при апгрейде — по тем модулям, что уже стоят. Разделы серверной памяти и серверных платформ удобно смотреть вместе.

И практическое правило напоследок: свободные слоты ценнее лишних гигабайт. Память можно добавить через год, когда станет понятна реальная нагрузка, — но только если слоты остались. Полностью забитая платформа лишает вас этой возможности и превращает расширение в замену всех модулей сразу.

Если нужно подобрать память под конкретный сервер, передайте менеджерам e2e4 модель платформы и процессора: проверим совместимость по типу и рангам, подберём комплект с учётом схемы заполнения слотов. Каталог серверной памяти, серверов и серверных платформ — на сайте.