Оптимизируем Microsoft SQL Server 2014 для работы с 1С. ОС — Windows Server 2012 R2. Напишу что нужно сделать, а что не нужно.
Определяю мифичность очень просто, если мне пришлось применить настройку — реальность, не пришлось — миф.
Устанавливаем последний Service Pack и Cumulative Update — реальность
На текущий момент нужно обновиться до SP3.
MSSQL - устанавливаем Service Pack 3
Обязательно нужно сделать.
Выравнивание разделов — миф
Рекомендуют выравнивать сектора дисков по границе 1024Кб. Не заморачивайтесь, эта рекомендация устарела. Операционная система теперь сама выравнивает раздел как нужно для дисков более 4 ГБ.
HKLM \ SYSTEM \ CurrentControlSet \ Services \ VDS \ Alignment
Эту настройку не применяем.
Форматирование с размером блока 64Кб
А вот здесь всё очень неявно. Есть статья Best Practice от Microsoft:
В ней явно говорится:
Partition the Disk volumes hosting SQL databases (Data and log) with 64 KB allocation unit size:
A drive can be formatted with different sizes ranging from 512 bytes to 64K sizes with the default being 4KB (4096 bytes). This setting is also called as “Bytes Per Cluster”. The atomic unit of storage in SQL Server is a page which is 8KB in size. Extents are groups of eight 8 KB pages that are physically contiguous to each other for a total of 64 KB. SQL Server uses extents to store data. Hence, on a SQL Server machine the NTFS Allocation unit size hosting SQL database files (Including tempdb files) should be 64K.
Кстати, обратите внимание на другие разделы статьи, возможно, там тоже найдёте для себя что-то полезное.
Казалось бы всё ясно, 64 килобайта — наше всё. Но... Откуда ноги растут? Есть рекомендация от Microsoft с 2008 года:
https://docs.microsoft.com/en-us/previous-versions/sql/sql-server-2008/dd758814(v=sql.100)
Здесь аргументированно с указанием конкретного железа, на котором производились испытания, пишут:
Note that file allocation unit (cluster) size commonly correlates with common stripe unit sizes. The performance question here is usually not one of correlation per the formula, but whether the cluster size is the NTFS default of 4,096 bytes or has been explicitly defined at 64 KB, which is a best practice for SQL Server.
Снова 64 килобайта — наше всё. Читаем дальше:
An appropriate value for most installations should be 65,536 bytes (that is, 64 KB) for partitions on which SQL Server data or log files reside. In many cases, this is the same size for Analysis Services data or log files, but there are times where 32 KB provides better performance. To determine the right size, you will need to do performance testing with your workload comparing the two different block sizes.
Получается, что SQL сервер ведёт себя лучше при размере кластера 64 килобайта, однако, в некоторых случаях, максимальной производительности удавалось достигать при размере кластера в 32 килобайта.
А теперь добавляем переменных:
- Появились новые типы массивов типа SSD и NVMe.
- Всё чаще SQL сервер устанавливается виртуально или в облаке, где файловая система виртуальной машины живёт внутри файловой системы гипервизора.
- Производители жёстких дисков и RAID контроллеров используют кеширование и дополнительные технологии ускорения работы дисков.
Ещё следует учитывать, что NTFS для разных размеров диска создаёт разные размеры блока. Стандартный размер кластера (лучше использовать это название) в файловой системе NTFS:
- ёмкость до 16 Тб — 4 килобайта
- ёмкость от 16 до 32 Тб — 8 килобайт
- ёмкость от 32 до 64 Тб — 16 килобайт
- ёмкость от 64 до 128 Тб — 32 килобайта
- ёмкость от 128 до 256 Тб — 64 килобайта
Так что если вы не хотите заморачиваться, то ставьте размер блока (кластера) при форматировании 64 килобайта. Однако не факт, что при этом ваш SQL сервер будет работать быстрее. Правильный ответ можно получить только при тестировании производительности.
Присылайте ссылки на статьи, где проводились исследования производительности для разных размеров кластера. Истина где-то там.
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? Отключать нечего.
Эту настройку не применяем.
Источник:
https://internet-lab.ru/mssql_1c_optimization
Если вам понравилась статья, то ставьте 👍🏻 каналу.
Пишите комментарии, задавайте вопросы, подписывайтесь.
