Ошибки конфигурации MS SQL Server под 1С. Часть 1 - планирование и развёртывание

За много лет работы с MS SQL Server я много раз наблюдал одну и ту же последовательность событий.

Сервер под 1С устанавливается методом «далее - далее - готово». Полгода всё работает. Потом наступает пик, сезон продаж или закрытие года, и система встаёт. Отдел сопровождения ищет причину, находит десяток версий и ни одного ответа. Руководство нервничает. Решение рождается само собой, купить новый сервер, так как «этот уже не справляется».

Вопрос, который витает немым подтекстом звучит просто. В чём именно он не справляется?

Вариантов проблем четыре, и справлятся с ними надо по-разному. Блокировки, Неоптимальный код, Дисковая подсистема, Нехватка памяти или процессорных ядер. Новое железо помогает в последних двух случаях, да и то не всегда. Блокировки и медленный код переезжают на новый сервер в полном составе, и через следующие полгода история повторяется, уже с потраченным бюджетом.

Повторяется всё это не от нехватки знаний. Причина лежит уровнем выше и касается уже не людей, а того, как мы привыкли относиться к самому продукту.

Возьмите Oracle Exadata. Никому не придёт в голову привезти стойку, включить питание и пройти установку кнопкой «Далее». Конфигурацию считают под профиль нагрузки. Схему размещения данных согласовывают заранее. Приёмку и ввод в эксплуатацию закладывают отдельным этапом работ, с отдельными сроками и бюджетом, и зовут людей, которые это уже проходили. Никто при этом не спрашивает, к чему такие сложности, всем понятно, какого класса машина приехала.

Теперь посмотрим на MS SQL Server под 1С. Те же терабайты, та же критичность для бизнеса, те же сотни пользователей в пик сезона, те же ночные окна, в которые нужно успеть с обслуживанием. По классу задачи разговор идёт об одном и том же, но почему-то разворачивается такой сервер “мастером” за пятнадцать минут, из которых десять уходит на копирование файлов.

Проще при этом стал не продукт. Проще стал вход, и вход мы по привычке принимаем за всю дистанцию. Oracle продаёт свою машину вместе с методикой внедрения, она приезжает в одной коробке с железом, и деваться от неё некуда. К MS SQL Server методику нужно принести с собой.

Приносить её, как правило, некому. В типичной компании сервером СУБД под 1С занимается системный администратор в паре с 1С-разработчиком или франчайзи. У администратора компетенция в операционных системах и сети, у разработчика в конфигурациях и проводках. Уровень СУБД остаётся между ними, и вопросы этого уровня закрываются способом, который обоим понятнее, покупкой железа. Внятно ответить, почему система тормозит и в каком именно месте, может специалист по базам данных. Такой позиции в штате среднего бизнеса обычно нет, и дальше я покажу, во что это обходится на каждом этапе жизни сервера.

Одна оговорка до начала. Статья написана вокруг связки MS SQL Server и 1С, при этом уровень железа (разнесение дисков, баланс памяти и процессоров, электропитание, антивирус) устроен одинаково для любой серьёзной СУБД и любой учётной системы поверх неё. Те же принципы работают для Dynamics 365 и CRM-систем на этой платформе, для ERP на Oracle и PostgreSQL. Специфика 1С начнётся там, где пойдёт речь о профилях нагрузки, а во второй части о режимах блокировок платформы.

Начну со свежего случая, в нём собралось практически всё, о чём пойдёт речь ниже.

Случай из практики - сервер за три миллиона

Позвонил знакомый, у них в компании розничная торговля, подробности опущу, работать стало невозможно, система замирает каждый час. Попросил связаться с руководителем их ИТ-отдела.

Разговор с руководителем вышел коротким. Новый сервер уже куплен, стоил три миллиона рублей, приедет через неделю. От меня требовалось одно - перенести на него базы. Я попросил доступы к текущему серверу. Раз до переезда неделя, есть время посмотреть, с чем имеем дело.

Картина оказалась хрестоматийной, дальше по тексту вы встретите её по частям. Сервер приложений 1С стоял на одной машине с СУБД и генерировал поток временных файлов. Всё хозяйство лежало на диске C. Рядом с рабочей базой лежала стопка бухгалтерских баз, на этом же сервере строились отчёты. Настройки - по умолчанию, до последнего флага. Версия была SQL Server 2017.

Первым делом я снял метрики. Они подтвердили нагрузку от сервера приложений, показали затык дисковой подсистемы и нехватку процессорной мощности. Дальше работа руками. Сервер приложений 1С переехал на отдельную машину, в старый сервер добавили дисков, базы и потоки ввода-вывода я разнёс, настройки привёл в порядок. Самая занятная находка ждала в конце, франчайзи забыли отключить одно из тяжёлых регламентных заданий, оно и создавало ежечасные фризы поверх общей перегрузки.

Через неделю старый сервер работал без сбоев, и приезда новой машины мы ждали уже ничтоже сумняшеся. Когда она приехала, я собрал конфигурацию основываясь на метриках со старой инсталляции. SQL Server 2025, данные, журналы транзакций и tempdb разнесены по томам, версионирование строк включено. Идёт третий месяц, за это время не было ни одного звонка с просьбой помочь.

Разберём, что здесь произошло. Сервер купили до ответа на вопрос, в чём старый не справляется. Ответ оказался составным, ежечасные замирания создавало забытое регламентное задание, заметную часть общей нагрузки давал сервер приложений на той же машине, и только третьим пунктом шла нехватка процессоров и памяти.

Покупка в итоге пришлась к месту, по совпадению, поскольку расчёта под ней не было. Правильный порядок начинается с диагностики сервера, и дальше я разберу по шагам, из чего она складывается при планировании.

Первый вопрос - какая у вас 1С

Прежде чем говорить о параметрах, нужно понять, что за систему мы обслуживаем. На практике встречаются два принципиально разных профиля.

Первый - тяжёлая ERP. УПП, отраслевые решения, конфигурации ERP-класса, к этому же профилю относятся Axapta и другие системы уровня предприятия. Одна большая база, сотни активных пользователей, длинные транзакции, тяжёлые отчёты поверх оперативной работы.

Самая большая база под моим сопровождением выросла из Axapta до 22 ТБ. Продажи и склад федерального ритейла.

Второй профиль - куст бухгалтерских баз. Сто и больше баз на одном инстансе, типичная картина бухгалтерского обслуживания или группы компаний. В каждую базу ходят раз в день или раз в неделю, зато в период сдачи отчётности нагрузка вырастает на порядок по всем базам одновременно.

Конфигурация под эти профили местами противоположная. Для тяжёлой ERP главная борьба идёт за параллелизм, tempdb и блокировки. Для куста баз - за план обслуживания, который успевает пройти по всем базам за ночь, за память, поделённую на всех, и за возможность восстановить одну базу, не трогая остальные девяносто девять. Кстати, второй профиль - это место, где архитектура MS SQL Server раскрывается в полную силу. Один инстанс динамически распределяет ресурсы между всеми базами, у каждой базы собственный журнал транзакций и собственное восстановление на момент времени.

Типовые статьи «настройка SQL для 1С» дают один список параметров на оба случая. Поэтому они и не работают.

Развёртывание. Дисковая подсистема

Инсталляция по умолчанию кладёт всё на диск C (систему, файлы данных, журналы транзакций, tempdb). Для теста это допустимо.

В проде такой сервер упрётся в дисковую очередь. Вопрос только в сроке.

