При работе с крупными базами данных 1С, особенно объемом от 350 ГБ и более, стандартные подходы к обслуживанию SQL Server могут быть недостаточными. Необходимо внедрять комплексные планы, учитывающие специфику высоких нагрузок и больших объемов данных. Рассмотрим, какие шаги мы можем предпринять для оптимизации производительности и стабильности работы.
Обслуживание базы данных SQL Server для 1С сводится к нескольким ключевым операциям, которые необходимо выполнять с определенной периодичностью.
Обновление статистики. Статистика помогает SQL Server строить оптимальные планы выполнения запросов. Чем активнее изменяются данные в базе, тем чаще необходимо обновлять статистику.
INSERT).sp_updatestats. Примерный скрипт для всех баз, кроме системных:
sp_MSforeachdb 'if ''?'' NOT IN (''tempdb'',''master'',''model'',''msdb'') use ? exec sp_updatestats'
WITH FULLSCAN для большей точности.DBCC FREEPROCCACHE), чтобы SQL Server начал использовать новые, более оптимальные планы запросов.Реиндексация и перестроение индексов. Эти операции приводят индексы и сами данные в порядок, что критически важно для скорости поиска и сортировки.
ALTER INDEX... REORGANIZE или DBCC INDEXDEFRAG используется для дефрагментации. Эта операция не блокирует всю таблицу и доступна в Standard Edition SQL Server. Мы применяем ее, когда фрагментация индекса составляет от 10% до 30%.ALTER INDEX... REBUILD или DBCC DBREINDEX полностью перестраивает индекс. Это более длительная операция, которая может блокировать доступ к таблице на время выполнения. Поэтому ее мы проводим в периоды минимальной активности пользователей, например, раз в неделю по выходным. Преимущество ALTER INDEX... REBUILD в том, что оно автоматически пересчитывает статистики по обрабатываемому индексу. Мы используем ее при фрагментации свыше 30%.ALLOW_PAGE_LOCKS = OFF) для борьбы с эскалацией блокировок. Это может вызывать ошибки при попытке реорганизации индексов. Как решение, мы можем временно включать ALLOW_PAGE_LOCKS = ON перед реорганизацией и отключать после. Некоторые эксперты даже предлагают полностью отказаться от регламентных заданий по дефрагментации и перестроению индексов, особенно на SSD-дисках, если техническое окно не позволяет их выполнить.Бэкапы и сокращение логов транзакций. Эти операции стандартны, но их важность для больших баз возрастает.
Помимо регламентных операций, мы можем значительно улучшить производительность за счет правильной настройки самого SQL Server.
Настройка tempdb. База данных tempdb интенсивно используется 1С, особенно при работе с временными таблицами или уровнем изоляции транзакций SNAPSHOT. Мы можем предпринять следующие шаги:
tempdb на самом быстром диске (SSD или NVMe).tempdb. Рекомендуется 4-8 файлов (по одному на каждое ядро процессора, но не более 8), чтобы улучшить параллелизм и избежать блокировок.tempdb и отключаем автоматическое увеличение (autogrowth), чтобы избежать фрагментации и неожиданных операций роста. Если нагрузка на tempdb высока, следует значительно увеличить ее начальный размер.tempdb: Использование RAM-диска для tempdb может обеспечить максимальную скорость, если у нас достаточно оперативной памяти. Однако нам необходимо тщательно мониторить размер tempdb и учитывать пропускную способность памяти, а также другие приложения, использующие ОЗУ. Скорость RAM-диска не всегда выше NVMe из-за особенностей кэширования и копирования буферов в памяти. Если каналов памяти много и пропускная способность действительно высокая (например, 200 GiB/s), тогда смысл появляется.Сжатие данных. Сжатие данных (на уровне строк и страниц) в SQL Server может экономить дисковое пространство и память, так как данные хранятся в сжатом виде даже в оперативной памяти. Сжатие доступно во всех редакциях SQL Server начиная с версии 2016 SP1. Однако сжатие требует дополнительных ресурсов CPU для каждого доступа к сжатым данным (распаковки), поэтому его не рекомендуется применять к "горячим" (часто используемым) данным. Мы наиболее эффективно используем сжатие для "холодных" данных, которые редко используются. Колоночные индексы могут обеспечивать еще более сильное сжатие (до 10 раз). Сжатие резервных копий также рекомендуется для экономии места и сокращения времени их создания и передачи.
Query Store (Хранилище запросов). Если наш SQL Server достаточно свежий (SQL Server 2016 и выше, доступен во всех редакциях), мы включаем Query Store. Это мощный инструмент для мониторинга и анализа производительности запросов. Он сохраняет историю планов выполнения запросов и метрики производительности (использование CPU, чтения, записи), агрегируя их по заданным интервалам. Это позволяет нам выявлять регрессии производительности, вызванные изменением планов запросов, и сравнивать планы во времени. Query Store очень полезен для выбора оптимального плана запроса в сложных случаях.
Параллелизм (MAXDOP). Для 1С мы рекомендуем устанавливать параметр Max Degree of Parallelism (MAXDOP) равным 1, так как платформа 1С не рассчитана на распараллеливание запросов внутри СУБД. Это помогает избежать проблем с производительностью, когда SQL Server пытается распределить задачу на несколько ядер, что в итоге может привести к замедлению.
Разделение файлов. Мы по-прежнему придерживаемся практики размещения файлов данных, логов транзакций и tempdb на разных физических носителях. Это значительно повышает производительность, позволяя выполнять параллельные операции ввода-вывода.
Выбор и настройка аппаратного обеспечения, а также подход к виртуализации, играют огромную роль в производительности 1С.
Виртуализация. Дискуссия о производительности 1С на виртуальных машинах продолжается. Наши тесты и опыт показывают, что виртуальные машины могут демонстрировать снижение производительности (до двух раз) по сравнению с физическим оборудованием, независимо от типа виртуализации. Это объясняется накладными расходами на виртуализацию, управлением кэшем процессора, ожиданием доступа к памяти и DMA-каналам. Особенно это проявляется в монолитных приложениях, требующих высокой скорости обработки в потоке, как 1С. Однако, при правильной настройке виртуальной среды и выделении достаточных ресурсов, пользователи 1С могут не заметить разницы, если сервер способен обслуживать несколько виртуальных машин. Например, для 3 виртуальных серверов 1С (до 100 пользователей) это может быть оправдано. Если же мы имеем высоконагруженный сервер 1С с 1000 пользователями, которому необходимы все 100% ресурсов, то тогда нет смысла резать его на виртуалки; лучше выделить полностью под одну задачу, возможно, даже потребуется несколько физических серверов с объединением в кластер. Важно выравнивать виртуальные ресурсы (ядра, NUMA-узлы) с физической структурой оборудования, чтобы SQL Server корректно их использовал. Также для 1С сервер "любит" высокую тактовую частоту процессора.
Схема управления питанием. Мы всегда устанавливаем максимальную производительность в схеме управления питанием на сервере. Это гарантирует, что процессор всегда работает на своей максимальной частоте без перехода в энергосберегающие режимы, что критически важно для производительности 1С.
Помимо основных пунктов, есть еще несколько моментов, которые мы учитываем при работе с большими базами 1С.
Мониторинг. Мы активно используем встроенные счетчики производительности Windows, технологический журнал платформы 1С, а также такие инструменты, как Zabbix, Grafana или специализированные решения для мониторинга SQL Server и 1С. Это позволяет нам отслеживать производительность, выявлять узкие места и аномалии, а также оперативно реагировать на проблемы.
Рефакторинг кода 1С. Любые, даже самые лучшие, настройки SQL Server не помогут, если код 1С написан неоптимально. Мы постоянно работаем над рефакторингом кода запросов и общего кода в 1С, чтобы минимизировать нагрузку на базу данных. Это включает в себя оптимизацию сложных запросов, использование индексированных полей, избегание запросов "выборка по условию" в больших циклах и т.д.
Change Tracking (Отслеживание изменений). Технология Change Tracking в SQL Server (начиная с 2008) позволяет отслеживать изменения в строках таблиц (INSERT, DELETE, UPDATE). Мы используем ее для инкрементальной загрузки данных или создания пользовательских решений, которым требуется знать, какие строки были изменены с момента последнего обхода. Это позволяет снизить нагрузку при синхронизации данных, так как не требуется сканировать всю таблицу для выявления изменений.
Применение этих рекомендаций в комплексе позволит нам добиться значительного улучшения производительности и стабильности работы больших баз 1С на SQL Server, даже в условиях высоких нагрузок.