Как ускорить ms sql 2019 для 1с

Чек-лист по настройке инфраструктуры для повышения скорости работы 1С с MS SQL (особенно важно в облаках)

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

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

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

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

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

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

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

• Сервер с клиентским приложением, например терминальный сервер с клиентской частью «1С» (толстый клиент)
• Сервер «1С» и СУБД (MS SQL или PostgreSQL)

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

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

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

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

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

1. Количество виртуальных ядер CPU = 1 или 2 для ОС + (2-4) для Cервера 1С + (2-8-16…) для СУБД SQL в зависимости от объема и количества баз данных
2. Объем памяти RAM = 1 или 2 ГБ для ОС + (2-4) ГБ для Cервера 1С + (2-4-8-16-32…) ГБ для СУБД SQL в зависимости от объема и количества баз данных
3. Размер диска/хранилища 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С:Корпоративный инструментальный пакет» (https://its.1c.ru/db/kip или http://v8.1c.ru/expert/etp.htm).

С помощью тестов Гилева можно быстро и достаточно легко понять, насколько эффективно работает платформа «1С», как влияют на ее производительность те или иные настройки, а также найти и устранить узкие места инфраструктуры. Для более детального анализа нагрузки и поиска узких мест рекомендуется использовать утилиту Process Explorer Марка Русиновича (https://technet.microsoft.com/en-us/sysinternals/processexplorer).

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

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

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

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

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

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

• Создание базы данных
• Добавление файлов, журналов или данных в существующую базу данных
• Увеличение размера существующего файла (включая операции автоувеличения)
• Восстановление базы данных или файловой группы

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

• На компьютере, где будет создан файл резервной копии, откройте приложение Local Security Policy (secpol.msc)
• Разверните на левой панели узел Локальные политики, а затем кликните пункт Назначение прав пользователей
• На правой панели дважды кликните Выполнение задач по обслуживанию томов
• Нажмите кнопку «Добавить» пользователя или группу и добавьте сюда пользователя, под которым запущен сервер MS SQL Server
• Нажмите кнопку Применить

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

• 1С
• MS SQL Системное администрирование
• MS SQL
• системное администрирование
• Настройка 1С
• Повышение производительности 1С
• 1С в облаке

Настройка MSSQL для работы с 1С — мифы и реальность

Оптимизируем Microsoft SQL Server 2014 для работы с 1С. ОС — Windows Server 2012 R2. Напишу что нужно сделать, а что не нужно.

Определяю мифичность очень просто, если мне пришлось применить настройку — реальность, не пришлось — миф.

Устанавливаем последний Service Pack и Cumulative Update — реальность

На текущий момент нужно обновиться до SP3.

Обязательно нужно сделать.

Выравнивание разделов — миф

Рекомендуют выравнивать сектора дисков по границе 1024Кб. Не заморачивайтесь, эта рекомендация устарела. Операционная система теперь сама выравнивает раздел как нужно для дисков более 4 ГБ.

Эту настройку не применяем.

Форматирование с размером блока 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 года:

Здесь аргументированно с указанием конкретного железа, на котором производились испытания, пишут:

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

Однако, у меня там уже прописана группа 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

Видим, что политика не настроена. Можно добавить сюда пользователя, от имени которого работает 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. И зеркалироваться.

Эту настройку не применяем.

Резервирование и обслуживание — реальность

Эту настройку применяем.

Настройка памяти — реальность

Да, память для MSSQL нужно настраивать. По умолчанию сиквел жрёт всё что может, системе начинает не хватать. Как итог — тормоза. Нужно выделить SQL серверу строго определённое количество памяти и пусть не рыпается.

Не держите приложение 1С и SQL Server на одном сервере. MSSQL должен жить отдельно.

Это позволить избежать конкуренции за ресурсы.

Эту настройку применяем.

Настройка процессора — реальность

Эту настройку применяем.

Расположение файлов данных — реальность

Файлы данных и файлы журналов транзакций желательно размещать на разных дисковых массивах. Если один из массивов быстрее, то лог нужно разместить там.

Эту настройку по возможности применяем.

Разбить tempdb на несколько файлов по количеству процессоров — миф

Эту настройку не применяем.

Перенести tempdb в RAM — реальность

Сам протестировал, добился 10-кратного прироста скорости чтения-запись для tempdb.

Эту настройку по возможности применяем.

Установить параметр 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? Отключать нечего.

Эту настройку не применяем.

Как настроить параметры MS SQL Server, чтобы ускорить работу системы – 7 настроек за 43 минуты!

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

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

Итак, серия видео, в которых мы рассмотрим основные настройки MS SQL.

Расскажем, какие именно параметры имеет смысл настроить в первую очередь, какие значения им проставить и как это повлияет на общую производительность.

Видео 1: Базовая настройка MS SQL Server

В этом видео разберем, что такое базовая настройка.

Shared Memory как способ ускорить работу 1С Предприятия!

Shared Memory как способ ускорить работу 1С Предприятия!

Один из самых простых и быстрых способов ускорить 1С в ее клиент-серверном варианте работы, есть протокол Shared memory!

Если в цифрах то, проведя простые манипуляции можно ускорить 1С Предприятие

на 10 – 15 процентов!

Конечно, данная тема также подымается и на курсе: Администратор 1С!

И так что нужно для успешной реализации:

1. 1С Предприятие выше 8.2.17
2. «Сервер 1С» и MS SQL находятся на одном «хосте» (один ПК или Сервер)
3. Подключение «Сервера 1С» c СУБД установлено через имя хоста (Не IP)!

В чем суть ?

Известно, что «Сервер 1С» и СУБД MS SQL «общаются между собой» обычно по протоколу TCP/IP, что конечно хорошо когда «Сервер 1С» и СУБД находятся на разных серверах, а вот если они вместе на одном сервере, тогда есть смысл организовать их работу через протокол Shared memory!

Работая с «Общей памятью» Shared Memory мы ускорим тем самым их «общение» на 10-15% процентов, как заявляет сама фирма 1С.

Что пишет WIKI о Shared Memory…

Разделяемая память (англ. Shared memory) является самым быстрым средством обмена данными между процессами[1].

В других средствах межпроцессового взаимодействия (IPC) обмен информацией между процессами проходит через ядро, что приводит к переключению контекста между процессом и ядром, т.е. к потерям производительности[2].

Техника разделяемой памяти позволяет осуществлять обмен информацией через общий для процессов сегмент памяти без использования системных вызовов ядра. Сегмент разделяемой памяти подключается в свободную часть виртуального адресного пространства процесса[3]. Таким образом, два разных процесса могут иметь разные адреса одной и той же ячейки подключенной разделяемой памяти.

Процесс перехода на Shared Memory:

Сперва проверяем текущие соединения MS SQL и «Сервера 1С»

Вдруг уже работаем по Shared Memory! )

Выполним вот такой не сложный запрос: