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

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

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

Рис. 1
Рис. 1

Как правильно выбрать вариант/режим работы 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 и подключиться к нужному серверу

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

USE master

GO

ALTER DATABASE tempdb

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

GO

ALTER DATABASE tempdb

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

GO

  • Перезапустить 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

Комментарии 34

    0
    1. Разнести файлы данных mdf и файлы логов ldf на разные физические диски.
      В этом случае работа с файлами может идти не последовательно, а практически параллельно

    Простите, что?

      0

      Тут речь немного о другом. При коммите транзакции sql server обязан сначала записать данные в файл журнала транзакций (без кеширования/буферизации), а только потом в mdf файл (при этом допустимо кэширование, тк в файл журнала данные уже записаны и по журналу можно "дозавершить" транзакцию в случае внезапного отключения питания, например если mdf окажется "недозаписанным"). Когда файл журнала находится на отдельном диске, запись в него может пройти быстрее, тк отложенная запись в mdf от других транзакций не влияет на очередь того диска, на котором находится ldf

        –1

        Чем вызван сам совет, я знаю. Но то, как это мотивирует автор, вызывает сомнения в том, насколько он понимает, о чём пишет.


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

          +1
          В огороде бузина, а в Киеве дядька.

          Да, транзакции сначала пишутся в файл транзакций. Только не при коммите, а именно в процессе обработки транзакции. Собственно, любое действие над БД начинается в памяти (в буфере), и потом фиксируется в файле транзакций, тем самым освобождая буфер.
          Но сам процесс обработки каждой транзакции может быть очень длительным, к тому же одноврменно могут обрабатываться не одна, а несколько транзакций. Так что до момента коммита (или роллбэка) в файл транзакций может быть записано довольно много записей.
          Кстати, с точки зрения механизмов СУБД сам коммит (или роллбэк) транзакции ничего особенного не делает — только снимает блокировки (а вот на чтение-запись не влияет никак).

          А для файлов данных гораздо важнее скорость их считывания — но никак не записи. Их запись, вообще-то, асинхронно происходит. Планово. И довольно редко. Так что на скорость работы СУБД практически не влияет.
            –1

            Насчет того, что изменения фиксируются в журнале еще до коммита транзакций, да Вы правы. Я очень коряво сформулировал. Насчет того, что запись в базу манее важна чем скорость чтения — это очень спорное утверждение, т.к. зависит от типа нагрузки на базу (OLAP/OLTP). Если в нашей OLTP-системе десятки тысяч меняющих запросов в секунду, в т.ч. массовых, затрагивающих не одну строчку и не одну таблицу, я не могу сказать, что скорость записи нам менее важна чем чтения )

        0
        Если человек не дочитает статью до пункта 9, то начальное упоминание про priority boost подталкивает на бездумное включение может подпортить жизнь.
          0

          Boost priority вообще не нужно использовать после 2008й версии sql server. Эта опция deprecated и оставлена только для обратной совместимости при апгрейде на более свежие версии. Сам Майкрософт так говорит.

          +1
          Вспоминается…
          Не учи физику в школе и твой мир всегда будет наполнен чудесами.
          Статья неплохая, если поменять название. На чек-лист она не тянет.
          Есть официальный чек-лист от 1С и он в 99% случаев работает
          Check-list по настройке рабочих серверов в продукционной зоне
            0

            Выдача привилегии на Lock pages in memory может привести к тому, что в один прекрасный момент на сервере закончится память, а через диспетчер задач или другие инструменты мониторинга ресурсов вы даже не сможете понять, куда она делась. Только через Rammap можно будет что-то выяснить. Но далеко не все администраторы Windows про него знают и умеют пользоваться.
            Поэтому я бы посоветовал обязательно документировать использование этого механизма.

              +2
              Статьи по 1С всегда холиварны, «всегда найдется китаец это делает лучше тебя» :)

              Кроме того, файл подкачки ОС, профили пользователей, файлы баз данных, файлы логов транзакций (SQL) и tempDB (SQL) лучше разместить на дополнительных SSD-дисках
              Статья про чеклист для облаков. Если вы думаете что взяв в личном кабинете два «ssd» диска вы получите два физически разных ssd диска в своей виртуальной машине, то у меня для вас грустные новости, ибо все будет лежать на одной и той же СХД. Иначе это не облако, а дедикейтед сервер.

              а для файла подкачки установить фиксированный размер
              просто укажите стартовый размер в 512 мегабайт, а потолок равный двум объемам оперативной памяти. Если файл подкачки в процессе работы начинает расти, то по его размеру будет даже понятно какой недостаток памяти. В идеале он не должен начать расти.

              ежедневную дефрагментацию индексов
              Используйте официальную терминологию: перестроить и/или реорганизовать. Отсебятина вредна.

              а также полную реиндексацию не реже одного раза в неделю
              Начиная с 2016 SQL Server можно задать в плане обслуживания при каком проценте изменения индекса выполнять процедуры перестроения и реорганизации индекса в рамках одного задания. Скажем, если индекс протух на от 10 до 29% то делаем реорганизацию, если свыше 30% то перестроение. Если меньше 10 то вообще не трогаем. Очень удобно тем что процессы происходят по мере необходимости. Если база почти не изменяется, то смысл её ежедневно гонять из-за индексов, и полностью перечитывать на выходных?

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

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

              11. Разнести файлы данных mdf и файлы логов ldf на разные физические диски.
              Статья про облако. Что за чушь то :)

              А еще в чеклисте не слова про настройку журнала операций 1С, при активной работе они принесут вам много сюрпризов.

              А еще нет описания как пробросить физические ключи с площадки в облако.
                0
                А еще в чеклисте не слова про настройку журнала операций 1С, при активной работе они принесут вам много сюрпризов.

                И про настройку программистов 1С, вот где поле непаханое-то для оптимизации. :)

                  0

                  Два диска будут лежать где угодно, но вот что ОС и ПО ВМ их будет считать разными — уже хорошо.


                  Потому что ОС, получив инструкции от ПО, может на одном диске включить кеширование, на другом — отключить (это как пример), и чем уламывать её кеш включать, проще два или более диска ей организовать. Тем более что в облаке мы платим только за место, но не за кол-во дисков.


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

                    0
                    у СУБД данные могут быть в памяти, но еще не оказаться корректно записанными на диск,

                    Ну, за все СУБД не скажу — а у MS SQL такое невозможно.

                    Первое действие, которое выполняется при изменении данных в базе — это запись в файл транзакций. Собственно, «метки оси времени» в этой СУБД учитываются в форме LSN (Log Sequence Number, номер записи в файле транзакций).
                    Это сделано специально: даже если «всё крахнет», данных с диска будет достаточно для корректного возобновления работы БД.
                      0

                      Даже запись в файл, если это не CoW, с его накладными расходами, может закончиться «ни там, ни здесь», и файл станет поврежденным/нечитаемым. И это ахилесова пята любого работающего с диском процесса (и если не сталкивались, то это, как говорится, просто везло). Так что лучше подумать о таковом заранее.


                      Ну и наоборот, не зря агенты систем виртуализации делаются же? Тем более что коммерческие СУБД они точно умеют готовить к бекапу.


                      (Вот с Postgresql чуть сложнее, но и там сходный подход. Зато производительность у PostgresPro Enterprise 1c на том же железе, как утверждается, выжимает большую производительность для 1с, так что есть смысл подразобраться)

                    0
                    про настройку журнала операций 1С

                    Что вы имеете в виду под «журналом операций 1С»?
                      0
                      моя неточность, каюсь.

                      Администрирование — Поддержка и обслуживание — Журнал регистрации

                      Все то, что по умолчанию лежит в
                      C:\Program Files\1cv8\srvinfo\reg_1541\[GUID]
                        0
                        Ок, ясно.
                    0
                    Если честно я ожидал в статье про 1С в облаках описание решения, когда реализуется виртуалка с сервером 1С, а база лежит в каком нить DBaaS.
                      0
                      Спасибо за хорошую идею. Постараюсь написать в ближайшее время. У меня собирается материал по использованию Postgres Pro с 1С.
                      Интересна эта тема?
                      Сравнение с MS SQL, режимы использования и настройка, использование в режимах выделенной инсталляции (dedicated/хостинг) и PaaS?
                      + / -?
                      Экономика?
                      Что из этого больше интересует?
                        +1
                        Начните с банального. Вот как ставить 1С и MSSQL на сервер мы все знаем.
                        А как мне поставить 1С и подключить к облачной базе данных? А на примере отечественных провайдеров? Каковы затраты, на что обращать внимание? Как экономить на таких серверах?
                          0
                          Еще раз спасибо за идеи, постараюсь сделать в ближайшее время. Смерть выходным :)
                            0

                            Если 1с у тебя онпрем, а база в облаке, то с получившимся латенси на ввод-вывод оно всё будет тааааак тормозить.

                              0
                              Дык разговор то про 1С сервер в облаке и инстанс дб тоже в том же облаке. А до 1С rdp или веб у клиентов.
                        0
                        Перепечатка документации от фирмы 1с. Таким на инфостарте баловались. Теперь и тут?
                          0

                          "Максимальная степень параллизма установить в 1".
                          Представьте что у вас сервер mssql 24 или больше ядер и всё это добро простаивает.


                          Так делать не надо. Поменяйте дефолтную стоимость запроса для его распараллеливания mssql с 5 до 50.
                          Называется "max degree of parallelism" (максимальный градус параллелизма).


                          Его дефолтное значение не менялось с 2000 или 2005 mssql. Сейчас в среднем раз в 10 больше будет вполне нормальным для erp и зуп.


                          (Если где то ошибся в цифрах поправьте меня, нет под рукой mssql)

                            0
                            Случайно продублировал название того же параметра.
                            Правильно: «Стоимостной порог для параллелизма». Его нужно менять, а «Максимальная степень параллизма» ни в коем случае не надо делать в 1. Только обдуманно.
                            (Хабр не дал исправить коммент, поэтому исправляюсь во втором)
                            0

                            О, уже вроде как технические специалисты любую сеть называют "облачком"? Как мы до этого дошли?

                              0
                              А какие облачка существуют? Публичные, частные, домашние...? Да, этим термином многие «накрывают» целые инфраструктуры, корпоративную виртуализацию с сервисами vCloud Director или аналогичными, а некоторые даже свою «домашнюю» платформу, например, типа NextCloud :)
                              Что для Вас облако?
                              0

                              После тестов Гилева дальше читать не стал. Тест — раскрученный бренд, не более того. Код можно посмотреть, хоть он и закрыт, он поражает своей ненаправленностью, простотой и бестолковостью. Не верите и не хотите вскрывать код — сравните файловый режим и серверный на одном и том же железе. Получаем, что файловая работает в два раза быстрее! Проверка ожидания блокировок — нет, загрузка железа сервера 1с — нет, загрузка железа субд — нет, анализ задержек сети — нет.

                                0
                                Спасибо за Ваш комментарий. Действительно, тест достаточно упрощенный. Это знают все «1С-ники»: «тест в попугаях, служит для относительной оценки, например, поменял диски или настройки железа сервака и посмотрел, как это повлияло на производительность...».
                                Да, все так, как Вы пишете Но для упрощенных оценок вполне годится. Для инженерных оценок и сложных решений существуют другие инструменты. Они тоже упомянуты. Видели? Как они Вам? Удобно пользоваться? Легко развернуть и настроить? :)
                                Профи пишут собственные обработки (если не в курсе, так называются прикладные решения на платформе 1С, которые могут выполняться в большинстве конфигураций 1С, подробней: v8.1c.ru/platforma/obrabotka или здесь v8.1c.ru/platforma/vneshnie-obrabotki). Эти обработки имитируют реальные нагрузки, которые дают результаты тестирования с более высокой степенью достоверности и в контексте конкретной задачи.
                                Но, к сожалению, 90% «леди 1С» измеряют тестами Гилева все подряд, а потом утверждают, что размер имеет значение :) Мне было важно, чтобы «публика» задумалась и начала обсуждать эти и подобные проблемы, так как в современной ИТ-галактике нет абсолютно правильных решений, и истина рождается именно в таких обсуждениях)
                                0
                                пункт 3. встроенный в винду тоже отключать? в частности тот, который видит воздействие приложений на файлы.
                                вот нам последний раз червяк зашифровал все базы (файлы) и денег попросил.
                                а если бы он был включен — проблемы бы не было.
                                  0
                                  Никого не хочу обидеть, но написано «для опытных админов» :)
                                  Здесь на хабре такие решения подробно разбирались. А также + / — такого подхода. Конечно, несколько контуров защиты всегда есть, как и регулярные бэкапы 3-2-1. Рекомендую делать бэкапы на инфраструктурном уровне, в СУБД и на уровне приложения (сама 1С умеет делать, включая регулярную выгрузку конфигурации — особенно ценно для «отката»/rollback, когда неосторожные разработчики что-то натворят или просто тестируют новую версию в продуктиве, но надо подстраховаться). Периодическая выгрузка-загрузка конфигурации также помогает решить еще несколько относительно полезных задач.
                                  Советую прочитать
                                  infostart.ru/public/1119557
                                  www.1cbit.ru/blog/uskorenie-i-optimizatsiya-1s-kak-uskorit-rabotu-1s
                                  а также
                                  habr.com/ru/post/535662
                                    0

                                    Не хочу обидеть, но это был сарказм.
                                    На фоне всей статьи, этот пункт — это как: отрежьте заключенному ноги, тогда он точно не убежит. А как же в туалет ходить? Будем носить его на руках, катать на каталке, приносить к нему утку.


                                    У нас проблема была в потерянном времени, а мой вопрос: как обезопасить систему, на которой стоит mssql, а не базы, которые в нем. Ваш совет — отключить антивирус и делать бекапы (которые червь кстати также без проблем зашифрует, к примеру, если они были на подключённой шаре). И вот не надо про одностороннюю запись, про шифрование копий и прочее.

                                      0
                                      Давайте попробую ответить еще более доброжелательно, так как Вы же потратили время на чтение и коммент к этой странной статье?:) Как и чем защищать, Вы лучше меня знаете. Но мне показалось, что что-то Вам таки было важно найти, но, вероятно, не нашли в этом опусе?
                                      Вот теперь по возможности доброжелательно :) напишите, пожалуйста, что Вы хотели узнать, что интересует? Что надо решить, стоят задачи?

                                Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                                Самое читаемое