Калькулятор размера сервера: CPU, RAM, хранилище и пропускная способность
Полезный калькулятор определения размера сервера преобразует данные о рабочей нагрузке в диапазон конфигурации. Он не выбирает оборудование только по количеству посетителей. Поведение приложения, параллелизм, эффективность кэша, доступ к базе данных, размер объекта и продолжительность пиковой нагрузки определяют, появится ли первое узкое место в CPU, RAM, хранилище или сети.
Этот метод предназначен для команд, занимающихся оценкой веб-сайтов, баз данных, игровых серверов, потоковых сервисов, узлов хранения и вывода ИИ. Он создает надежную отправную точку для проверки концепции и нагрузочного теста, а не обещает, что одна фиксированная конфигурация подойдет для каждого выпуска.
Используйте калькулятор определения размера сервера в качестве рабочего процесса планирования: определите рабочую нагрузку, соберите нормальный и пиковый базовый уровень, определите первый ограничивающий ресурс, составьте список двух жизнеспособных проектов и протестируйте их с производственными данными. Сохраняйте предположения видимыми, чтобы будущий обзор мог обновить модель без повторного открытия.
Коммерческие варианты, упомянутые в этом руководстве: каталог выделенных серверов (https://unihost.com/dedicated/); Серверы AMD EPYC (https://unihost.com/dedicated/epyc/); Серверы GPU (https://unihost.com/dedicated/gpu/)
Связанное чтение Unihost: планирование пропускной способности сервера (https://unihost.com/blog/server-bandwidth-guide-high-load-projects/); Выбор уровня RAID (https://unihost.com/blog/raid-made-simple-choose-level/); NVMe производительность сервера (https://unihost.com/blog/what-is-nvme-ssd-server/)
Калькулятор определения размера сервера: начните с рабочей нагрузки, а не оборудования
Опишите рабочую нагрузку, прежде чем выбирать модель CPU или уровень RAM. Веб-сайту необходима частота запросов, размер ответа и коэффициент попадания в кеш; базе данных необходим размер рабочего набора, задержка запроса и сочетание операций чтения и записи; Для вывода ИИ необходим формат модели, длина контекста, размер пакета и параллелизм. Стриминговые, игровые и сервисы хранения данных используют разные пути. Прежде чем сравнивать цены на оборудование, запишите требования к выделенному серверу в качестве измеримых критериев приемки.
Собирайте запросы или задания в секунду, одновременные сеансы, задержку p95 и p99, частоту ошибок, коэффициент попадания в кэш, размер набора данных, объем передачи и пиковую продолжительность во время обычного трафика и во время типичного пика. Совместите временные метки инфраструктуры с трассировками приложений, чтобы команда могла связать медленный запрос или неудачное задание с ресурсом, который был ограничен. Средние значения полезны для планирования затрат, но p95, p99 и рост очереди показывают, наносят ли уже короткие всплески вреда службе.
Создайте один базовый уровень для нормального трафика и один для наиболее загруженного вероятного интервала, а затем сопоставьте его с пиком, который должен пережить бизнес. Основной риск планирования заключается в использовании широкого ярлыка, такого как высокий трафик, при этом игнорируется, является ли реальным ограничением блокировка базы данных, сериализованный код, задержка хранилища или исходящая передача. Подтвердите свой выбор, воспроизведя репрезентативные запросы с производственными данными, состоянием кэша и задержкой зависимостей. Сохраните условия тестирования и порог приемлемости в модуле Runbook, чтобы последующие изменения можно было проверить по тому же базовому состоянию.
Возможности также должны охватывать техническое обслуживание и поведение при отказах. Зарезервируйте достаточно места для мониторинга, ротации журналов, сканирования безопасности, резервного копирования и временной потери узла, когда архитектура обещает непрерывность. Этот резерв не является фиксированным процентом: извлеките его из сценария отказа и явно отобразите на рабочем листе.
Размер CPU: ядра, тактовая частота и параллелизм задач
CPU ядра для серверных рабочих нагрузок имеют значение только тогда, когда программное обеспечение может их использовать. PHP-работники, контейнеры, независимые запросы API, задания сборки и многие этапы аналитики могут выполняться параллельно. Сериализованный игровой цикл, один загруженный поток базы данных или сценарии, чувствительные к задержке, могут выиграть больше от более высокой производительности каждого ядра, чем от большего количества ядер.
Создайте базовый показатель на основе использования каждого ядра, длины очереди выполнения, средней нагрузки, CPU времени для каждого процесса, переключения контекста, регулирования, времени кражи на виртуальных машинах и p95 задержки запроса. Записывайте одни и те же сигналы до и после каждой настройки или изменения инфраструктуры. Если пропускная способность возрастает, а задержка и ошибки остаются под контролем, это изменение создает полезную емкость. Если очереди растут или задержка увеличивается, значит, система достигла предела, даже если один из основных показателей использования все еще выглядит удовлетворительным.
Выберите высокопроизводительный CPU сервер с большим количеством ядер для устойчивой параллельной работы и отдайте предпочтение более сильному одноядерному поведению, когда один или несколько горячих потоков контролируют время отклика. Следите за подсчетом логических потоков в качестве гарантированной пропускной способности приложения или допускайте, что низкое среднее значение означает отсутствие коротких окон насыщения. Перед заказом или миграцией используйте проверку параллелизма, которая постепенно увеличивает количество рабочих и записывает пропускную способность, хвостовую задержку и рост очереди на каждом этапе. Документированный критерий отклонения так же важен, как и критерий успеха, поскольку он сообщает команде, когда следует остановить развертывание или перейти на следующий уровень мощности.
Полезное решение имеет масштабный путь. Укажите, что можно расширить на месте, что требует перезапуска или миграции и какой порог запускает эту работу. Время выполнения закупок, продолжительность копирования данных и окна изменений относятся к планированию мощности, поскольку ресурс, который может быть добавлен в следующем месяце, может не помочь во время пика на следующей неделе.
Сколько RAM нужно моему серверу? Выбор размера в зависимости от рабочей нагрузки и параллелизма
RAM должен хранить операционную систему, активные процессы приложений, кэши, буферы базы данных и временную работу без рутинной замены. Ответ на вопрос, сколько RAM требуется моему серверу, зависит от рабочего набора и параллелизма, а не от общего размера каждого файла, хранящегося на диске. Базам данных и службам в памяти обычно требуется больше места, чем статическим веб-узлам.
Используйте резидентную память по процессам, использование страничного кэша, занятость буфера базы данных, активность подкачки, основные ошибки страниц, события нехватки памяти и рост памяти во время пиковой нагрузки в качестве модели небольшой емкости, а не в виде снимка информационной панели. Разделите устойчивый спрос, плановую работу и исключительные пики. Модель должна объяснять, какой ресурс насыщается первым, как долго длится это насыщение и какой клиентский или операционный результат меняется в этот момент.
Начните с измеренного пикового рабочего набора плюс пространство для OS, задач обслуживания и трафика вышедшего из строя узла, а затем округлите его до практического уровня мощности. Проект по-прежнему может потерпеть неудачу, если рассматривать свободную память как ненужную или скрывать утечку памяти за сервером с большим объемом памяти вместо исправления модели роста. Докажите предполагаемое поведение с помощью длительного пикового теста, включающего прогрев кэша, запланированные задания, резервное копирование и максимальное запланированное количество рабочих процессов. Включите в тест мониторинг, резервное копирование и средства контроля безопасности, поскольку производственные издержки не должны появляться в первый раз после запуска.
Стоимость должна быть привязана к единице успешной работы, такой как заказ, запрос, завершенное задание, восстановленный терабайт или принятый ответ модели. Такое представление не позволяет дешевой конфигурации выиграть, когда она не достигает целевого показателя задержки или восстановления, а также не позволяет рассматривать неиспользованный запас мощности как бесплатный.
RAM таблица размеров по рабочей нагрузке и параллелизму
| Рабочая нагрузка | Начало планирования | Увеличение, когда | Перед заказом измерьте |
|---|---|---|---|
| Маленькая сеть или узел API | 16-32 ГБ | Больше рабочих, более тяжелые фреймворки или локальное кэширование | RSS на каждого работника, пиковый параллелизм, коэффициент попадания в кэш |
| Загруженное веб-приложение или приложение электронной коммерции | 32-128 ГБ | Большие пулы процессов, поиск, сеансы или пики кампаний | Пиковый рабочий набор, события OOM, задержка оформления заказа |
| Транзакционная база данных | 64-256 ГБ | Количество горячих наборов данных или подключений растет | Коэффициент попадания в буфер, активный набор, временные операции |
| Аналитика или обработка в памяти | 128 ГБ и выше | Задания сканируют или объединяют более крупные активные наборы данных | Пиковая память заданий, объем утечки, параллелизм |
| Хост вывода AI | 64-512 ГБ и выше | Модели, CPU разгрузка или предварительная обработка растут | Файлы моделей, разгрузка RAM, количество пакетов и рабочих |
Просмотр подходящих выделенных серверов
Определение размера хранилища: емкость, IOPS, RAID и затраты на резервное копирование.
При выборе размера хранилища возникают два независимых вопроса: какой объем полезной емкости требуется и как быстро должны обслуживаться данные. Выбор серверов NVMe и SSD должен соответствовать задержке и измерениям IOPS, в то время как HDD или хранилище, ориентированное на емкость, по-прежнему может подходить для архивов и последовательного резервного копирования. RAID изменяет полезную емкость и поведение при сбоях, но не заменяет резервную копию.
Измеряйте используемую и растущую емкость, чтение/запись IOPS, пропускную способность, глубину очереди, задержку хранения p95, усиление записи, временное пространство базы данных и перестройку нагрузки с достаточным разрешением для захвата всплесков и достаточной продолжительностью для выявления утечек, эффектов кэша и фоновых заданий. Держите структуру рабочей нагрузки видимой. Тест, в котором преобладают простые запросы, может показать хорошие средние значения, в то время как дорогостоящий путь уже стоит в очереди.
Зарезервируйте пространство для роста, снимков, журналов, временных файлов и выбранного макета RAID перед расчетом полезной емкости, а затем разместите «горячие» и «холодные» данные на соответствующих уровнях. Не игнорируйте покупку достаточного количества терабайт, но отсутствие требований к произвольному вводу-выводу или учет зеркальных дисков и дисков с четностью как полностью используемую емкость. Подтвердите рекомендацию с помощью теста хранилища с реальными размерами блоков приложения и сочетанием операций чтения и записи, а затем, если это возможно, повторите попытку восстановления массива с ухудшенными характеристиками или восстановлением. Запишите, какое предположение имеет наименьшую достоверность, и сначала повторно проверьте это предположение при изменении трафика, данных или программного обеспечения.
Калькулятор пропускной способности сервера с примерами ежемесячных переводов
Калькулятор пропускной способности сервера должен отделять скорость порта от ежемесячной передачи. Передача оценивает общее количество байтов за расчетный период; Скорость порта определяет, как быстро пакет может покинуть сервер. Начните с запросов, умноженных на среднее число байтов ответа, добавьте репликацию, резервное копирование и административный трафик, затем примените пиковый коэффициент, полученный в результате мониторинга.
Создайте повторяемый набор доказательств на основе среднего и пикового исходящего трафика в Мбит/с, использования 95-го процентиля, ежемесячных байтов, размера ответа, кэша или разгрузки CDN, отбрасывания пакетов и пропускной способности окна резервного копирования. Сохраняйте входные данные о рабочей нагрузке рядом с результатами, включая версию программного обеспечения, размер данных, состояние кэша и параллельный доступ. Это превратит следующий обзор емкости в сравнение, а не в еще одну оценку по памяти.
Выберите порт, который обеспечивает измеренный пиковый уровень, с оперативным запасом и резервом на пересылку, охватывающим месяц, не полагаясь на нереалистичный фиксированный средний показатель. Самой дорогостоящей ошибкой было бы разделить ежемесячные байты на каждую секунду месяца и считать это небольшое среднее значение требуемой скоростью порта. Уменьшите эту неопределенность с помощью воспроизведения трафика в часы пик, а также синхронизированной резервной копии или передачи репликации, пока пользовательский трафик остается активным. Сохраняйте путь обновления или отката, который не зависит от уже ограниченного компонента.
Примеры ежемесячных трансферов для планирования
| Сценарий | Формула планирования | Иллюстративный ежемесячный перевод | Решение порта |
|---|---|---|---|
| Веб-страницы | просмотры страниц x среднее количество доставленных байтов | 1 000 000 x 2 МБ – это около 2 ТБ без учета CDN и служебных данных протокола. | Размер самой загруженной минуты, а не среднемесячного значения. |
| API | запрашивает x среднее количество байт ответа | 50 миллионов x 20 КБ – это около 1 ТБ. | Проверьте скорость пакетной передачи и параллелизм соединений |
| Доставка файлов | количество загрузок x средний размер файла | 100 000 x 500 МБ – это около 50 ТБ. | Более широкий порт сокращает очереди во время кампаний |
| Резервные копии | измененные данные x копии x частота | 2 ТБ, меняемые еженедельно с одной удаленной копией, составляют около 8 ТБ. | Не позволяйте окнам резервного копирования конкурировать с производственными |
Пять готовых профилей конфигурации выделенного сервера
Профили являются ярлыками для первого списка, а не заменой измерений. Начальному приложению часто требуются сбалансированные ресурсы; база данных отдает приоритет RAM и задержке хранения; службам с высоким трафиком требуется параллельный CPU, объем памяти и сетевой запас; ИИ добавляет GPU VRAM; узлы хранения отдают приоритет полезной емкости, целостности и скорости восстановления.
Отслеживайте ограничивающие показатели, указанные в предыдущих разделах, ожидаемый рост, модель избыточности, цель восстановления и план масштабирования на уровнях компонентов и услуг. Запас ресурсов ценен только тогда, когда он сохраняет показатели задержки, корректности и восстановления, которые важны для бизнеса. Используйте первую последовательно ограниченную метрику в качестве руководства для следующего теста.
Составьте короткий список двух соседних профилей, чтобы тест мог показать, достаточен ли меньший уровень или следующий уровень существенно снижает риск. Распространенным режимом сбоя является сопоставление проекта с именем профиля с упущением одного доминирующего требования, такого как скорость каждого ядра, память базы данных, GPU VRAM или исходящий трафик. Используйте одну и ту же рабочую нагрузку для обеих конфигураций-кандидатов, указав стоимость за успешный запрос или задание, включенную в сравнение, прежде чем рассматривать конфигурацию как готовую к работе. Обсудите результат с владельцем приложения, а также с командой инфраструктуры.
Пять профилей планирования
| Профиль | CPU направление | RAM направление | Хранилище и сетевое направление |
|---|---|---|---|
| Стартер | Сбалансированный современный CPU | 16-32 ГБ | SSD или NVMe, измеренный допуск на перенос |
| База данных | Мощное количество ядер плюс достаточный параллелизм | 64-256 ГБ или измеренный горячий набор | Низкая задержка NVMe, отказоустойчивость RAID, отдельное резервное копирование |
| Высокий трафик | Больше параллельных ядер с запасом по мощности | 64-256 ГБ | NVMe и порт, рассчитанный на пакетную передачу данных |
| АИ/GPU | CPU способен питать ускорители | 64-512 ГБ и выше | GPU VRAM сначала, быстро NVMe для моделей, адекватная сеть |
| Хранение | Умеренные вычисления, если не обрабатываются данные | 32-128 ГБ плюс потребности в файловой системе | Уровень емкости, избыточность, контрольная сумма и план восстановления |
Сравните AMD EPYC (https://unihost.com/dedicated/epyc/), GPU (https://unihost.com/dedicated/gpu/) и серверы с большим объемом памяти (https://unihost.com/dedicated/high-memory/).
Когда выбрать VPS, специализированное или индивидуальное решение
VPS эффективен для небольших или переменных рабочих нагрузок, сред разработки и сервисов, которые выигрывают от быстрого изменения размера. Выделенное оборудование рассчитано на длительную нагрузку, предсказуемую задержку, большой объем памяти, высокую IOPS или более сильную изоляцию. Специальное решение становится полезным, когда несколько ролей, частная сеть, узлы GPU, общее хранилище или аварийное переключение должны работать как одна система.
Соберите данные о частоте насыщения ресурсов, масштабировании времени выполнения заказа, отклонении производительности, ежемесячных затратах, ограничениях соответствия и эксплуатационных усилиях во время обычного трафика и во время репрезентативного пика. Совместите временные метки инфраструктуры с трассировками приложений, чтобы команда могла связать медленный запрос или неудачное задание с ресурсом, который был ограничен. Средние значения полезны для планирования затрат, но p95, p99 и рост очереди показывают, наносят ли уже короткие всплески ущерб службе.
Используйте VPS, пока его пределы остаются измеримыми и экономичными; переходите к выделенному, когда устойчивый спрос или предсказуемость оправдывают эксклюзивные ресурсы; Разработайте собственный стек, когда один сервер может создать узкое место или область сбоя, которых можно избежать. Основной риск планирования заключается в том, что вертикальные обновления рассматриваются как архитектурная стратегия после того, как рабочая нагрузка уже требует разделения ролей или резервирования. Подтвердите свой выбор с помощью параллельного анализа затрат и производительности, который включает миграцию, управление, резервное копирование и восстановление после сбоев, а не только стоимость вычислений. Сохраните условия тестирования и порог приемлемости в модуле Runbook, чтобы последующие изменения можно было проверить по тому же базовому состоянию.
Окончательный контрольный список и запрос конфигурации
Запрос на настройку должен включать тип рабочей нагрузки, стек программного обеспечения, текущие графики ресурсов, размер активных данных, параллелизм, целевую задержку, ежемесячную передачу, местоположение, горизонт роста, политику резервного копирования и RPО. Добавьте все требования к лицензированию, соответствию требованиям, GPU, частной сети или управлению, чтобы рекомендация охватывала всю операционную среду.
Создайте базовый уровень на основе текущего базового уровня, пикового базового уровня, предположения о росте, целей восстановления и критериев приемки для нагрузочного теста. Записывайте одни и те же сигналы до и после каждой настройки или изменения инфраструктуры. Если пропускная способность возрастает, а задержка и ошибки остаются под контролем, это изменение создает полезную емкость. Если очереди растут или задержка увеличивается, значит, система достигла предела, даже если один из основных показателей использования все еще выглядит удовлетворительным.
Запросите диапазон конфигурации с явными предположениями и путем обновления вместо одной необъяснимой модели сервера. Следите за заказом по частичному описанию и обнаружением после миграции того, что хранилище, трафик, лицензирование или восстановление были исключены. Перед заказом или миграцией используйте письменный контрольный список приемки, подписанный после развертывания, нагрузочного тестирования, настройки мониторинга и теста восстановления. Документированный критерий отклонения так же важен, как и критерий успеха, поскольку он сообщает команде, когда следует остановить развертывание или перейти на следующий уровень мощности.
Отправьте свою рабочую нагрузку и получите рекомендации по конфигурации
Часто задаваемые вопросы
Сколько CPU ядер нужно моему серверу?
Начните с количества задач, которые ваше программное обеспечение может выполнять параллельно, и измеряйте насыщенность каждого ядра, длину очереди и задержку хвоста. Добавляйте ядра, одновременно увеличивая пропускную способность без непропорционального увеличения задержки. Если один горячий поток остается пределом, более высокая одноядерная производительность может помочь больше, чем дополнительные ядра.
Сколько RAM достаточно для веб-сайта с высокой посещаемостью?
Измерьте пиковый рабочий набор приложения, базы данных, кэша и операционной системы при запланированном количестве рабочих. Диапазон планирования может начинаться от 32-128 ГБ для загруженного сайта, но правильное значение зависит от размера процесса, стратегии кэширования и размещения базы данных. Подтвердите это длительным пиковым тестом и наблюдайте за свопом и событиями OOM.
Как рассчитать ежемесячную пропускную способность?
Умножьте доставленные объекты или запросы на их средний размер ответа, а затем добавьте резервные копии, репликацию и накладные расходы протокола. Используйте мониторинг или аналитику для оценки ежемесячного итога. Определите скорость порта отдельно от самого загруженного интервала, поскольку среднемесячное значение скрывает всплески.
Когда мне следует выбрать выделенный сервер вместо VPS?
Выбирайте выделенное оборудование, когда нагрузка устойчива, отклонения в производительности являются дорогостоящими или проекту требуется большая RAM, высокая IOPS, выделенная GPU, более сильная изоляция или предсказуемая сеть. VPS хорошо подходит, когда спрос скромный или эластичный, а быстрое изменение размера более ценно, чем эксклюзивное оборудование.
