Память для создания индекса sql для 1с

Обновлено: 02.07.2024

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

И хоть вопросы немного разнятся, но проблема как оказалось у всех одинакова:

«MS SQL скушал, забрал, использовал всю оперативку»

Действительно не редкие случаи, когда MS SQL чрезмерно употребляет ОЗУ и если не убавить его аппетиты можно и совсем остаться без свободной оперативной памяти.

Первое так сказать быстрое и «почти универсальное» решение проблемы чрезмерного употребления ОЗУ в MS SQL это указать в свойствах MS SQL (вкладка «Память») тот объем ОЗУ, который мы можем отдать на нужды «сиквела». (Не забывайте после перезапустить MS SQL)

Более подробная информация по вопросу выделения ОЗУ, есть на курсе: Администратор 1С.

На картинке выше указанно 4 Гб которые может употребить MS SQL (И обычно за «Максимальный размер памяти сервера он и не выходит»).

Таким образом, мы снимаем «острую» проблему с потреблением ОЗУ в MS SQL.

Конечно, при всем этом сразу возникает много вопросов:

1. Почему MS SQL не освобождает память ?

2. Сколько ОЗУ для моего MS SQL установить ?

3. Как определить сколько ОЗУ нормально для MS SQL ?

4. Можно-ли не наращивать объем ОЗУ для MS SQL ?

5. Чем грозит ОЗУ в MS SQL ?

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

Главный вопрос: «Почему MS SQL не освобождает память, неужели он не умеет это делать ?

Умеет!

MS SQL умеет динамически работать с ОЗУ!

Вот что пишет MS:

Когда SQL Server использует память динамически, он периодически опрашивает систему, чтобы определить объем свободной физической памяти. SQL Server использует API уведомления памяти QueryMemoryResourceNotification, чтобы определить, когда можно выделить и освободить память буферного пула.

Но почему же это не всегда происходит?

Все просто.

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

Безусловно, это нормально поведение не только MS SQL, но и большинства других СУБД.

Только сведя к минимуму операции ввода /вывода с диска (работая с ОЗУ) можно добиться максимальной производительности, что собственно и пытается делать MS SQL.

К сожалению не только «природа» 1С Предприятия способствует чрезмерным аппетитам «сиквела», тут здорово помогают и «кривые запросы» и «ошибки» в коде, и конечно все это ведет к тому, что MS SQL употребляет ОЗУ больше чем мы рассчитывали, (часто всю что видит).

Другими словами, MS SQL не виноват в том, что 1С «дает повод» брать больше ОЗУ и не дает основания ее освобождать.

Благо в MS SQL есть инструмент позволяющий «руками» ограничить потребление ОЗУ, что собственно в самом начале статьи и продемонстрировали на скрине.

Конечно, помимо инструментов есть, и советы от Microsoft касательно MS SQL:

Рекомендуется устанавливать MS SQL единственным (кроме системы) софтом.

Так он не будет конфликтовать за ресурсы с другими программами и сможет взять ОЗУ сколько ему потребуется.

Объем ОЗУ (в идеале) должен быть равен размеру всех баз.

Другими словами если у Вас 3 базы по 10 Гб, размер ОЗУ для MS SQL в идеале 30 Гб.

Безусловно в идеале и «миллион» долларов вряд ли бы кого расстроил ) но исходим от того что имеем ), и 30% процентов от баз также будет очень хорошо! (Во многих случаях и меньше того).

Физика работы MS SQL, проста в базовом плане потребления ОЗУ, помещаем в буфер то, что часто используется, чтоб обеспечить как можно лучшую производительность.

Если «сиквел» обнаружит, что у него всего 30% ОЗУ он будет просто больше писать и читать с диска и обходится тем, что есть. Да, конечно, всему есть придел и слишком большой дефицит ОЗУ приведет сперва к падению производительности (хорошо будет заметно при формировании отчетов в 1С), а потом и к различным ошибкам, вплоть до «вылета» программы.