Потоки ввода-вывода должны быть разнесены по физическим носителям. Файлы данных, журналы транзакций, tempdb и резервные копии - это четыре разных профиля нагрузки. Данные читаются случайным доступом, журнал пишется строго последовательно, tempdb принимает шквал мелких операций, бэкап даёт длинное последовательное чтение и запись. Сведённые на один том, эти потоки выстраиваются в общую очередь, и каждый замедляет остальные. Требование разносить файлы данных, журналов и tempdb по разным носителям зафиксировано в рекомендациях Microsoft по настройке операционной системы под SQL Server ¹.

Перед планированием разнесения нужно понять, с каким железом мы имеем дело. Вариантов два. Standalone-машина, у которой дисковая подсистема на борту, и сервер с дисковой полкой, откуда ресурсы подаются отдельными LUN. Принцип разнесения один и тот же, разница в количестве каналов, по которым можно подать потоки данных.

Моя базовая схема первичной инсталляции выглядит так. Диск C - операционная система. Диск D - файлы данных (mdf). Диск E - журналы транзакций. Диск F - tempdb. Резервные копии уходят на сетевой ресурс.

Хранить бэкапы под ногами, на самом сервере, я считаю ошибкой, при выходе машины из строя теряются и базы, и копии, то есть мы своими руками создаём лишнюю точку уязвимости.

Все тома собираются в RAID и подаются разными каналами, в первую очередь это касается данных, журналов транзакций и tempdb. Такой набор я считаю минимально достаточной конфигурацией дисковой подсистемы для продуктивного сервера 1С. При работе с дисковой полкой каждый из перечисленных ресурсов подаётся отдельным LUN.

Отдельная система хранения данных - признак богатой инфраструктуры, встречается она нечасто. Обычно покупается сервер со встроенными дисками и контроллером, и здесь принципиален выбор многоканального контроллера, на отдельные каналы вешаются отдельные RAID-массивы, потоки разводятся физически.

Про tempdb скажу особо. Пишут, что эту базу можно массивом не защищать, при каждом перезапуске сервера она пересоздаётся с нуля. Для нашей конфигурации совет плохой. При включённом версионировании строк через tempdb проходит хранилище версий ², отказ её тома останавливает работу всего инстанса, поэтому RAID для tempdb обязателен. Если контроллер достался простой, двухканальный, раскладка превращается в работу по обстоятельствам. Смотрим, какие базы нагружены сильнее остальных, и решаем, что с чем может соседствовать, опираясь на собственный опыт.

Существует и более тонкий приём - смешанные типы дисков. Большие архивные таблицы выносятся в отдельные файловые группы и укладываются на медленные накопители, оперативные данные остаются на быстрых. Это тюнинг уровня advanced, браться за него имеет смысл, когда базовая схема уже выстроена и работает.

В современных реалиях выбор для этих томов - NVMe-накопители, с одной оговоркой. Модели должны быть оптимизированы под запись (write intensive). Накопители, рассчитанные на чтение, под серверной нагрузкой с интенсивной записью (журнал транзакций, tempdb) быстро теряют и производительность, и ресурс.

Последний штрих при подготовке томов - форматирование. Тома под данные, журналы и tempdb форматируются с размером кластера 64 КБ. По умолчанию NTFS размечает том кластером 4 КБ, при этом SQL Server работает с данными экстентами по 64 КБ (восемь страниц по 8 КБ). Размер кластера, выровненный под экстент, убирает лишние операции ввода-вывода на ровном месте. Рекомендация в 64 КБ для томов с данными, журналами и tempdb - официальная позиция Microsoft ¹, подробный разбор с измерениями есть в классическом документе про выравнивание разделов ³.

Отдельная частая находка на аудитах - сервер приложений 1С и СУБД на одной машине, оба на системном диске. Сервер приложений 1С в процессе работы создаёт большое количество временных файлов, и эта запись конкурирует с СУБД за дисковый ресурс, попутно замедляя саму операционную систему. Экономия на второй машине оборачивается тем, что две системы мешают друг другу на каждой операции. В случае из начала статьи вынос сервера приложений на отдельную машину стал первым шагом и снял заметную часть нагрузки ещё до всех остальных работ.

