Калькулятор розміру сервера: 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 мільйонів х 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 і розмір порту для пакетів |
| AI/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, щоб пізніші зміни можна було перевірити за тією ж базовою лінією.
Остаточний контрольний список і запит на налаштування
Запит на конфігурацію має містити тип робочого навантаження, стек програмного забезпечення, графіки поточних ресурсів, розмір активних даних, паралелізм, цільову затримку, щомісячну передачу, місцезнаходження, горизонт зростання, політику резервного копіювання та RPO/RTO. Додайте будь-які вимоги щодо ліцензування, відповідності, GPU, вимоги до приватної мережі чи керування, щоб рекомендація охоплювала повне операційне середовище.
Побудуйте базову лінію на основі поточної базової лінії, максимальної базової лінії, припущення зростання, цілей відновлення та критеріїв прийнятності для тесту навантаження. Записуйте однакові сигнали до та після кожного налаштування чи зміни інфраструктури. Якщо пропускна здатність зростає, а хвостова затримка та помилки залишаються під контролем, зміна створила корисну ємність. Якщо черги зростають або затримка зростає, система досягла ліміту, навіть якщо один заголовок показника використання все ще виглядає комфортним.
Попросіть діапазон конфігурації з явними припущеннями та шлях оновлення замість однієї непоясненої моделі сервера. Слідкуйте за замовленням із часткового опису та виявленням після міграції, що зберігання, трафік, ліцензування чи відновлення було виключено. Перед замовленням або міграцією скористайтеся письмовим контрольним списком приймання, підписаним після розгортання, навантажувального тестування, налаштування моніторингу та тесту відновлення. Задокументований критерій відхилення так само важливий, як і критерій успіху, оскільки він говорить команді, коли зупинити розгортання або перейти до наступного рівня потужності.
Надішліть своє робоче навантаження та отримайте рекомендацію щодо конфігурації
Поширені й відповіді
Скільки CPU ядер потрібно моєму серверу?
Почніть із кількості завдань, які ваше програмне забезпечення може виконувати паралельно, і виміряйте насиченість кожного ядра, довжину черги та кінцеву затримку. Додайте ядра, поки пропускна здатність зростає без непропорційного збільшення затримки. Якщо один гарячий потік залишається обмеженням, більш висока одноядерна продуктивність може допомогти більше, ніж додаткові ядра.
Скільки RAM достатньо для веб-сайту з високим трафіком?
Виміряйте максимальний робочий набір програми, бази даних, кешу та операційної системи при запланованій кількості робочих місць. Діапазон планування може починатися приблизно з 32-128 ГБ для завантаженого сайту, але правильне значення залежить від розміру процесу, стратегії кешу та розміщення бази даних. Підтвердьте це за допомогою тривалого пікового тесту та спостерігайте за подіями обміну та OOM.
Як розрахувати місячну пропускну здатність?
Помножте доставлені об’єкти або запити на їх середній розмір відповіді, а потім додайте резервне копіювання, реплікацію та накладні витрати на протокол. Використовуйте моніторинг або аналітику, щоб оцінити підсумок за місяць. Розмір швидкості порту окремо від найбільш завантаженого інтервалу, оскільки середньомісячне значення приховує спалахи.
Коли я повинен вибрати виділений сервер замість VPS?
Вибирайте спеціальне обладнання, коли навантаження постійне, відхилення продуктивності є дорогим або проект потребує великого RAM, високого IOPS, виділеного GPU, сильнішої ізоляції або передбачуваної мережі. VPS добре підходить, коли попит скромний або гнучкий, а швидке змінення розміру є ціннішим, ніж ексклюзивне обладнання.