(Рекомендую время от времени просматривать журнал MS SQL не сыпется ли уже ошибки связанные с памятью, особенно обратить внимание на строки memory pressure).

Вот мы и подошли к еще одному Важному вопросу:

«Так сколько ОЗУ надо для счастливой» жизни «сиквелу» ) ?

В рамках данной статьи, попытаюсь дать ответ и на этот не простой вопрос, или как минимум указать верное направление)

Если Вы хотите больше узнать о технической стороне 1С, тогда регистрируйтесь на первый бесплатный модуль курса: Администратор 1С >>>

Сервер "1С:Предприятия" и SQL-сервер

В данном разделе рассмотрены особенности настройки SQL-сервера для обеспечения взаимодействия сервера "1С:Предприятия 8" с SQL-сервером. Напомним, что в качестве SQL-сервера предполагается использовать Microsoft SQL Server 2000 с установленным Service Pack 2 или Microsoft SQL Server 2005. Далее по тексту под SQL-сервером будем понимать именно этот продукт. Поскольку использование "1С:Предприятия 8" в варианте "клиент-сервер" подразумевает хранение данных в SQL-сервере, для безошибочной работы "1С:Предприятия 8" необходимо уделить внимание следующим вопросам:

распределение SQL-сервера и сервера "1С:Предприятия" по компьютерам;
проверка наличия и версии SQL-сервера и компонента доступа к данным;
выбор протокола передачи данных между сервером "1С:Предприятия" и SQL-сервером;
настройка прав пользователя сервера "1С:Предприятия 8".

Рассмотрим подробнее каждый из перечисленных вопросов.

Распределение SQL-сервера и сервера "1С:Предприятия" по компьютерам

SQL-сервер и сервер "1С:Предприятия 8" могут быть установлены как на одном компьютере, так и на разных компьютерах, в зависимости от предполагаемой загрузки (см. руководство: "1С:Предприятие 8. Клиент-сервер. Особенности установки и использования"). Сервер "1С:Предприятия 8" взаимодействует с SQL-сервером через специальный компонент доступа к данным - Microsoft OLE DB Provider for SQL Server, входящий в состав Microsoft Data Access (MDAC), который, в свою очередь, взаимодействует с SQL-сервером либо непосредственно, если SQL-сервер установлен на том же компьютере, что и сервер "1С:Предприятия", либо через некоторый протокол передачи данных, если SQL-сервер и сервер "1С:Предприятия" установлены на разных компьютерах.

Проверка наличия и версий SQL-сервера и компонента доступа к данным

Для нормальной работы сервера "1С:Предприятия 8" необходимо, чтобы на компьютере, на котором установлен сервер "1С:Предприятия", присутствовал компонент Microsoft OLE DB Provider for SQL Server, который обычно входит в состав операционной системы Microsoft Windows 2000 и более новых и расположен в файле C:\Program Files\Common Files\System\OLE DB\sqloledb.dll. Маршрут используемого файла sqloledb.dll можно посмотреть в ветке
HKEY_CLASSES_ROOT\CLSID\\InprocServer32
системного реестра. Чтобы узнать его версию, необходимо открыть закладку Versions диалога свойств этого файла. Версия должна быть 08.10.9030 или более поздняя. Если это не так, то необходимо установить клиентские компоненты Microsoft SQL Server. Он также входит в состав Microsoft Data Access 2.6. Еще необходимо обратить внимание на файл C:\WINNT\system32\ntwdblib.dll, который должен иметь версию 8.00.194 или более позднюю.

В качестве SQL-сервера должен использоваться Microsoft SQL Server 2000 с установленным Service Pack 2 или Microsoft SQL Server 2005. Проверить версию SQL-сервера можно при помощи утилиты Enterprise Manager, входящей в комплект SQL-сервера. Запустите ее на компьютере, на котором установлен SQL-сервер, выберите ветку Console Root -> Microsoft SQL Servers -> SQL Server Group -> (Local), откройте окно ее свойств и на закладке General обратите внимание на строку Product version. Должна быть версия 8.00.534(SP2) или более поздняя. Если это не так, установите Microsoft SQL Server 2000 Service Pack 2 или Microsoft SQL Server 2005.

Выбор протокола передачи данных между сервером "1С:Предприятия" и SQL-сервером

Если сервер "1С:Предприятия" и SQL-сервер установлены на разных компьютерах, то передача данных осуществляется посредством сетевого протокола. Установки сетевых протоколов на SQL-сервере и у компонентов доступа к данным должны быть согласованы между собой. Для установки сетевых протоколов на SQL-сервере можно воспользоваться утилитой SQL Server Network Utility. Ее загрузочный модуль обычно находится в файле "C:\Program Files\Microsoft SQL Server\80\Tools\Binn\svrnetcn.exe". Эта утилита отображает диалог, в котором на закладке General представлен список включенных и выключенных протоколов. Для надежной работы "1С:Предприятия 8" рекомендуется включить протокол TCP/IP (первой строкой) и Named Pipes (второй строкой) и выключить все остальные протоколы.

Компьютер, на котором установлен сервер "1С:Предприятия", является по отношению к SQL-серверу клиентом, и для определения его сетевых протоколов воспользуйтесь утилитой SQL Server Client Network Utility. Ее загрузочный модуль обычно находится в файле "C:\WINNT\system32\cliconfg.exe". Она отображает диалог, в котором на закладке General представлен список включенных и выключенных протоколов. Рекомендуется использовать протокол TCP/IP, поскольку это исключает дополнительные проблемы с настройкой системы безопасности Windows и обеспечивает наибольшую производительность системы. Остальные протоколы лучше выключить. Обратите внимание на закладку Alias. Упоминание на ней имени используемого "1С:Предприятием" SQL-сервера может изменить выбранный сетевой протокол и привести к неожиданным эффектам.

Настройка прав пользователя сервера "1С:Предприятия 8"

Для повышения гибкости настройки прав рекомендуется использовать SQL Server Authentication.

Перед созданием первой информационной базы выполните следующие настройки. Запустите утилиту Enterprise Manager, входящей в комплект SQL-сервера, выберите ветку Console Root -> Microsoft SQL Servers -> SQL Server Group -> (Local), откройте окно ее свойств. На закладке Security переключатель Authentication установите в положение SQL Server and Windows и нажмите Ok. Выберите ветку Console Root -> Microsoft SQL Servers -> SQL Server Group -> (Local) -> Security -> Logins. Создайте учетную запись, имя и пароль, которой вы будете задавать в качестве имени и пароля пользователя SQL при создании информационной базы (Локальное Меню -> New Login. ). На закладке General отображенного диалога: в строке Name задайте имя пользователя; переключатель Authentication установите на SQL Server Authentication и задайте пароль пользователя; укажите master в качестве Default Database. На закладке Server Roles включите роль Database Creators, а на закладке Database Access найдите базу данных master и включите для нее роль public. После этого информационную базу можно создавать.

После создания информационной базы эта учетная запись станет собственником созданной базы данных и будет иметь возможность чтения данных из системных таблиц базы данных master, что и требуется для нормальной работы сервера "1С:Предприятия". От имени этой учетной записи могут быть созданы и другие базы данных. Если это нежелательно, то в свойствах рассматриваемой учетной записи на SQL-сервере на закладке Server Roles роль Database Creators можно выключить. Более подробную информацию по администрированию SQL-сервера можно найти в документации к Miсrosoft SQL Server.

Настройка выделения памяти опциями "Maximum server memory" и "Minimum server memory"

Опция Maximum server memory

Принцип расчёта опции Maximum server memory возьмём из статьи Server Memory Server Configuration Options

В общем случае максимальный объём памяти, который можно выдать экземпляру SQL Server рассчитывается так:

Maximum server memory = Всего ОЗУ на сервере - ОЗУ под нужды ОС - ОЗУ под сторонние приложения - ОЗУ SQL Server (накладные расходы экземпляра, выходящие за рамки «Maximum server memory»)

