Поставщик запускает короткий тест и показывает высокую пропускную способность массива. После переноса базы картина меняется: пользователи проводят документы, СУБД пишет журнал, резервная копия читает данные. Задержки растут, хотя результат теста остался прежним.
Если вы сравниваете два сервера до покупки, одного синтетического теста мало. Он годится для первичного отсева. Для выбора нужны смешанная длительная нагрузка и данные о задержках.
Вердикт простой: победитель короткого теста получает допуск к следующей проверке, но не заказ на поставку.
Пиковая скорость отвечает только за одну операцию
Синтетический тест изолирует операцию и повторяет её в заданных условиях. Так можно сравнить последовательное чтение, случайную запись или другой отдельный профиль.
Рабочая база ведёт себя иначе. Чтение, запись, обновления и фоновые задания идут одновременно. Операции конкурируют за диски, кэш контроллера и очередь запросов.
Методика ADH Decode разделяет эти два вопроса. Синтетический тест показывает скорость конкретной операции. Проверка рабочей нагрузки показывает поведение системы в условиях эксплуатации.
| Что показал тест | Что осталось неизвестным | Ошибочный вывод |
|---|---|---|
| Высокая скорость последовательного чтения | Как массив обслуживает случайные чтение и запись одновременно | «База будет открывать формы и проводить документы быстрее» |
| Много операций ввода-вывода | Как меняется задержка при заполненной очереди | «Пользователи не заметят пауз» |
| Быстрый короткий прогон | Что произойдёт после длительной записи и нагрева | «Массив сохранит эту скорость весь рабочий день» |
| Хороший результат записи | Какая часть данных попала в кэш контроллера | «Накопители записали весь объём с показанной скоростью» |
| Высокое среднее значение | Были ли редкие, но длинные задержки | «Отклик системы стабилен» |
Пиковая пропускная способность не доказывает, что база сохранит отклик при смешанном вводе-выводе.
Короткий профиль всё же полезен. Он быстро отсеивает вариант с явной проблемой: неверным режимом контроллера, медленным томом или ограничением интерфейса. Но сравнивать можно лишь тесты с одинаковыми параметрами.
Иначе вы сравните не накопители, а настройки вокруг них.
Кэш RAID-контроллера способен подменить результат
В режиме Write Back контроллер сначала принимает запись в собственный кэш. Система получает подтверждение до того, как массив запишет данные на накопители.
Короткий прогон может закончиться раньше, чем кэш заполнится. В отчёте останется скорость приёма данных контроллером, а не установившаяся скорость массива.
Intel в инструкции по настройке кэша RAID-контроллеров прямо связывает параметры кэша с результатами теста. Для большинства приложений компания рекомендует Write Back, Adaptive Read Ahead и Direct I/O. Эти рекомендации относятся к контроллерам, которые поддерживают соответствующие режимы.
Отсюда не следует, что Write Back нужно включать ради красивого отчёта. Сначала проверьте защиту кэша.
Прошивка контроллера Intel переводит запись из Write Back в Write Through, если резервная батарея отсутствует или разряжена. Intel не советует отключать эту защиту: при сбое питания данные из незащищённого кэша могут потеряться.
Два одинаковых массива дадут разные результаты, если один работает через защищённый Write Back, а второй перешёл в Write Through. Это не повод объявлять второй массив медленным. Сначала нужно выяснить состояние батареи и режим записи.
| Что зафиксировать в отчёте | Почему это меняет результат | Когда сравнение недействительно |
|---|---|---|
| Политику записи контроллера | Write Back подтверждает запись через кэш, Write Through ждёт накопители | На серверах действуют разные политики |
| Состояние BBU | Контроллер может автоматически сменить режим записи | Батарея одного контроллера отсутствует или разряжена |
| Режим кэша операционной системы | Системный кэш способен принять часть операций вместо дискового тома | На одном сервере кэш включён, на другом отключён |
| Размер тестового файла | Малый файл может поместиться в кэш и не нагрузить массив | Файлы отличаются или их размер не указан |
| Длительность прогона | Короткая проверка не показывает установившийся режим | Один прогон закончился раньше другого |
| Размер блока | Профиль крупных блоков не равен мелким случайным операциям | Значения различаются или не записаны |
| Глубину очереди | Она меняет число одновременных запросов к подсистеме | Тесты выполнены с разной очередью |
Если отчёт не фиксирует эти условия, повторить сравнение нельзя. Для решения о покупке такой отчёт непригоден.
Параметры стоит записывать рядом с результатом, а не в отдельной переписке. Через месяц никто не вспомнит, какая батарея стояла в контроллере и какой кэш использовала система.
Именно поэтому методика тестирования должна описывать конфигурацию стенда и условия прогона. Итоговая цифра без них не переносится на другой сервер.
Смешанная нагрузка отделяет быстрый массив от подходящего
Во время работы 1С дисковая подсистема не выполняет одну операцию по кругу. СУБД читает страницы, записывает изменения и ведёт журнал. Параллельно могут работать резервное копирование и регламентные задания.
ADH Decode указывает ещё на одно отличие рабочей нагрузки. Операции зависят друг от друга и создают конкуренцию. Изолированный запрос этих зависимостей не показывает.
Случайный набор SQL-запросов проблему не решает. Он не сохраняет порядок пользовательских действий, связи между запросами и характер доступа к данным.
Приблизить проверку к рабочей базе можно двумя способами. Первый — записать обезличенный поток операций и воспроизвести его на тестовом контуре. Второй — собрать модель с заданными долями чтения, записи и фоновой нагрузки.
Для воспроизведения нужен репрезентативный период. В нём должны присутствовать обычная работа, пиковая активность и фоновые процессы. Конфиденциальные данные перед переносом на стенд удаляют или заменяют.
Модель проще подготовить, но она требует понимания нагрузки. Если задать доли операций наугад, тест снова измерит искусственный сценарий.
Для Windows-сервера такой профиль можно собрать в Microsoft DiskSpd. Инструмент задаёт размер блока, соотношение чтения и записи, глубину очереди, число потоков и несколько целей.
DiskSpd также выводит перцентили задержки. Параметр -Sh отключает программный и аппаратный кэш для соответствующего режима проверки. Полную команду нужно собирать под конкретный том и сверять с документацией Microsoft DiskSpd.
Готовую универсальную команду здесь дать нельзя. Без сведений о СУБД, массиве и характере операций она создаст точный отчёт о неподходящей нагрузке.
| Этап проверки | Какая нагрузка нужна | Как принять решение |
|---|---|---|
| Первичный отсев | Один синтетический профиль на обоих вариантах | Убрать вариант с явным провалом или нестабильным результатом |
| Выбор сервера | Длительный смешанный профиль при одинаковых настройках | Сравнить пропускную способность и хвостовые задержки |
| Проверка перед переносом | Обезличенное воспроизведение рабочего периода либо подтверждённая модель | Убедиться, что отклик сохраняется при характерном сочетании операций |
| Повторная проверка | Тот же профиль после изменения контроллера, прошивки или кэша | Не смешивать результаты разных конфигураций |
Синтетический прогон сокращает список кандидатов. Решение о покупке появляется только после смешанной нагрузки.
Тип накопителя тоже нельзя оценивать по названию интерфейса. Проверки NVMe, SSD и SAS в одинаковых условиях полезнее сравнения паспортных характеристик. Там видно, почему неизменный стенд важнее этикетки на накопителе.
Среднее значение скрывает паузы пользователей
Высокая пропускная способность может соседствовать с нестабильным откликом. Среднее значение сглаживает редкие задержки, хотя именно их замечают пользователи.
Допустим, большая часть операций проходит ровно, но отдельные запросы надолго задерживаются в очереди. Средняя скорость отчёта останется высокой. Пользователь увидит паузу при проведении документа.
Поэтому в отчёте нужны не только операции в секунду и мегабайты в секунду. Добавьте задержку и её перцентили. DiskSpd умеет выводить такое распределение.
Перцентиль показывает границу, быстрее которой завершилась заданная доля операций. Он помогает увидеть хвост: небольшую часть запросов с самым долгим ожиданием.
Универсального порога для 1С нет. Он зависит от операции, СУБД, конфигурации базы и ожиданий пользователей. Сравнивайте не отвлечённую задержку, а два варианта в одном профиле.
Отдельно сопоставьте начало и конец длительного прогона. ProlimeHost в руководстве по проверке серверов связывает деградацию накопителей с длительной записью, насыщением контроллера, температурой и поведением очередей.
Если хвостовые задержки растут к концу, высокая начальная скорость не спасает вариант. Именно конец прогона ближе к рабочей смене, чем первые минуты.
На уже работающем сервере тест дисков не заменяет диагностику. Если 1С тормозит, сначала определите масштаб проблемы: сеанс, операцию, базу или весь сервер. Затем пройдите проверку от симптома до дискового слоя.
Замена накопителей по одному короткому отчёту может оставить причину на месте. Паузы способны возникнуть в СУБД, сети, фоновых заданиях или рабочем процессе сервера 1С.
Как читать два отчёта перед покупкой
Сначала проверьте воспроизводимость. В отчётах должны совпадать профиль нагрузки, размер файла, длительность, блок, очередь и число потоков.
Затем проверьте окружение. Запишите модели контроллеров, прошивки, политики записи, состояние BBU и режим системного кэша.
Только после этого сравнивайте результаты. Начните с пропускной способности, затем посмотрите на задержки. Отдельно оцените их хвост и изменение к концу прогона.
Если поставщик показывает лишь итоговую картинку, запросите параметры и исходный отчёт. Отказ раскрыть условия делает результат непроверяемым.
Для покупки недостаточно фразы «этот массив быстрее». Формулировка должна звучать точнее: при одинаковом смешанном профиле вариант сохраняет отклик и не накапливает хвостовые задержки.
Решение по конкретной базе может зависеть от фоновых заданий, СУБД и допустимого времени простоя. Если эти данные ещё не собраны, закажите оценку дисковой схемы под вашу нагрузку до согласования поставки.
Правило допуска дисковой подсистемы
Для первичного отсева прогоните один синтетический профиль на обоих серверах. Настройки должны совпадать. Проигравший отсеивается, победитель проходит дальше.
Для покупки запускайте длительную смешанную нагрузку. Выбирайте вариант, который сохраняет задержки к концу прогона, а не лидирует в первые минуты.
Для приёмки перед переносом воспроизведите обезличенный рабочий период. Если это невозможно, используйте модель с обоснованными долями операций. Победа в коротком тесте без такой проверки остаётся неподтверждённой.
Перед тем как использовать отчёт в заявке на покупку, проверьте пять пунктов:
- Зафиксированы политика кэша контроллера и состояние BBU.
- На обоих вариантах совпадают параметры теста.
- Профиль сочетает чтение и запись.
- В отчёте видны перцентили задержки в начале и конце прогона.
- Результат хранится вместе с конфигурацией и условиями проверки.
Провал любого пункта запрещает использовать отчёт как основание для покупки. Такой результат годится лишь как повод повторить тест.