Настройка MSSQL для работы с 1С — мифы и реальность
Оптимизируем Microsoft SQL Server 2014 для работы с 1С. ОС — Windows Server 2012 R2. Напишу что нужно сделать, а что не нужно.
Определяю мифичность очень просто, если мне пришлось применить настройку — реальность, не пришлось — миф.
Устанавливаем последний Service Pack и Cumulative Update — реальность
На текущий момент нужно обновиться до SP3.
MSSQL - устанавливаем Service Pack 3
Обязательно нужно сделать.
Выравнивание разделов — миф
Рекомендуют выравнивать сектора дисков по границе 1024Кб и форматировать с размером блока 64Кб. Не заморачивайтесь, эта рекомендация устарела.
HKLM \ SYSTEM \ CurrentControlSet \ Services \ VDS \ Alignment
Эту настройку не применяем.
Database instant file initialization — частично миф, частично реальность
Рекомендуют включить возможность Database instant file initialization для пользователя, от которого запущена служба Microsoft SQL Server.
Что это за штука?
Во-первых, эта настройка влияет только на файл данных. Когда файл автоматически вырастает, то новый кусок заполняется нулями, в этот момент 1С может тормозить. Instant File Initialization (IFI) позволяет отключить это зануление.
Делается так.
- Запускаем Local Group Policy Editor: gpedit.msc
- Слева выбираем Local Computer Policy, Computer Configuration, Windows Settings, Security Settings, Local Policies, User Rights Assigment.
- Тыкаем в Perform volume maintenance tasks.
- Сюда добавляем юзера, от имени которого запускается SQL Server.
Однако, у меня там уже прописана группа Administrators, а пользователь, под которым работает служба SQL Server уже в этой группе.
Так что у меня ничего не пришлось настраивать. Но вы у себя проверьте.
Давайте проверим, что всё работает. Рекомендуют создать новую БД размером 5 Гб и логом 1 Мб. Вот тут тоже нужно быть внимательным, нужно создавать под тем же пользователем, от которого запускается сервис SQL. Я создам от имени другого пользователя, который тоже в группе Administrators.
База создалась мгновенно. На всякий случай попробую создать базу размером 50 Гб, место есть. Да, моментально на диске пропало 50 Гб и БД создалась быстро.
Вывод:
Instant File Initialization (IFI) работает из коробки, если пользователь, под которым работает сервис SQL входит в группу Administrators сервера.
Эту настройку применяем только при необходимости.
Lock pages in memory — реальность
Рекомендуют установить разрешение на Lock pages in memory (блокировку страниц в памяти) для пользователя, от которого запущена служба Microsoft SQL Server. Эта политика Windows определяет, какие учетные записи могут сохранять данные в физической памяти, чтобы система не отправляла страницы данных в виртуальную память на диске.
- Запускаем Local Group Policy Editor: gpedit.msc
- Слева выбираем Local Computer Policy, Computer Configuration, Windows Settings, Security Settings, Local Policies, User Rights Assigment.
- Тыкаем в Lock pages in memory.
- Видим, что политика не настроена. Можно добавить сюда пользователя, от имени которого работает SQL Server, я просто добавляю сюда группу Administrators.
Эту настройку применяем. Нужно учитывать, что потребление оперативки возрастёт.
Power Option: High performance — реальность
Да, это реальность. По умолчанию план электропитания в Windows Server 2012 R2 — Balanced.
В некоторых случаях, Microsoft не уточняет в каких, на сервере может из-за этого снижаться производительность. Переключаем план на High performance.
Эту настройку применяем.
Сжатие содержимого — миф
Рекомендуют проверить, что галка, отмеченная на картинке выше, снята. Имеется в виду папка, где лежат файлы БД. По умолчанию она снята — рекомендация миф.
Индексация файлов — миф
По умолчанию галка Allow files in this folder to have contents indexed in addition to the file properties стоит:
Казалось бы, надо снимать. Подумаем, эта галка указывает службе индексации, что содержимое нужно обработать. Зачем на сервере индексировать содержимое? А стоит ли вообще служба индексации по умолчанию? Проверяем:
А служба поиска не установлена! Ну и забиваем на все эти галки. Эту настройку не применяем.
Исключить файлы БД из систем резервного копирования — миф
Это классика, не нужно ничего исключать, нужно просто нормально резервирование делать.
Во-первых, не отделяйте мух от котлет. Не держите приложение 1С и SQL Server на одном сервере. MSSQL должен жить отдельно. И резервироваться он должен средствами MSSQL. И зеркалироваться.
Эту настройку не применяем.
Резервирование и обслуживание — реальность
Ссылки:
Maintenance Plans - резервное копирование и обслуживание баз данных в Microsoft SQL Server 2014
Настройка зеркалирования в Microsoft SQL Server 2014
Эту настройку применяем.
Настройка памяти — реальность
Да, память для MSSQL нужно настраивать. По умолчанию сиквел жрёт всё что может, системе начинает не хватать. Как итог - тормоза. Нужно выделить SQL серверу строго определённое количество памяти и пусть не рыпается.
Повторюсь:
Не держите приложение 1С и SQL Server на одном сервере. MSSQL должен жить отдельно.
Это позволить избежать конкуренции за ресурсы.
Эту настройку применяем.
Настройка процессора — реальность
Настроим проц.
Эту настройку применяем.
Расположение файлов данных — реальность
Файлы данных и файлы журналов транзакций желательно размещать на разных дисковых массивах. Если один из массивов быстрее, то лог нужно разместить там.
Эту настройку по возможности применяем.
Разбить tempdb на несколько файлов по количеству процессоров — миф
Миф обыкновенный:
Эту настройку не применяем.
Перенести tempdb в RAM — реальность
Сам протестировал, добился 10-кратного прироста скорости чтения-запись для tempdb.
MSSQL - переносим tempdb на RAM диск
Эту настройку по возможности применяем.
Установить параметр Max degree of parallelism = 1 — частично миф, частично реальность
В закладке Advanced есть возможность установить параметр Max degree of parallelism. Кто-то рекомендует ставить 1, чтобы запретить параллельные запросы. Смысл в том, что один толстый запрос может сожрать все процессоры и помешать другим пользователям. С другой стороны, запущенная на ночь обработка могла бы выполняться быстрее при использовании нескольких процессоров. Давайте поступим иначе - ограничим половиной процессоров. У меня их 8, ставлю 4.
Эту настройку применяем только при необходимости и в зависимости от количества процессоров.
Прирост файлов БД — реальность
Меняем дефолтные настройки прироста размера файлов данных и лога.
По умолчанию прирост 10%, это никуда не годится. Если база 500 гигабайт, то одномоментно отобранные 50 Гб места могут негативно сказаться на работе.
Ставим прирост 200 Мб.
Эту настройку применяем.
Флаги трассировки — реальность
4199 - включает исправления оптимизатора из фиксов.
1118 — использовать разные страницы памяти.
Запускаем SQL Server Configuration Manager. SQL Server Services. SQL Server — правой кнопкой свойства. Вкладка Startup Parameters. Добавляем -T1118 и -T4199.
Для применения потребуется перезапустить SQL сервер.
Эту настройку применяем.
Сетевые протоколы — реальность
Протокол "Named pipes" необходимо отключить.
Запускаем SQL Server Configuration Manager. SQL Server Network Connfiguration. Protocols for MSSQLSERVER (наш инстанс). Делаем Named Pipes - Disabled.
Эту настройку применяем.
Отключение DFSS — миф
DFSS по умолчанию устанавливается на терминальный сервер. При чём тут SQL? Отключать нечего.
Эту настройку не применяем.