В нашем случае в качестве опорной ОС для SQL Server используется 64-битная Windows Server 2012 R2 Standard с 72GB ОЗУ и 12-core CPU. Проведём расчёт, на базе нашего примера.

Рассчитываем ОЗУ под нужды ОС

У каждой версии ОС есть минимальные требования к ОЗУ, но они более, чем скромные. Есть мнения, что для систем с объёмом ОЗУ более 20GB под ОС нужно резервировать 12.5% общего объёма ОЗУ. На мой субъективный взгляд это избыточный подход, и исходя из имеющейся практики использования Windows Server 2012 R2, полагаю, что для комфортной работы базовой ОС в нашем случае будет более, чем достаточно 4GB ОЗУ.

Рассчитываем ОЗУ под сторонние приложения

Помимо потребностей базовой ОС, на сервере, как правило, имеются приложения инфраструктурной обвязки, такие как всевозможные агенты мониторинга, управления, резервного копирования, антивирусное ПО и т.д. В случае, если сервер 1С:Предприятие планируется установить на одной системе с SQL Server, то нужно учесть величину ОЗУ, необходимую для работы сервера 1С:Предприятия (анализируем суммарное потребление памяти такими процессами, как ragent, rmngr и rphost). В нашем примере 1С на сервере SQL Server нет, а есть только инфраструктурные приложения набора System Center (агенты SCOM/SCCM/SCDPM) и антивирусное ПО. В общей сложности под эти задачи мы зарезервируем 2GB ОЗУ.

Рассчитываем ОЗУ SQL Server

Чтобы рассчитать накладные служебные расходы ОЗУ SQL Server, выходящие за рамки параметра Maximum server memory, воспользуемся формулой из статьи Server Memory Server Configuration Options:

stack size * calculated max worker threads + -g startup parameter (or 256MB by default if -g is not set).

Значение stack size рассчитывается согласно документа Memory Management Architecture Guide. На 64-битной ОС с 64-битной SQL Server stack size равен 2048KB Значение calculated max worker threads рассчитывается согласно документа Configure the max worker threads Server Configuration Option. В этом документе приводится таблица расчётных значений в зависимости от количества процессоров и битности сервера.
В нашем случае используется 64-битный сервер с 12 ядрами, поэтому расчёт будет выполняться по формуле 512 + ((logical CPU’s - 4) * 16) = 640.

Итак, в нашем примере накладные расходы SQL Server составят 2MB * 640 + 256MB = 1536MB = 1,5GB.

Обратите внимание на то, что если на сервере SQL Server планируется использовать более одного экземпляра SQL Server, то расчёт накладных расходов нужно выполнять по аналогии отдельно для каждого экземпляра. Например, в нашем случае планируется использование двух инстансов SQL Server, поэтому значение, которое нужно зарезервировать на накладные расходы SQL Server будет увеличено до 3GB (1,5GB * 2)

Итоговый расчёт Maximum server memory

Согласно нашего примера, итоговый расчёт памяти, который можно указать в качестве Maximum server memory будет выглядеть так:

Всего ОЗУ на сервере (72GB) - ОЗУ под нужды ОС (4GB) - ОЗУ под сторонние приложения (2GB) - ОЗУ накладные расходы SQL Server (3GB) = 63GB.

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

Одному из двух экземпляров SLQ Server, который в нашем случае будет использоваться разными мелкими служебными приложениями, мы разрешим использовать лишь малую часть расчётного максимального значения - 3GB, а экземпляру SQL Server, который будет обслуживать базы 1C:Предприятие мы отдадим оставшиеся 60GB в качестве Maximum server memory.

Опция Minimum server memory

Параметр Minimum server memory определяет нижнюю границу невысвобождаемой экземпляром SQL Server памяти. При запуске экземпляра эта память не занимается сразу, однако добравшись до этой нижней границы, указанный объём памяти закрепляется за работающим экземпляром SQL Server.

Найти каких-то чётких рекомендаций относительно этого показателя для 1С не удалось, поэтому воспользуемся простым примером из документа 1С:ИТС - Настройки Microsoft SQL Server для работы с 1С:Предприятием и установим значение Minimum server memory в виде половины от рассчитанного выше значения Maximum server memory.