Баланс процессоров, памяти и дисков

Три компонента сервера обязаны быть сбалансированы между собой. Под балансировкой я понимаю простое правило, количество процессорных ядер не должно создавать давления на объём памяти. Многопоточная обработка данных удерживает в памяти большое количество страниц, поэтому щедрый набор ядер при скромной памяти гарантирует постоянный дефицит. Увеличение одного компонента тянет за собой увеличение другого, и оплачивается эта гонка из бюджета компании.

Отправная точка расчёта - старая система, если она есть. Ориентир по процессорам такой, средняя загрузка не выше сорока процентов, тогда остаётся запас на кратковременные пики. От посчитанной процессорной мощности планируется объём памяти.

Один из ключевых показателей достаточности памяти - время жизни страницы в буферном пуле, page life expectancy. Рядом с ним смотрят процент попадания в кэш и другие счётчики памяти, но начинать удобно именно с него. Универсального норматива у него нет, оценивается он наблюдением за конкретной системой, для одной нормальны значения в час и выше, для другой рабочими оказываются двадцать-тридцать минут. Зависит это от интенсивности транзакционной нагрузки, плотный поток OLTP в любом случае выдавливает страницы из памяти и снижает показатель. Граница, которую переходить нельзя, наступает в момент, когда страницы в памяти не задерживаются и каждое чтение уходит на диск. Подсистема ввода-вывода в этом режиме перегружается, деградирует весь сервер целиком.

Здесь есть ловушка, чтобы посчитать пиковую нагрузку, её нужно было измерять на прошлой инсталляции, а мониторинга там, как правило, не было. Круг замыкается, и новый сервер покупается по принципу «возьмём вдвое больше ядер».

Виртуализация эту задачу упрощает. Можно стартовать с небольшого набора ресурсов, посмотреть через какое-то время, как сервер справляется, и добавить процессоров или памяти по факту. С baremetal такой свободы нет, добавление процессорной мощности или памяти в купленную машину проблематично, поэтому считать нужно заранее и тщательно, а брать с небольшим запасом.

Инсталляция без «далее - далее»

Дальше сама установка. Перечислю настройки, которые задаются один раз при развёртывании, а расплата за них наступает месяцами позже. Каждый пункт - регулярная находка на аудитах.

Коллация. Задаётся при установке инстанса, для 1С нужна Cyrillic_General_CI_AS. Мастер установки подставляет коллацию по региональным настройкам Windows, и совпадает она с нужной не всегда. Обнаруживается ошибка при создании первой базы, исправляется переустановкой инстанса.

max server memory. По умолчанию верхняя граница памяти для СУБД не задана, и сервер занимает всю память машины. Операционной системе и службам остаётся подкачка, деградирует всё разом. Ограничение выставляется сразу при установке, с запасом под нужды ОС, Microsoft рекомендует задавать верхнюю границу во всех версиях сервера ⁴, а начиная с SQL Server 2019 инсталлятор сам предлагает расчётное значение. Для крупных систем сюда же добавляется право Lock Pages in Memory сервисному аккаунту, страницы буферного пула перестают уходить в файл подкачки.

Смотреть при этом нужно в обе стороны, сколько памяти получает СУБД и сколько остаётся операционной системе. Все потоки, которые порождают службы на сервере, обрабатывает в конечном счёте операционная система, и количество потоков, которое она способна держать, напрямую зависит от объёма доступной ей памяти. На больших инсталляциях, где много ядер и высокая нагрузка, этот резерв становится критичным.

Ориентир для типового сервера такой, при восьми ядрах и 32 ГБ оперативной памяти системе оставляется шесть гигабайт, меньше нельзя. С ростом машины растёт и резерв. В моей практике были инсталляции с резервом 12-15 гигабайт, а на сервере банковского транзакционного процессинга со 144 ядрами и полутора терабайтами памяти под операционную систему уходило до 20 гигабайт, при меньшем запасе система захлёбывалась потоками на пиках нагрузки.

