Смена началась. Тридцать сборщиков одновременно сканируют товар, 1С проверяет остатки и записывает результаты отбора. Через несколько минут подтверждение позиции занимает секунды, хотя терминалы исправны.
Новые сканеры задержку не уберут. Сервер одновременно выполняет выборки, вычисления и транзакции записи. По методике выбора оборудования 1С скорость системы сильнее всего зависит от процессора, дискового массива и объёма памяти.
Посчитаем сервер под 30 одновременных сессий, базу 300 ГБ и рост на 200 ГБ в год. Эту конфигурацию можно отдать поставщику как исходную, а затем проверить на складском пике.
Тридцать терминалов создают поток коротких транзакций
Примем, что каждый сборщик подтверждает одну позицию раз в пять секунд. Это допущение для расчёта: на твоём складе интервал может быть другим.
Получаем:
30 терминалов ÷ 5 секунд = 6 операций в секунду
За час непрерывного пика сервер обработает:
6 × 3600 = 21 600 операций
Это число не определяет нагрузку на процессор. Проведение строки заказа и проверка серии товара требуют разного времени. Зато оно задаёт частоту запросов, которую нужно воспроизвести при испытании.
Файловая база для такого склада не подходит. В сравнительной таблице ITART её предел обозначен пятью одновременными пользователями: при большем числе сессий возникают конфликты блокировок. Для 30 сборщиков нужна клиент-серверная схема с PostgreSQL или Microsoft SQL Server. Если компания пока работает с общим файлом, сначала пригодится разбор перехода на сервер 1С.
Восемь быстрых ядер — старт, а не гарантия
ITART указывает для SQL-сервера 1С ориентир от восьми ядер с высокой частотой. Для расчётных шести операций в секунду начнём с одного восьмиядерного процессора. Второй сокет усложнит платформу, но сам по себе не сократит время одной транзакции.
Частоту нельзя вывести из числа терминалов. Поэтому методика 1С разделяет расчёт номинального количества ядер и выбор модели процессора. Конкретный CPU нужно сравнивать на тяжёлом складском сценарии: проведении заказа, проверке остатков или другой операции, которая создаёт очередь на твоей базе.
Стартовая точка для запроса поставщику — от восьми физических ядер с высокой частотой. Если предлагают несколько процессоров, выбирай по времени выполнения тяжёлой операции, а не по числу ядер в таблице характеристик.
Когда на той же машине работают СУБД, обмены, печать, фоновые задания и другие базы, процессор делится между ними. Расчёт только по складским терминалам тогда занижает нагрузку.
Диски должны держать случайную запись
Складская база читает остатки и сразу записывает изменения. Для такой нагрузки ITART рекомендует SSD или NVMe, RAID 10 и подбор по IOPS — числу операций ввода-вывода в секунду.
В характеристиках накопителя недостаточно проверить общий TBW — допустимый объём записи за срок службы. Производитель промышленных SSD ATP публикует отдельные показатели для последовательной и случайной нагрузки по методике JESD219A. Для базы нужен второй: последовательный тест блоками 128 КБ даёт большее число, но описывает перенос крупных файлов, а не смешанные запросы СУБД.
Берём четыре серверных SSD или NVMe по 1 ТБ в RAID 10. Две зеркальные пары дадут около 2 ТБ номинальной полезной ёмкости до форматирования и внутреннего резерва накопителей. RAID 10 соответствует рекомендации ITART для SQL-сервера 1С с интенсивным вводом-выводом.
Ёмкость считаем на три года:
300 ГБ + 3 × 200 ГБ = 900 ГБ
Добавим 30% на отклонение от прогноза, обслуживание и временные операции:
900 ГБ × 1,3 = 1,17 ТБ
Массив на 2 ТБ закрывает расчёт и оставляет около 830 ГБ до номинального предела. Если база растёт не на 200, а на 400 ГБ в год, получим:
300 ГБ + 3 × 400 ГБ = 1,5 ТБ
С резервом 30% потребуется 1,95 ТБ. Четыре накопителя по 1 ТБ формально вместят такой объём, но рабочего запаса не останется. Для этого темпа роста бери четыре SSD по 1,92–2 ТБ.
Память зависит от рабочего набора базы
ITART указывает для SQL-сервера 1С диапазон от 32 до 128 ГБ памяти. Для одной базы объёмом 300 ГБ возьмём 64 ГБ как исходное допущение: это середина диапазона, которую нужно подтвердить на пике по использованию памяти и работе кэша СУБД.
ECC RDIMM здесь — выбор автора для серверной платформы, а не требование ITART. Такая память исправляет одиночные битовые ошибки, но сама по себе не определяет скорость 1С.
Если сервер обслуживает несколько баз или тяжёлые отчёты вытесняют рабочие данные из кэша, 64 ГБ закончатся раньше дискового места. Связь между нагрузкой и остальными параметрами подробнее разобрана в материале о характеристиках сервера 1С.
Конфигурацию проверяют во время волны комплектации
Средняя загрузка за сутки скрывает очередь в начале смены. Методика 1С требует считать оборудование по самому тяжёлому паттерну. Модельная система должна повторять приложение, режим работы, версии платформы, СУБД и операционной системы.
Однопользовательскую модель можно собрать за 1–3 дня, но 1С оценивает точность такого теста как относительно низкую. Он покажет стоимость отдельной операции, однако не воспроизведёт блокировки между тридцатью сборщиками.
Подготовка многопользовательского стенда обычно занимает больше месяца. Зато он выявляет задержки и блокировки, которые возникают только при совместной работе.
Для закупки можно взять восемь ядер за стартовую точку, но в условии приёмки зафиксировать испытание на утреннем пике. В тесте должны работать те же расширения, обмены и фоновые задания, что и на складе. Пустая типовая база не покажет, как сервер поведёт себя с доработанной рабочей системой.
Спецификация под задачу
Считаем конфигурацию для 30 одновременных сессий, одной операции на терминал каждые пять секунд, клиент-серверной 1С и базы 300 ГБ. Прирост — 200 ГБ в год, горизонт закупки — три года.
| Компонент | Что заложить | Почему |
|---|---|---|
| Процессор | 1 × от 8 физических ядер с высокой частотой | ITART задаёт нижний ориентир; конкретную модель выбирают по тесту тяжёлой складской операции |
| Память | 64 ГБ ECC RDIMM как стартовое допущение | Объём находится внутри диапазона 32–128 ГБ для SQL-сервера 1С; достаточность проверяют по рабочему набору на пике |
| Хранилище | 4 × 1 ТБ серверных SSD или NVMe, RAID 10 | Около 2 ТБ номинальной полезной ёмкости при расчётной потребности 1,17 ТБ |
| Ресурс SSD | Random TBW или DWPD для нагрузки JESD219A | Последовательный TBW не описывает смешанную запись базы |
| Сеть | От 1 Гбит/с; при высокой нагрузке — 10 Гбит/с | Такой диапазон ITART указывает для SQL-сервера в зависимости от числа клиентов и архитектуры |
При 60 сборщиках расчётный поток вырастет вдвое:
60 терминалов ÷ 5 секунд = 12 операций в секунду
Сначала измерь загрузку процессора и задержку тяжёлой операции по методике 1С. Если CPU упирается в загрузку, добавляй ядра или разноси сервер приложений и СУБД по разным машинам.
Переход от 64 к 128 ГБ привязывай не к размеру файла базы, а к поведению системы во время пика. Поводы увеличить память — несколько активных баз, широкие отчёты и вытеснение рабочего набора из кэша.
Эта спецификация рассчитана на один сервер. Если склад не может ждать его восстановления, продолжи выбор между одним сервером и кластером 1С. Второй узел увеличит стоимость закупки, зато позволит строить схему под допустимое время простоя, а не только под скорость операций.