Дополнительные источники информации:

Проверено на следующих конфигурациях:

Версия ОС	Версия SQL Server
Microsoft Windows Server 2012 R2 Standard EN (6.3.9600)	Microsoft SQL Server 2016 SP2 CU4 (13.0.5233.0)

Автор первичной редакции:
Алексей Максимов
Время публикации: 13.02.2019 10:57

Подготовка дисковой подсистемы под файлы БД SQL Server

В случае использования ОС Windows Server 2003 желательно произвести выравнивание (смещение) начального сектора (Partition Offset / Starting Offset) на уровень 1024KB. Выравнивание может быть выполнено только на этапе создания дискового раздела NFTS и невозможно для уже существующих разделов без из пересоздания. Для ОС Windows Server 2008 и выше выравнивание проводить не требуется, так как все вновь создаваемые разделы NTFS уже смещены на число байт, кратное размеру кластера (Bytes Per Cluster / Allocation unit size). Для системного тома в ОС Windows Server 2008 и выше смещение первого раздела в конфигурации по умолчанию составляет 1024KB.
При форматировании дискового раздела NTFS желательно выбирать рекомендуемый размер кластера в 64KB (по умолчанию используется размер в 4KB).

При проверке смещения разделов, на которых планируется размещение файлов БД, можно руководствоваться правилом:

Размер смещения Partition Offset в байтах, делённый на размер кластера, которым отформатирован раздел (Allocation unit size или Bytes Per Cluster) в байтах = любое целое число.

В случае, если в результате деления получается дробное число, считается, что выравнивание диска выполнено неправильно.

Чтобы проверить смещение разделов, на которых планируется расположить файлы БД, можно воспользоваться утилитой diskpart, введя примерно следующую последовательность команд:

В нашем примере диск Disk 2 является кластерным GPT-диском, на котором разделы Partition 1 и Partition 3 являются скрытыми служебными разделами. Раздел Partition 2 является тем видимым в оснастке Disk Management разделом, который был нами создан под файлы БД SQL Server. Его смещение мы и будем проверять.

Смещение раздела Partition 2 имеет значение 135266304 байт (129MB), а сам раздел при этом отформатирован кластерами по 65536 байт (64KB). Проверяем: 135266304/65536 = 2064. Мы получили целое число, то есть в нашем случае смещение раздела сделано правильно и выравнивание раздела не требуется.

В разных источниках можно встретить рекомендацию проверять смещение разделов с помощью команды типа:

Такая информация может внести некоторую сумятицу, поэтому для более внятного определения смещения раздела лучше использовать утилиту diskpart.

Что же касается размера кластеров, которыми должен быть отформатирован NTFS раздел (Allocation unit size или Bytes Per Cluster) под файлы БД SQL Server, то его можно определить на этапе форматирования раздела.

Без явного указания размера кластера, если выбрано значение Default, раздел форматируется более мелкими 4KB кластерами. Проверить размер кластера уже отформатировано ранее раздела можно с помощью утилиты fsutil

В нашем примере видно, что диск отформатирован кластерами по 64KB.

Для систем на базе Windows Server 2003 пример создания раздела со смещением в 1024KB на MBR-диске и форматирования этого раздела в NFTS с размером кластера 64KB может выглядеть следующим образом:

Дополнительные источники информации:

Проверено на следующих конфигурациях:

Версия ОС
Microsoft Windows Server 2012 R2 Standard EN (6.3.9600)

Автор первичной редакции:
Алексей Максимов
Время публикации: 10.02.2019 17:30

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

В зависимости от количества пользователей, размера баз данных и ограничений бюджета (с учетом стоимости дополнительных лицензий на сервер «1С:Предприятие 8» и лицензий на СУБД) платформа «1С» может работать в файловом и клиент-серверном вариантах (на основе трехуровневой архитектуры «клиент-сервер» (рис. 1): клиентское приложение, кластер серверов «1С:Предприятия 8», СУБД).