Instant File Initialization. Право Perform Volume Maintenance Tasks для сервисного аккаунта, одна галка при установке. С ней файлы данных растут и восстанавливаются без предварительного заполнения нулями ⁵, что на больших базах экономит часы при восстановлении из бэкапа. Про эту галку часто забывают.

План электропитания. Windows по умолчанию работает в режиме Balanced и снижает частоты процессора. Сервер баз данных на таком плане работает вполсилы, в логах при этом ни одного признака проблемы. Выставляется High Performance, заодно проверяются настройки энергосбережения в BIOS. Эффект плана Balanced на серверную производительность описан у самой Microsoft ⁶.

Антивирус. Без настроенных исключений сканер проверяет файлы данных и журналов на каждом обращении, фактически сервер делает всю работу дважды. В исключения вносятся расширения mdf, ndf, ldf, bak, trn, каталоги установки СУБД и процесс sqlservr.exe, полный официальный список исключений опубликован Microsoft ⁷.

Autogrowth и преаллокация. Приращение файлов по умолчанию мелкое, под нагрузкой файл растёт сотнями шагов, каждый шаг притормаживает запись. Правильный подход - преаллокация. Файлы данных и журналов создаются сразу достаточного размера с запасом, а autogrowth остаётся страховкой с крупным шагом на случай ошибки планирования.

Сетевые протоколы и лишние компоненты. После установки проверяется, что включён TCP/IP и согласован порт между сервером 1С и СУБД. Обратная сторона вопроса - лишнее. SSAS, SSRS и прочие компоненты, поставленные «до кучи», занимают память продуктивного сервера без всякой пользы. На прод ставится только ядро СУБД.

Прогон дисков до продакшена. Перед вводом в строй дисковая подсистема прогоняется синтетическим тестом, подойдёт DiskSpd от Microsoft ⁸, он умеет имитировать характер нагрузки SQL Server. Цель - фактические цифры пропускной способности и задержек по каждому тому, пока сервер пуст. Эти цифры пригодятся дважды. Первый раз при приёмке железа у поставщика, второй как эталон для сравнения, когда через год возникнут подозрения на деградацию дисков.

Виртуализация. Секция для продвинутых

Значительная часть серверов 1С сегодня работает в виртуальных машинах, и у виртуализации есть собственный слой ошибок конфигурации. Главная сложность этого слоя в том, что изнутри виртуальной машины он не виден, по счётчикам самой машины всё в порядке, при этом система тормозит. Разберу основные засады. Развёрнутый справочник по теме - официальный гайд VMware по архитектуре SQL Server на vSphere ⁹, большинство пунктов ниже разобраны там в деталях.

Память и ballooning. Гипервизор выделяет виртуальным машинам больше памяти, чем есть физически, это называется переподпиской. Когда памяти на хосте перестаёт хватать, внутри виртуальной машины срабатывает balloon driver, механизм, отбирающий у неё память в пользу хоста. Windows внутри виртуалки начинает выгружать страницы в подкачку, и первым под выгрузку попадает буферный пул СУБД как самый крупный потребитель. Выглядит это как внезапный обвал page life expectancy и рост чтений с диска без видимых причин. Для продуктивной виртуалки СУБД память резервируется в полном объёме (memory reservation в VMware). В Hyper-V для SQL Server выключается Dynamic Memory и задаётся статический объём.

Процессоры и CPU Ready. Виртуальные ядра выделяются с переподпиской точно так же. Пока хост свободен, всё работает. Когда соседние виртуалки нагружаются, vCPU ждёт очереди на физическое ядро, и это ожидание накапливается в метрике CPU Ready. Изнутри виртуальной машины оно не видно совсем, диспетчер задач показывает свободный процессор, запросы при этом выполняются медленно. Правила здесь два. Для СУБД переподписка на хосте держится близкой к один к одному. Ядра «про запас» виртуалке не раздаются, широкой машине труднее получить все ядра одновременно, поэтому восемь vCPU нередко работают быстрее двадцати четырёх.

