Сервер для Microsoft SQL Server выбирают по сложности запросов, объёму активно используемых данных и интенсивности записи. Для обычной корпоративной базы разумная отправная точка — один процессор с 8–16 производительными ядрами, 64–128 ГБ оперативной памяти и серверные SSD с избыточностью. При тяжёлой аналитике или постоянной записи требования будут выше. Перед покупкой оборудования определите, что ограничивает работу: вычисления, память, накопители или сами запросы, и учтите ограничения редакции SQL Server.
С чего начинать выбор сервера
Размер базы и число запросов
База на 1 ТБ может содержать многолетний архив, к которому обращаются несколько раз в месяц. Её повседневные операции затрагивают сравнительно небольшой объём данных. Другая база занимает 150 ГБ, но непрерывно принимает заказы, пересчитывает остатки и формирует отчёты. Второй системе может потребоваться более производительное оборудование.
Подключённые пользователи не равны одновременно выполняемым запросам. Для расчёта нужны:
- размер данных и индексов, скорость их роста;
- объём регулярно используемых данных — рабочий набор;
- число одновременно выполняемых запросов;
- соотношение чтения и записи;
- частота отчётов, массовых загрузок и обслуживания;
- допустимое время ответа и продолжительность восстановления после сбоя.
Как нагрузка влияет на процессор, память и диски
| Характер нагрузки | Процессор | Оперативная память | Накопители |
|---|---|---|---|
| Частые короткие операции: учётная система, CRM, интернет-магазин | Производительность ядра и достаточное число ядер для одновременных запросов | Кэш часто используемых данных и индексов | Низкие задержки случайного чтения и записи журнала |
| Тяжёлые отчёты и аналитика | Вычислительная мощность и полезный для запросов параллелизм | Память для сортировок, соединений и больших рабочих наборов | Пропускная способность чтения и скорость временной базы |
| Массовая загрузка и интенсивная запись | Обработка поступающих данных, индексов и сжатия | Буферы и память выполняемых операций | Устойчивая запись, низкая задержка журнала, достаточный ресурс SSD |
| Несколько баз или экземпляров SQL Server | Совокупная нагрузка и распределение вычислений | Сумма потребностей с учётом совпадающих пиков | Отсутствие чрезмерной конкуренции за общий массив |
Процессор: частота, ядра и лицензии
Когда важнее производительность одного ядра
Короткий запрос часто выполняется последовательно. Если он использует одно ядро, увеличение их количества с 16 до 32 не сократит его время вдвое. Здесь важны архитектура процессора, производительность на такт и частота, которую он удерживает под реальной нагрузкой.
Когда нужны дополнительные ядра
Больше ядер полезно, если сервер одновременно обслуживает много запросов или выполняет тяжёлые операции, допускающие распараллеливание. Но есть ограничения:
- не каждый запрос получает параллельный план;
- распределение работы между потоками требует ресурсов;
- избыточный параллелизм одного отчёта может мешать коротким операциям;
- дополнительные ядра не исправляют блокировки и медленные накопители.
Один процессор или два
Один CPU часто достаточен для умеренной нагрузки. Второй нужен для дополнительных вычислений, памяти и её расширения: часть слотов может работать только при заполнении второго сокета.
В многопроцессорных системах применяется NUMA: процессор быстрее обращается к своей области памяти, чем к памяти соседнего узла. Поэтому число ядер и общий объём памяти ещё не описывают всю производительность.
Почему стоимость ядер важна до покупки
При лицензировании физического сервера по ядрам учитывают установленные физические ядра, с минимумом четыре лицензируемых ядра на процессор. При прочих равных сервер с 24 ядрами требует втрое больше лицензируемых ядер, чем сервер с восемью. Стоимость лицензий может изменить экономику покупки сильнее, чем разница в цене оборудования.
Аппаратные потоки не следует путать с физическими ядрами. Для виртуальных машин действуют отдельные правила. В актуальном руководстве Microsoft по лицензированию SQL Server лицензирование отдельной виртуальной машины по ядрам связано с Software Assurance или подпиской и предусматривает минимум четыре лицензии на виртуальную среду.
Оперативная память: сколько действительно нужно
Почему SQL Server занимает много памяти
SQL Server хранит в памяти страницы данных и индексов, планы выполнения и промежуточные результаты. Повторное чтение из памяти обычно обходится значительно дешевле обращения к накопителю, при этом особенность архитектуры SQL в том, что он займёт абсолютно всю память, которая ему будет предоставлена.
Объём базы нельзя напрямую превращать в объём RAM. Для базы на 1 ТБ могут быть достаточны даже условные 32 ГБ, если основная работа затрагивает небольшой набор страниц, или кэш запросов не применим для последующих операций. Для базы на 100 ГБ может потребоваться больше 128 ГБ памяти памяти, если одновременно выполняются крупные сортировки и соединения.
Из чего складывается потребность
Расчёт включает несколько составляющих:
- Часто используемые данные и индексы.
- Память одновременно выполняемых запросов.
- Служебные структуры SQL Server.
- Операционную систему, защитное ПО и агенты резервного копирования.
- Другие экземпляры и приложения, если они размещены на сервере.
Ограничения редакции и версии
Ограничения Standard различаются:
- SQL Server 2022 Standard: меньшая величина из четырёх сокетов и 24 ядер; буферный пул до 128 ГБ на экземпляр.
- SQL Server 2025 Standard: меньшая величина из четырёх сокетов и 32 ядер; буферный пул до 256 ГБ на экземпляр.
Актуальные ограничения перечислены в документации Microsoft о редакциях SQL Server 2025. Буферный пул — область памяти для кэширования страниц; его лимит не равен пределу всей памяти сервера или полному потреблению процесса.
Лимит памяти и заполнение каналов
Параметр max server memory задаёт верхнюю границу памяти, управляемой соответствующими механизмами SQL Server. При этом не все выделения процесса входят в этот лимит. Отдавать ему всю физическую память опасно: системе тоже нужны ресурсы.
Microsoft в рекомендациях по настройке памяти SQL Server предлагает учитывать ОС, другие приложения и выделения вне управляемого лимита. Фиксированная формула вроде «всегда оставлять 8 ГБ» не подходит для любых комплектаций.
Для сервера нужна ECC-память с коррекцией ошибок. Модули устанавливают по схеме производителя, распределяя их по каналам. Один большой модуль и несколько модулей того же суммарного объёма могут дать разную пропускную способность. Скорость также зависит от процессора, типа модулей и числа модулей на канал.
SSD: задержки, ресурс и размещение файлов
Почему недостаточно скорости в МБ/с
Для накопителей важны три разных показателя:
- Пропускная способность: сколько данных передаётся за секунду; существенна для больших чтений и резервного копирования.
- IOPS: число операций ввода-вывода в секунду; важно для множества небольших обращений.
- Задержка: сколько длится отдельное обращение; особенно заметна при коротких транзакциях и записи журнала.
SATA, SAS и NVMe
Samsung PM1743 с двумя вариантами корпуса.
Источник изображения: news.samsung
Серверные SATA или SAS SSD могут быть достаточны для умеренной базы. NVMe стоит рассматривать при интенсивном вводе-выводе, тяжёлой аналитике и требованиях к низким задержкам.
Но интерфейс — только часть выбора. Важны модель накопителя, контроллер, подключение корзины и возможности платформы. SATA SSD с предсказуемой записью может оказаться рациональнее потребительского NVMe, скорость которого заметно падает после заполнения быстрого кэша.
Для рабочих SSD важны защита от потери питания и корректное подтверждение записи: данные не должны оставаться только в незащищенном кэше.
Важным моментом являются и показатели ресурса SSD - DWPD (Drive Writes Per Day) показывает допустимое число полных перезаписей накопителя в сутки на протяжении заявленного срока службы. Другой показатель, TBW (Total Bytes Written), описывает суммарный объём записи. Например, 1 DWPD для SSD на 1,92 ТБ означает соответствующий паспортный ресурс примерно 1,92 ТБ записи в сутки при условиях производителя. Реальную нагрузку на накопитель увеличивают журнал, индексы, временные данные и особенности массива. При этом для баз данных, используемых для аналитики (основные запросы - на чтение), можно использовать более дешёвые накопители, с меньшим ресурсом.
Данные, журнал транзакций и tempdb
У SQL Server есть три области с разным поведением:
- Файлы данных: таблицы и индексы, случайные обращения и большие чтения.
- Журнал транзакций: последовательная запись изменений, необходимая для восстановления и фиксации операций.
- tempdb: временная база для промежуточных результатов, временных объектов и других операций.
При умеренной нагрузке допустим общий массив. При интенсивной записи выделяют отдельный ресурс журналу, при тяжёлых отчетах — tempdb выносят на более производительный массив. Стоит учесть, что разные разделы на одном массиве продолжают конкурировать за физические накопители и не дадут особого прироста, и что RAID не заменяет отдельные резервные копии.
RAID и полезная ёмкость
RAID 1 является зеркальной парой, он замедляет процедуру записи, зато может ускорять операции чтения.. RAID 10 часто используют для смешанной нагрузки, когда нужны избыточность и запись без вычисления чётности. RAID 5/6 экономнее по емкости, но при записи и восстановлении требуют отдельной оценки производительности.
Четыре SSD по 1,92 ТБ в RAID 10 дают 3,84 ТБ номинальной полезной ёмкости. ОС покажет меньшее число при отображении в двоичных единицах. Часть пространства также потребуется для роста базы, обслуживания и свободного резерва.
Для RAID-контроллера важна защита кэша. С NVMe заранее определяют поддерживаемый способ избыточности: обычный SAS/SATA-контроллер не управляет такими накопителями автоматически.
Примеры конфигураций для SQL Server
Следующие комплектации — отправные точки для проектирования. Диапазоны размера базы описывают сценарий и не гарантируют производительность. Конкретные процессоры, модули и диски подбирают по совместимости выбранной платформы.
Небольшая корпоративная база
Варианты платформ: HPE ProLiant DL380 Gen10 для стойки или HPE ProLiant ML110 для размещения в башенном корпусе.
Условия: база ориентировочно 50–200 ГБ, ограниченный рабочий набор, короткие операции и умеренная запись. Тяжёлые отчёты выполняются редко.
Комплектация:
- один процессор с 8 производительными физическими ядрами;
- 64 ГБ ECC-памяти;
- два серверных SSD по 480–960 ГБ в RAID 1 для ОС;
- два серверных SSD по 1,92 ТБ в RAID 1 для данных, журнала и tempdb;
- отдельное хранилище резервных копий.
Корпоративная система со смешанной нагрузкой
HPE ProLiant DL380 Gen11.
Источник изображения: Сервер Молл
Вариант платформы: HPE ProLiant DL380 Gen11 в исполнении с достаточным числом отсеков для SSD.
Условия: база ориентировочно 200–800 ГБ, регулярные отчёты, заметный рабочий набор и одновременная запись.
Комплектация:
- один процессор с 16 производительными физическими ядрами;
- 128–192 ГБ ECC-памяти;
- зеркало из двух SSD для ОС;
- четыре серверных SSD по 1,92 ТБ в RAID 10 для данных;
- два SSD по 960 ГБ в RAID 1 для журнала при интенсивной записи;
- отдельная зеркальная пара для tempdb, если измерения подтверждают необходимость;
- сеть 10 Гбит/с, если этого требуют передача данных и резервное копирование.
Корпус 2U даёт больше пространства для дисковых корзин и расширения. Различия платформ разобраны в статье «HPE ProLiant DL380: сравнение поколений Gen9–Gen12».
Аналитика и большие рабочие наборы
Вариант однопроцессорной платформы: HPE ProLiant DL325 Gen11. Поддерживаемые исполнения перечислены в спецификации DL325 Gen11.
Условия: база ориентировочно 1–3 ТБ, большие чтения, сортировки, соединения и несколько тяжёлых отчётов одновременно.
Комплектация:
- один процессор с 24–32 физическими ядрами;
- 256–512 ГБ ECC-памяти;
- отдельное зеркало для ОС;
- четыре или восемь серверных NVMe по 3,84 ТБ с поддерживаемой схемой избыточности;
- отдельные ресурсы для журнала и tempdb при выявленной конкуренции;
- сеть 10–25 Гбит/с по требованиям обмена и резервного копирования.
База с жёсткими требованиями к доступности
Для такой системы нужны как минимум два узла, каждый из которых выдерживает всю основную нагрузку после отказа соседа. Отправной вариант на узел:
- 16–24 физических ядра;
- 128–256 ГБ памяти;
- отказоустойчивые SSD-массивы;
- сетевой ресурс для репликации и прикладного обмена;
- отдельные резервные копии.
Два узла не удваивают автоматически скорость основной базы. В синхронной схеме фиксация транзакции может зависеть от подтверждения второго узла, поэтому его диски и сеть также влияют на время ответа.
Редакция Standard поддерживает базовые группы доступности с ограничениями, включая одну базу и две реплики в группе. Для более сложной схемы оценивают уже версию Enterprise или другой механизм резервирования. Лицензирование пассивного узла зависит от условий лицензий и предоставленных прав; считать его безусловно бесплатным нельзя.
Что показывают замеры: память, диски или CPU
Какие показатели сопоставлять
Средняя загрузка сервера недостаточна. Нужны показатели в период, когда пользователи замечают задержки:
- длительность типовых операций и число выполненных операций в секунду;
- загрузка CPU и процессорное время дорогих запросов;
- физические чтения и ожидание памяти запросами;
- задержки файлов данных и журнала;
- нагрузка на tempdb и блокировки.
Microsoft в руководстве по диагностике ввода-вывода SQL Server приводит 10–15 мс как приблизительный ориентир для выявления проблем хранения. Это не целевая задержка современной SSD-системы и не универсальная граница приемлемого времени ответа.
Ожидания помогают выбрать направление анализа:
- PAGEIOLATCH_* — ожидание загрузки страниц с накопителя;
- WRITELOG — ожидание записи журнала;
- RESOURCE_SEMAPHORE — ожидание выделения памяти запросу;
- SOS_SCHEDULER_YIELD — сигнал для сопоставления с загрузкой CPU и работой запросов;
- PAGELATCH_* — конкуренция за доступ к страницам в памяти, которую нельзя автоматически лечить заменой дисков.
Опубликованный тест: ускорение хранилища
Microsoft опубликовала сравнение производительности SQL Server на Azure. В тесте использовали SQL Server 2017 Enterprise, виртуальную машину E64s_v3 с 64 виртуальными процессорами и 432 ГБ памяти. Нагрузка была основана на уменьшенном сценарии TPC-E с базой около 800 ГБ.
| Хранилище данных и журнала | Пиковая пропускная способность | Что важно для интерпретации |
|---|---|---|
| Два Premium SSD P30 для данных, один P20 для журнала | До 490 транзакций/с | Для данных включён кэш чтения; tempdb размещена на локальном SSD |
| Ultra Disk для данных и журнала | До 1489 транзакций/с | После ускорения хранения загрузка CPU достигла 92% |
В условиях этого теста пропускная способность выросла примерно в три раза без замены виртуальной машины. Ограничение сместилось в сторону вычислительных ресурсов. Это показывает, почему покупка дополнительных ядер до анализа дисков может не дать ожидаемого эффекта.
Тест опубликован в 2019 году и относится к конкретной облачной конфигурации. Он не обещает такого же ускорения при замене SATA на NVMe в локальном сервере и не является сравнением всех современных накопителей.
Когда полезнее добавить память
Память стоит увеличивать, когда регулярно используемые страницы вытесняются из кэша, растут физические чтения с диска или запросы ждут её выделения. После расширения ожидают уменьшения этих обращений и улучшения времени ответа на той же нагрузке.
Дополнительная память не исправит неверную оценку количества строк, из-за которой запрос получает недостаточный объём для сортировки. Здесь сначала анализируют план выполнения и статистику.
Когда полезнее ускорить диски
Накопители становятся приоритетом, если операции ждут чтения данных или записи журнала, а измерения подтверждают высокие задержки соответствующих файлов. Улучшать следует тот ресурс, который действительно занят: быстрый массив для данных не исправит медленный отдельный журнал.
Когда полезнее заменить процессор
Для отдельного запроса сопоставляют процессорное время и полную длительность. Если последовательный запрос выполняется 3 секунды и тратит почти 3 секунды CPU, он преимущественно занят вычислениями. Если из 10 секунд процессорное время занимает 0,5 секунды, основную задержку следует искать в ожиданиях.
Это поясняющие примеры, а не результаты испытаний конфигураций. У параллельного запроса суммарное время CPU может превышать длительность: несколько ядер работают одновременно.
Как сравнивать модернизации
На отдельном стенде воспроизводят один сценарий и поочерёдно изменяют доступную память, хранилище и вычислительную платформу. Сохраняют одинаковыми копию базы, число сессий, настройки SQL Server, параметры запросов и обслуживание.
После прогрева выполняют несколько повторений и сравнивают время ответа и пропускную способность. Кэш рабочей базы ради теста не очищают. При смене CPU вместе с памятью и платформой результат относится ко всей системе.
Физический сервер или виртуальная машина
Физический сервер удобен, когда нужны выделенные ресурсы, прямой контроль хранения и предсказуемая нагрузка. Виртуальная машина также может эффективно работать с SQL Server, если узел обеспечивает необходимый ресурс.
Для виртуальной системы существенны:
- конкуренция с соседними машинами за процессор;
- гарантированная доступность памяти;
- соответствие виртуальной NUMA физической топологии;
- задержки общего хранилища и ограничения его производительности;
- права на лицензирование и перенос машины.
Для компактного узла с умеренным локальным хранилищем можно рассматривать DL360. Разница между ним и более вместительным DL380 объясняется в статье «HPE ProLiant DL360: сравнение поколений и выбор».
Надежность и стоимость владения
Цена сервера — часть бюджета. В него входят лицензии SQL Server и ОС, SSD, резервное копирование, поддержка, электричество и возможный простой. Недорогая система с большим числом старых ядер может проиграть более новой платформе с меньшим числом производительных ядер после расчёта лицензий.
Для новой системы выбирайте ближайший по характеру нагрузки пример, затем подтверждайте его пилотом. Для действующей базы опирайтесь на измерения в пиковые периоды: память помогает при подтверждённом дефиците, накопители — при задержках хранения, процессор — при вычислительном ограничении. Такой подход позволяет направить бюджет в компонент, который улучшит нужные операции.