Рис. 1

Как правильно выбрать вариант/режим работы 1С: файловый или SQL?

Обычно для 1-10 пользователей выбирается файловый режим

От 10 и более пользователей выбирается режим работы с использованием SQL

В файловом варианте все пользователи могут работать на одной виртуальной машине в облаке, например на терминальном сервере.

Для клиент-серверного варианта лучше выбрать не менее двух виртуальных машин:

Сервер с клиентским приложением, например терминальный сервер с клиентской частью «1С» (толстый клиент)

Сервер «1С» и СУБД (MS SQL или PostgreSQL)

Как рассчитать мощности сервера для 1С в файловом режиме работы?

В обоих вариантах: файловом и SQL, для работы с пользовательским приложением 1С в классическом режиме, например, «удаленного рабочего стола» (так называемый «толстый клиент»), необходимы следующие минимальные ресурсы виртуального сервера:

Количество виртуальных ядер CPU = 1 или 2 для ОС + 0,25 * количество пользователей

Объем памяти RAM = 1 или 2 ГБ для ОС + 0,5 ГБ * количество пользователей

Размер диска/хранилища HDD = 20-40 ГБ для ОС и приложений + (0,1-10) ГБ * количество пользователей. Для ОС и 1С рекомендуется использовать самые быстрые диски

Как рассчитать мощности сервера для 1С в варианте работы с SQL?

В клиент-серверном варианте работы 1С, в котором используется СУБД SQL, рекомендуется разместить 1С Сервер и сервер SQL на отдельном виртуальном сервере в общей с клиентским сервером локальной подсети. Необходимы следующие минимальные мощности для этого виртуального сервера:

Размер диска/хранилища HDD = 20-40 ГБ для ОС и приложений + (10-1000) ГБ в зависимости от объема и количества баз данных. Для ОС и СУБД рекомендуется использовать самые быстрые диски
------------
ОС - операционная система, например, Windows Server
Здесь Сервер 1С - ПО "сервер "1С:Предприятия 8"

Наиболее важными и непростыми задачами являются повышение продуктивности использования платформы «1С» в облаке и настройка СУБД. Типичные проблемы при развертывании и эксплуатации облачной инфраструктуры для «1С» следующие:

Неправильный выбор мощностей

Неквалифицированная настройка сервисов виртуальной инфраструктуры

Недостаточное внимание к тестированию производительности платформы «1С»

Для достижения максимальной производительности рекомендуется проверить и выполнить ряд настроек. Прежде всего необходимо исключить свопинг, для чего с помощью системы мониторинга следует обязательно удостовериться в том, что объем оперативной памяти достаточен для работы ВМ. Кроме того, файл подкачки ОС, профили пользователей, файлы баз данных, файлы логов транзакций (SQL) и tempDB (SQL) лучше разместить на дополнительных SSD-дисках, а для файла подкачки установить фиксированный размер.

На SQL-сервере необходимо выключить все ненужные службы, например FullText Search и Integration Services, установить максимально возможный объем оперативной памяти, максимальное количество потоков (Maximum Worker Threads) и повышенный приоритет сервера (Boost Priority), задать ежедневную дефрагментацию индексов и обновление статистики, настроить автоматическое увеличение файла базы данных (не менее 200 Мбайт) и файла лога (не менее 50 Мбайт), а также полную реиндексацию не реже одного раза в неделю. При размещении серверов SQL и «1С:Предприятие» на одной ВМ следует включить протокол Shared Memory.

Следуя перечисленным выше рекомендациям, можно добиться увеличения быстродействия платформы «1С» в облаке в 1,5–2 раза.

Квалифицированное размещение ИТ-сервисов, в том числе «1С», на облачной платформе позволяет:

Существенно сократить расходы

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

Обеспечить централизованное администрирование и мониторинг

Организовать эффективную и безопасную удаленную работу

Воспользоваться гибкими возможностями масштабирования, лицензирования и оперативного перехода на необходимые версии конфигураций «1С»