NUMA. Двухпроцессорный сервер - это два NUMA-узла, у каждого своя ближняя память. Виртуалка, помещающаяся в один узел, работает с локальной памятью на полной скорости. Виртуалка, растянутая на два узла, часть обращений к памяти гоняет через соседний процессор. SQL Server умеет учитывать топологию NUMA при условии, что гипервизор передал её виртуальной машине, функция называется vNUMA. Малоизвестная тонкость в том, что в vSphere до восьмой версии включённое горячее добавление процессоров, CPU hot-add, выключает vNUMA полностью, и галка, поставленная для удобства, оставляет СУБД без данных о топологии памяти. В vSphere 8.0 поведение исправили, hot-add больше не отключает vNUMA, но на старых версиях гипервизора эта проверка обязательна.

Электропитание хоста. План High Performance на виртуализации выставляется дважды, в Windows внутри виртуальной машины и на самом хосте, плюс проверяется BIOS хоста. Настройка внутри машины без настройки хоста не работает, частотами управляет железо под гипервизором.

Дисковый ввод-вывод. Для томов с данными, журналами и tempdb используется паравиртуальный контроллер PVSCSI в VMware вместо эмуляции LSI, у него выше пропускная способность и ниже накладные расходы. Второй приём - несколько виртуальных контроллеров. У каждого своя очередь команд, поэтому данные, журналы и tempdb разносятся по разным контроллерам. Это прямое продолжение принципа раздельных каналов, перенесённое с физического уровня на виртуальный. Остаётся и классика общего датастора, соседняя виртуалка с файловым архивом отбирает IOPS у СУБД, никакая настройка внутри виртуальной машины этого не компенсирует.

Снапшоты и бэкап уровня гипервизора. Снапшот виртуальной машины - дельта-файл, в который уходят все изменения. Снапшот, забытый на неделю, разрастается и кратно замедляет запись. Отдельная история - системы резервного копирования уровня гипервизора. В момент создания и удаления снапшота виртуалка замирает на секунды, эффект называется stun. Пользователи 1С видят его как короткие регулярные подвисания строго по расписанию бэкапа. Если жалобы на замирания приходят по часам, расписание заданий и бэкапов проверяется первым делом, вспомните историю из начала статьи.

Общий вывод по виртуализации короткий. Гибкость «начни с малого и добавляй» оплачивается обязанностью смотреть на два уровня сразу, внутрь виртуальной машины и на хост. Причины половины случаев «тормозит на виртуалке» находятся на хосте, куда у администратора 1С или DBA часто нет даже доступа.

Полдела сделано

Правильная установка и настройка MS SQL Server под 1С закрывает целый пласт будущих проблем, тех, что закладываются один раз при развёртывании и проявляются месяцами позже.

Оставшийся пласт относится к эксплуатации и оптимизации.

Как отличить блокировки от нехватки ресурсов, что делать с параллелизмом и tempdb, откуда берётся миф «на Postgres 1С не тормозит» и при чём здесь режимы блокировок платформы - об этом вторая часть, [Coming soon…].

Ссылки

1. Operating system best practice configurations for SQL Server - Microsoft ↩ ↩²

2. tempdb database - Microsoft Learn ↩

3. Disk Partition Alignment Best Practices for SQL Server - Microsoft SQLCAT ↩

4. Server memory configuration options - Microsoft Learn ↩

5. Database instant file initialization - Microsoft Learn ↩

6. Slow performance on Windows Server when using the Balanced power plan - Microsoft, KB 2207548 ↩

7. Configure antivirus software to work with SQL Server - Microsoft Learn ↩

8. DiskSpd - Microsoft ↩

9. Architecting Microsoft SQL Server on VMware vSphere. Best Practices Guide - VMware ↩