ЧЕК-ЛИСТ ПО ОПТИМИЗАЦИИ ИНФРАСТРУКТУРЫ 1С С MS SQL

1. Включить возможность мгновенной инициализации файлов (Database instant file initialization)

Это позволяет ускорить работу таких операций как:

Создание базы данных

Добавление файлов, журналов или данных в существующую базу данных

Увеличение размера существующего файла (включая операции автоувеличения)

Восстановление базы данных или файловой группы

Для включения настройки:

На компьютере, где будет создан файл резервной копии, откройте приложение Local Security Policy (secpol.msc)

Разверните на левой панели узел Локальные политики, а затем кликните пункт Назначение прав пользователей

На правой панели дважды кликните Выполнение задач по обслуживанию томов

2. Включить параметр «Блокировка страниц в памяти» (Lock pages in memory)

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

Для включения настройки:

В меню Пуск выберите команду Выполнить. В поле Открыть введите gpedit.msc

В консоли Редактор локальных групповых политик разверните узел Конфигурация компьютера, затем узел Конфигурация Windows

Разверните узлы Настройки безопасности и Локальные политики

Выберите папку Назначение прав пользователя

Политики будут показаны на панели подробностей

На этой панели дважды кликните параметр Блокировка страниц в памяти

В диалоговом окне Параметр локальной безопасности — блокировка страниц в памяти выберите «Добавить» пользователя или группу

В диалоговом окне Выбор: пользователи, учетные записи служб или группы добавьте ту учетную запись, под которой у вас запускается служба MS SQL Server

Чтобы изменения вступили в силу, перезагрузите сервер или зайдите под тем пользователем, под которым у вас запускается MS SQL Server

3. Включить каталоги с файлами базы данных в правила исключения для антивируса.

Если антивирус будет сканировать файлы базы, это может сильно замедлить работу СУБД.

Для опытных администраторов: антивирус на сервер СУБД лучше не устанавливать.

4. Включить каталоги с файлами базы данных в список исключений для системы автоматического копирования.

Если на сервере установлена система автоматического копирования файлов, то, когда она будет копировать файлы базы, это может привести к замедлению работы. Копии базы необходимо делать средствами самой СУБД.

5. Отключить механизм DFSS для дисков.

Механизм Dynamic Fair Share Scheduling отвечает за балансировку и распределение аппаратных ресурсов между пользователями. Иногда его работа может негативно сказываться на производительности 1С.

Чтобы отключить его только для дисков, нужно:

Найти в реестре ветку HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\TSFairShare\Disk

Установить значение параметра EnableFairShare в 0

6. Отключить сжатие данных для каталогов, в которых лежат файлы базы.

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

Чтобы отключить сжатие файлов в каталоге, необходимо:

Открыть свойства каталога

На закладке Общие нажать кнопку Другие

Снять флаг «Сжимать» содержимое для экономии места на диске

7. Установить параметр «Максимальная степень параллелизма» (Max degree of parallelism) в значение 1.

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

Для настройки параметра необходимо:

Запустить Management Studio и подключиться к нужному серверу

Открыть свойства сервера и выбрать закладку Дополнительно

Установить значение параметра равное единице

8. Ограничить максимальный объем памяти сервера MS SQL Server.

Необходимо ограничить максимальный объем памяти, потребляемый MS SQL Server, особенно это критично, если роли сервера 1С и сервера СУБД совмещены. Максимальный объем памяти, рекомендуемый для MS SQL Server, можно рассчитать по следующей формуле:

Память для MS SQL Server = Память всего – Память для ОС – Память для сервера 1С

Например, на сервере установлено 64 ГБ оперативной памяти, необходимо понять, сколько памяти выделить серверу СУБД, чтобы хватило серверу 1С.

Для нормальной работы ОС в большинстве случаев более чем достаточно 4 ГБ, обычно – 2-3 ГБ.

Чтобы определить, сколько памяти требуется серверу 1С, необходимо посмотреть, сколько памяти занимают процессы кластера серверов в разгар рабочего дня. Этими процессами являются ragent, rmngr и rphost, подробно данные процессы рассматриваются в разделе, который посвящен кластеру серверов. Снимать данные нужно именно в период пиковой рабочей активности, когда в базе работает максимальное количество пользователей. Получив эти данные, необходимо прибавить к ним 1 ГБ – на случай запуска в 1С «тяжелых» операций.

Чтобы установить максимальный объем памяти, используемый MS SQL Server, необходимо:

Запустить Management Studio и подключиться к нужному серверу

Открыть свойства сервера и выбрать закладку Память

Указать значение параметра Максимальный размер памяти сервера

9. Включить флаг «Поддерживать» приоритет SQL Server (Boost SQL Server priority).

Данный флаг позволяет повысить приоритет процесса MS SQL Server над другими процессами.

Имеет смысл включать флаг только в том случае, если на компьютере с сервером СУБД не установлен сервер 1С.

Для установки флага необходимо:

Запустить Management Studio и подключиться к нужному серверу

Открыть свойства сервера и выбрать закладку Процессоры

Включить флаг «Поддерживать приоритет SQL Server (Boost SQL Server priority)» и нажать Ок

10. Установить размер авто увеличения файлов базы данных.

Автоувеличение позволяет указать величину, на которую будет увеличен размер файла базы данных, когда он будет заполнен. Если поставить слишком маленький размер авторасширения, тогда файл будет слишком часто расширяться, на что будет уходить время. Рекомендуется установить значение от 512 МБ до 5 ГБ.

Для установки размера авторасширения необходимо:

Запустить Management Studio и подключиться к нужному серверу

Открыть свойства нужной базы и выбрать закладку Файлы

Напротив каждого файла в колонке Автоувеличение поставить необходимое значение

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

11. Разнести файлы данных mdf и файлы логов ldf на разные физические диски.

В этом случае работа с файлами может идти не последовательно, а практически параллельно, что повышает скорость работы дисковых операций. Лучше всего для этих целей подходят диски SSD.

Для переноса файлов необходимо:

Запустить Management Studio и подключиться к нужному серверу

Открыть свойства нужной базы и выбрать закладку Файлы

Запомнить имена и расположение файлов

Отсоединить базу, выбрав через контекстное меню Задачи – Отсоединить

Поставить флаг Удалить соединения и нажать Ок

Открыть Проводник и переместить файл данных и файл журнала на нужные носители

В Management Studio открыть контекстное меню сервера и выбрать пункт Присоединить базу

Нажать кнопку Добавить и указать файл mdf с нового диска

В нижнем окне сведения о базе данных в строке с файлом лога нужно указать новый путь к файлу журнала транзакций и нажать Ок

12. Вынести файлы базы TempDB на отдельный диск.

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

Рекомендуется хранить базу TempDB на отдельном диске для повышения производительности работы системы.

Для переноса базы TempDB на отдельный диск необходимо:

Запустить Management Studio и подключиться к нужному серверу

Создать окно запроса и выполнить скрипт:

ALTER DATABASE tempdb

MODIFY FILE (NAME = tempdev, FILENAME = 'Новый_Диск:\Новый_Каталог\tempdb.mdf')

ALTER DATABASE tempdb

MODIFY FILE (NAME = templog, FILENAME = 'Новый_Диск:\Новый_Каталог\templog.ldf')

Перезапустить MS SQL Server

13. Включить Shared Memory, если сервер 1С расположен на том же компьютере, что и сервер СУБД.

Протокол Shared Memory позволит общаться приложениям через оперативную память, а не через протокол TCP/IP.

Для включения Shared Memory необходимо:

Запустить диспетчер конфигурации SQL Server

Зайти в пункт SQL Native Client – Клиентские протоколы – Общая память – Включено

Поставить значение Да и нажать Ок

Протокол Именованные каналы нужно выключить аналогичным образом

14. Перезапустить службу MS SQL Server

Внимание! Когда все настройки выполнены, необходимо перезапустить службу MS SQL Server

Читайте также: