Ошибка при загрузке данных превышен максимальный расход памяти сервера за один вызов
Как я уже писал предыдущей статье Настройка кластера 1С 8.3 (ч. 1) , в кластере 1С Предприятие 8.3 значительно расширились настройки для оптимизации производительности.
При этом, важно отметить, что за счет большого количества параметров, которые за частую в 95% ситуаций не используются, настройка стала и сложнее.
Этап II. Настройка счетчиков производительности.
Создаем новый набор счетчиков.
Идём в контрольную панель и вызываем «Administrative Tools» (Control Panel\All Control Panel Items\Administrative Tools)
Открываем «Performance Monitor» и в раздел «User Defined» добавляем новую коллекцию счетчиков:
Выбираем «Create manually (Advanced)»:
Указываем, что мы хотим логировать именно счетчики производительности:
На следующем экране представлены все возможные счетчики. Для примера возьмем один:
В разделе «Processor» есть счетчик «% Processor time». В нижнем списке уточняем, какое ядро хотим мониторить. Для примера выбираем «Total» и нажимаем «Add». Это позволит отслеживать в процентах общую нагрузку по всем ядрам.
Указываем интервал сбора данных. Выбираем, к примеру, 15 секунд.
Далее без изменений, поэтому можно сразу жать "финиш". В итоге получаем набор счетчиков, но он пока не запущен, и запускать его пока что рано.
Перенастраиваем набор на БД MS SQL
Заходим в DataCollector01 и перевыбираем параметр Log format с Binary на SQL
Далее в параметре «Data source name» выбираем созданный в первом разделе провайдер
Идём в настройки New Data Collector Set. На закладке «Schedule» добавляем задание по старту счетчиков на ежедневной основе.
На закладке «Stop Condition» выставляем условия окончания сбора счетчиков. Я выбрал в качестве ограничения размер БД в 10 Гб.
Сохраняем и з апускаем счетчики
Проверяем, что данные начали собираться в БД MS SQL:
Вопрос №1
Добрый день! Вопрос по защищенному соединению. Не ясно отличие значений «выключено» и «только соединение».
В видео-уроке сказано, что при варианте «выключено» производится шифрование пароля при первом обмене. Разве пароль передаётся не только при первом обмене, при аутентификации? Кстати, шифруется только пароль или имя тоже?
Ответ
- При установленном значении “выключено” после установки соединения первая передача пароля выполняется с использованием шифрования по алгоритму RSA. Дальнейший обмен выполняется нешифрованными данными
- При установленном значении “только соединение” – обеспечивается шифрование обмена паролями всегда, но данные передаются в открытом виде
- При установленном значении “постоянно” – обеспечивается шифрование как паролей, так и данных. Для чего используются алгоритмы RSA (несимметричное шифрование с открытым (публичным) и закрытым ключом) и Triple DES (тройное шифрование симметричным алгоритмом DES).
Третий режим самый защищенный, но может серьезно нагружать сервер. В двух первых режимах шифруется только пароль.
Требования и назначения функциональности
Имеет смысл только если в кластере более 1 сервера. Дает возможность назначить конкретный сервис на конкретный сервер. После установки 1С , рекомендуется удалить локальный кластер (через панель администрирования), потому что он не используется.
Ниже рассмотрю ключевые сервисы, которые рекомендуется выделять.
Сервис лицензирования:
Целесообразно указать слабую машину или виртуальный сервер (предпочтительно, потому что легко перенести) с фиксированной аппаратной конфигурацией. Как следствие, не будет необходимости обновлять лицензию после каждого апгрейда конфигурации оборудования рабочих серверов.
Сервис заданий:
Дает возможность указать отдельный сервер для выполнения фоновых заданий. Таким образом снизить нагрузку на оперативную деятельность, а все расчеты вынести на фоновые задания на отдельную машину или виртуалку. Так же можно вынести выполнение фоновых заданий, например, на OS MS Windows, если требуется использование COM-объектов, таких как S Office или внешних компонент. При это большая часть кластера будет работать под Linux.
Сервис сеансовых данных / Сервис журналов регистрации / Сервис полнотекстового поиска:
Мы с Вами уже знаем, что самое важное для нас - это жесткий диск, потому что именно он зачастую является "бутылочным горлышком". Если перенести перечисленные сервисы на отдельный сервер с очень быстрым диском, то это значительно ускорит работу загруженного кластера.
С чего все началось. После перехода на версию платформы 8.3.18.1208 х64 и релиз ЗУП 3.1.17.135 перестали отправляться расчетные листки сотрудникам одним скопом (получателей 250+). А именно, начали ловить ошибку "Превышен максимальный расход памяти сервера за один вызов" (когда сеанс "отъедает" всю доступную серверу 1С оперативную память). В нашем случае, при отправке расчеток, формировалось фоновое задание, которое и расходовало всю доступную оперативную память. Обновление версии ЗУП до 3.1.17.138 и "танцы" с настройками сервера 1С не дали результата, отправился искать отладчиком "узкое" место встроенного языка, где происходит увеличение памяти.
На скрине представлен фрагмент типового кода конфигурации ЗУП 3.1.17.138 , логика приведенного цикла в формировании и сохранении результата отчета "Анализ начислений и удержаний" (расчетный листок) для каждого сотрудника.
Судить о том, что данный фрагмент является "узким" местом встроенного языка не берусь, но именно в этом месте, на каждой итерации цикла наблюдалось увеличение потребляемой оперативной памяти. И как следствие - появление ошибки указанной выше.
Решение. При рассылке отчетов типовым алгоритмом предусмотрено: формирование одного фонового задания, которое обеспечивает формирование и отправку результатов отчетов всем получателям. Так как памяти не хватает обрабатывать всех получателей за одно фоновое задание. Появилась идея формировать для каждого получателя отдельное фоновое задание (контролируя статус завершения фонового задания) и при этом минимально изменяя типовой алгоритм, в надежде, что когда нибудь это исправят. Результатом идеи и успешного решения поставленной задачи стало написанное расширение конфигурации. Логику и фрагменты которого распишу ниже.
Логика:
1. В имеющемся общем модуле перехватим типовую процедуру по формированию фонового задания для всего массива получателей и передадим в параметр создания фонового задания первый элемент массива получателей, затем сохраним исходный массив получателей и УИД задания во временном хранилище и хранилище общих настроек соответственно.
2. Далее подключим обработчик ожидания, который будет повторять создание фонового задания, пока массив получателей не будет пустым.
3. Организуем проверку статуса выполнения фонового задания. Если завершен, тогда удаляем из массива получателей первый элемент и вновь формируем фоновое задание, иначе отключаем обработчик ожидания.
В данном фрагменте типового общего модуля "РассылкаОтчетовКлиент" перехватим процедуру "ВыбратьПолучателяЗавершение". В которой "ВыполнитьОбработкуОповещения(ДополнительныеПараметры.ОбработчикРезультата, Результат)" дает условный старт формирования фонового задания, посему перед этой строкой мы сохраняем наш массив получателей во временное хранилище, а так же необходимые дополнительные параметры. (помещаем во временное хранилище обязательно с параметром "Новый УникальныйИдентификатор", чтобы наш массив получателей жил на протяжении всего сеанса пользователя).
Т.к. подключить обработчик ожидания мы не можем в текущем общем модуле, создадим и перейдем для этого в глобальный модуль "ОжиданиеОбработчика()". (подробнее в "Пример кода и описание пункта 2." ниже)
После выполнения "ВыполнитьОбработкуОповещения(ДополнительныеПараметры.ОбработчикРезультата, Результат)" и еще ряда процедур, исполнение кода переходит в процедуру "ВыполнитьСейчасВФоне", которую мы так же перехватим в расширении:
В данном фрагменте проверяем, что текущая рассылка у нас по расчетным листкам, затем после формирования фонового задания сохраняем его УИД в хранилище общих настроек.
Описанный выше код прописываем в заимствованном в расширении типовом общем модуле "РассылкаОтчетовКлиент".
Данный фрагмент кода используется, чтобы организовать повторение действий по созданию фонового задания для каждого получателя отдельно.
С чего все началось. После перехода на версию платформы 8.3.18.1208 х64 и релиз ЗУП 3.1.17.135 перестали отправляться расчетные листки сотрудникам одним скопом (получателей 250+). А именно, начали ловить ошибку "Превышен максимальный расход памяти сервера за один вызов" (когда сеанс "отъедает" всю доступную серверу 1С оперативную память). В нашем случае, при отправке расчеток, формировалось фоновое задание, которое и расходовало всю доступную оперативную память. Обновление версии ЗУП до 3.1.17.138 и "танцы" с настройками сервера 1С не дали результата, отправился искать отладчиком "узкое" место встроенного языка, где происходит увеличение памяти.
На скрине представлен фрагмент типового кода конфигурации ЗУП 3.1.17.138 , логика приведенного цикла в формировании и сохранении результата отчета "Анализ начислений и удержаний" (расчетный листок) для каждого сотрудника.
Судить о том, что данный фрагмент является "узким" местом встроенного языка не берусь, но именно в этом месте, на каждой итерации цикла наблюдалось увеличение потребляемой оперативной памяти. И как следствие - появление ошибки указанной выше.
Решение. При рассылке отчетов типовым алгоритмом предусмотрено: формирование одного фонового задания, которое обеспечивает формирование и отправку результатов отчетов всем получателям. Так как памяти не хватает обрабатывать всех получателей за одно фоновое задание. Появилась идея формировать для каждого получателя отдельное фоновое задание (контролируя статус завершения фонового задания) и при этом минимально изменяя типовой алгоритм, в надежде, что когда нибудь это исправят. Результатом идеи и успешного решения поставленной задачи стало написанное расширение конфигурации. Логику и фрагменты которого распишу ниже.
Логика:
1. В имеющемся общем модуле перехватим типовую процедуру по формированию фонового задания для всего массива получателей и передадим в параметр создания фонового задания первый элемент массива получателей, затем сохраним исходный массив получателей и УИД задания во временном хранилище и хранилище общих настроек соответственно.
2. Далее подключим обработчик ожидания, который будет повторять создание фонового задания, пока массив получателей не будет пустым.
3. Организуем проверку статуса выполнения фонового задания. Если завершен, тогда удаляем из массива получателей первый элемент и вновь формируем фоновое задание, иначе отключаем обработчик ожидания.
В данном фрагменте типового общего модуля "РассылкаОтчетовКлиент" перехватим процедуру "ВыбратьПолучателяЗавершение". В которой "ВыполнитьОбработкуОповещения(ДополнительныеПараметры.ОбработчикРезультата, Результат)" дает условный старт формирования фонового задания, посему перед этой строкой мы сохраняем наш массив получателей во временное хранилище, а так же необходимые дополнительные параметры. (помещаем во временное хранилище обязательно с параметром "Новый УникальныйИдентификатор", чтобы наш массив получателей жил на протяжении всего сеанса пользователя).
Т.к. подключить обработчик ожидания мы не можем в текущем общем модуле, создадим и перейдем для этого в глобальный модуль "ОжиданиеОбработчика()". (подробнее в "Пример кода и описание пункта 2." ниже)
После выполнения "ВыполнитьОбработкуОповещения(ДополнительныеПараметры.ОбработчикРезультата, Результат)" и еще ряда процедур, исполнение кода переходит в процедуру "ВыполнитьСейчасВФоне", которую мы так же перехватим в расширении:
В данном фрагменте проверяем, что текущая рассылка у нас по расчетным листкам, затем после формирования фонового задания сохраняем его УИД в хранилище общих настроек.
Описанный выше код прописываем в заимствованном в расширении типовом общем модуле "РассылкаОтчетовКлиент".
Данный фрагмент кода используется, чтобы организовать повторение действий по созданию фонового задания для каждого получателя отдельно.
Для поиска узких мест в производительности сервера можно включить и настроить счетчики этой самой производительности «Performance Monitor».
По умолчанию данные собираются и пишутся в файлы, но это не всегда удобно. Появилась задача, для которой более удобно собирать счетчики в базу данных MS SQL и позднее анализировать через 1С.
Далее о том, как это настроить, и какая обработка получилась у меня.
Этап I. Подготовка БД MS SQL и ODBC.
1. Создаем пустую БД, например «Test»
2. Настраиваем ODBC
Идём в контрольную панель и вызываем «Administrative Tools» (Control Panel\All Control Panel Items\Administrative Tools)
Открываем (в зависимости от разрядности) «ODBC Data Sources» и добавляем новый провайдер на закладке «System DSN»
Выбираем источник, SQL Server
Заполняем реквизиты доступа к ранее созданной БД test:
Указываем учетную запись, под которой будет осуществляться подключение к БД (тут все зависит от ваших предпочтений, доменная или иcпользовать учетную запись MS SQL):
Далее можно, ничего не меняя, нажимать "next". В конце будет итоговое окно:
Нажимаем «Test Data Source» и получаем заветное: "TESTS COMPLETED SUCCESSFULLY!". Как показала практика, наличие этой прекрасной надписи не означает отсутствия проблем в дальнейшем.
Проверяем, что новый источник появился:
Основные настройки сервера в кластере 1С 8.3
Диапазоны ip-портов:
Диапазон портов рабочих процессов. Можно расширить, если сеансов очень много (несколько тысяч) и портов на все соединения не хватает, то целесообразно расширить этот диапазон.
Так же такая ситуация может возникнуть при нагрузочном тестировании, например на 5000 онлайн пользователей и более.
Параметры рабочих процессов и количество соединений на процесс:
Рекомендуется оставлять по умолчанию. Изменять есть смысл только тогда, когда много слабо нагруженных баз, можно увеличить их количество на 1 процесс, чтобы не плодить rphost-ы.
Так же целесообразно изменять настройку в случае, если есть одна очень нагруженная база, и лучше под нее выделить отдельный процесс, указав на одном из серверов 1 базу на 1 процесс.
Безопасный расход памяти за 1 вызов:
Данная настройка используется очень редко и рекомендуется оставлять значения по умолчанию.
"Срабатывание" настройки делится на несколько этапов:
- Критический объем памяти процессов;
- Безопасный расход памяти за один вызов;
- Временно допустимый объем памяти процессов;
- Интервал превышения допустимого объема памяти процессов.
Если превышает указанное значение, то пользователь получит ошибку «Недостаточно памяти для выполнения операции».
Центральный сервер (ЦС):
Определяет, является ли сервер центральным, т.е.:
- через который можно подключиться к кластеру.
- на котором работает главный менеджер кластера.
Второй центральный сервер 1С 8.3
Если мы указываем два ЦС в рамках одного кластера, то получаем две точки входа в кластер. Если 1 ЦС умрет, то будет работать второй ЦС. Для обеспечения такой функциональности, все данные кластера резервируются, таким образом, как следствие, повышается нагрузка на оборудование.
В отличие от уровня отказоустойчивости, в данном случае, даже при падении одного ЦС, кластер будет жить, а пользователи могут даже не заметить проблем.
Вопрос №2
Добрый день! В версии 8.3.15 платформы 1С список настроек рабочего сервера изменился (на скрине выделено красным). Можете вкратце рассказать о них?
Ответ
”Безопасный расход памяти за один вызов” – максимальный расход памяти в байтах при серверном вызове. Если вызов использует больше памяти чем положено, этот вызов будет завершен в рамках кластера 1С без перезапуска рабочего процесса (rphost.exe), то есть без негативного влияния на работу других пользователей.
“Временно допустимый объем памяти процессов” – максимальный объем памяти для всех рабочих процессов сервера. Если рабочий сервер стал использовать памяти больше, чем указано в этом параметре, то на этот рабочий сервер перестают назначаться новые соединения.
“Интервал превышения допустимого объема памяти процессов”- в секундах. Если через количество секунд, которое указано в этом параметре, рабочий сервер все еще продолжает превышать “Временно допустимый объем памяти процессов”, то будут перезапущены рабочие процессы с наибольшим потреблением памяти. Будет перезапущено такое количество процессов, чтобы оставшиеся процессы не потребляли больше, чем указано в параметре “Временно допустимый объем памяти процессов”.
“Критический объем памяти процессов” – в байтах. Если рабочий сервер использует памяти больше, чем указано в этом параметре, то освобождение памяти будет выполнено немедленно. Процессы с наибольшим потреблением памяти будут остановлены аварийно, и затем запущены заново. Количество таких процессов будет определяться так же, как описано выше (для параметра “Период превышения временно допустимого объема памяти процессов”).
Этап III. Получение данных и их обработка в 1С
Теперь нужно получить данные из этой БД и как-то интерпретировать. Для этого нам понадобятся 2 функции:
Подключение к БД:
Получение данных из БД
В описываемом примере используется только 1 счетчик, но на самом деле их может быть много, поэтому сначала получим их список из таблицы [CounterDetails]:
Результат разбиваем на 3 списка (можно одним, но не наглядно):
- Список объектов контроля (ОЗУ, процессор и т.д.) [ObjectName]
- Список счетчиков [CounterName]
- Список экземпляров (Например нагрузку на процессор можно отслеживать в общем, а можно по ядрам) [InstanceName]
В итоге, выбрав нужное значение, в каждом из списков можно получить ID, по которому мы получим данные из таблицы [CounterData]. Помимо ID в условии указываем интервал времени, за который мы хотим получить информацию:
Для построения графика достаточно выбрать CounterDateTime и CounterValue.
В итоге получилась обработка следующего вида.
Для удобства помимо графика на форму выведены таблицы результатов запросов.
Настройки подключения к БД видны на закладке «Настройки». В событии"ПриСозданииНаСервере" можно прописать их автозаполнение
При контроле сервера каждому требуется свой состав счетчиков. Каждый для себя определяет границы счетчиков, превышение которых не желательно (это могут быть рекомендованные показатели или выбранные для себя эмпирически). Чтобы всё это не держать в голове, было принято решение вести в обработке таблицу соответствия:
1. Имя счётчика (в нижнем регистре)
2. Значение которое будет отчерчено на графике зеленой линией
3. Описание счетчика.
Для примера, в обработке заполнил полностью для рассматриваемого счетчика. Результат видно на основном скрин-шоте:
Никаких уникальных технологий не применялось, всё сделано именно на уровне "для чайников", из-за этого кому-то код может показаться "не на уровне". Так что пожелания и к онструктивная критика - приветствуются.
Если где-то описал сумбурно и требуется больше пояснений или кода - готов откорректировать.
Специальные предложения
(4) Самьій главньій тут вопрос - это смотреть данные в динамике.
Я еще собираю статистику по журналу регистрации, ну и счетчики, которые сервер 1с отдает с помощью утилиты rac/ras (отвязался от com, но привязался к 8.3), все это храниться в grpaphite + elasticsearch, ну и отображается с помощью graphana.
График в обработке - только визуализация, сделана скорее для демонстрации.
Причина сбора данных в БД:
1. Объем хранимой информации. Например, данные за месяц, необходимых мне счетчиков, в файлах занимают 17 Гб, в БД 3 месяца занимают 6 Гб.
2. При сбоях сервера или при сильной нагрузке наблюдались "пробелы" в файле счетчика. При сборе в БД пока что такой проблемы не обнаружено
3. Использование T-SQL для поиска необходимых данных. Например, сколько раз счетчик превышал заданное значение в течение дня/недели/месяца и тому подобное. Т.е. более гибкий и удобный анализ собранных данных.
4. Можно собирать данные чаще, чем раз в 15 секунд и получить возможность автоматизации реакции на события на сервере.
5. Можно сделать “dashboard” из 10 графиков для мониторинга производительности сервера получая информацию об оперативной памяти, процессоре, латчах или блокировках, или мониторить сразу несколько серверов.
особенно меня радуют статьи "в интернете не нашел, поэтому. " так и хочется спросить сколько секунд искал
теперь по статье - открываете системный монитор действия - свойства - источник - базы данных.
чтобы снимать данные каждую секудну идете рядом в свойствах - общие - элементы диаграммы - съем показаний каждые: 1 секунда
интервал анализируемых данных выбирается свойства - источник - диапазон времени
как говориться без комментариев
про сбои данных полная чушь, точно также данные и в базу могут не попасть
показания можно писать в файлы периодически изменяя файл, чтобы гарантировать целостность большей части данных
при указании нескольких источников точно также можно посмотреть графики с разных серверов
(8) Gilev.Vyacheslav, Суть стаьи не конкурировать с другими сервисами, а показать что и как можно сделать.
Меня не интересует отправка данных на сторонние ресурсы + черный ящик, который не ясно как работает (как минимум по соображениям инф. безопасности) . В нем есть описание счётчиков и обоснование граничных условий? Ссылки на MSDN? + стоимость 10 000 руб. для юр. лиц.
(10) т.е. код так и не посмотрели, но решили порассуждать "не читал, но осуждаю"
похвальный подход, вопросов больше нет
(11) DenIv, именно потому что и наш код, и многие сторонние обработки уже много раз заново изобретались - данная статья нового контекста не несет на мой взгляд
"За пользование своим сервисом вы просите денег. " ну 100 рублей мы просим потому что когда 3 года сервис работал бесплатно, люди настраивали десятки гигабайт в месяц к нам заливать, а при этом не разу не пользовались, поэтому мы сделали скорее психологический барьер чтобы ненужную работу наши сервера не делали, если 100 рублей - это как цуп за 84 000 руб., то готовы взять 1 рубль или даже бесплатно, главное что вы обязуетесь выключить заливку, если не будете заглядывать больше месяца
если уж говорить про сбор счетчиков, уж хотя бы написали бы про подкладывание счетчиков загруженности оборудования в трассировку профайлера, многим лень почитать, хоть новое узнают люди )))
Это какие такие счетчики занимают 17Гб за месяц?! Вы показания вообще всех счетчиков пишете или просто по большому количеству серверов?
Показания 25 основных счетчиков (Система, дисковая, MS SQL) одного сервера за полгода - меньше полутора гигабайта в общей папке скай-драйв - 6 файлов в сутки по 1,6 Мб.
В 08:00 автоматом стартуют, весь день пишутся, после 20:00 выключаются. В случае сбоя - оповещают.
Можно было и в СУБД писать, но скай-драйв по доступности универсальней, в любой момент с любого устройства можно открыть и изучить. А для продвинутого мониторинга есть ЦУП.
Это какие такие счетчики занимают 17Гб за месяц?! Вы показания вообще всех счетчиков пишете или просто по большому количеству серверов?
PhysicalDisk(_Total)\% Disk Read Time
PhysicalDisk(_Total)\% Disk Write Time
PhysicalDisk(_Total)\Avg. Disk Bytes/Read
PhysicalDisk(_Total)\Avg. Disk Bytes/Write
PhysicalDisk(_Total)\Current Disk Queue Length
PhysicalDisk(_Total)\Disk Read Bytes/sec
PhysicalDisk(_Total)\Disk Write Bytes/sec
PhysicalDisk(ххх)\Avg. Disk sec/Read по 3-м дискам
PhysicalDisk(ххх)\Avg. Disk sec/Write по 3-м дискам
Processor(_Total)\% Processor Time
Processor(_Total)\DPCs Queued/sec
При наличии 11 дисков и 16 CPU занимает за сутки 390 МБ.
Для продвинутого мониторинга есть много продвинутых систем, например SCOM.
А что ЦУП начали раздавать дешевле 100 000 рублей?
Забавно, я привел статистику с большим числом счетчиков для сервера с 16 CPU (8 аппаратных), 2 массива (9 дисков из которых 6 SSD), счетчики пишутся в двоичный формат раз в 10 сек. Ну и как я уже писал пишутся не нон-стоп, а с 8:00 до 20:00.
Единственный, на мой взгляд, недостаток - пока файл сбора данных не закроется нельзя его открыть для анализа. В этом плане запись в СУБД дает преимущество, можно смотреть данные почти в реальном времени.
(2) Gilev.Vyacheslav
Вячеслав, стесняюсь спросить: Ваш сервис, разве не по этому же принципу работает? Вы какими мотивами руководствовались когда изобретали свой велосипед?
К чему это негатив? Идея не нова, действительно, но в интернетах, кроме Ваших сервисов, которые собирают по тому же принципу показания, но только в Ваши БД, и ЦУПа, ничего вменяемого БЕСПЛАТНО действительно нет.
Ваш HardwareClient82 - это конфигурация собрал что-то отправил куда-то, получил ответ с истиной. Логика совершенно другая. За пользование своим сервисом вы просите денег.
Здесь все прозрачно, не кофа, а обработка, денег не стоит.
Процитирую. Вас же: - "как говориться без комментариев "
PS. Ваш авторитет в данной области ни у кого не вызывает сомнений, однако, именно поэтому Ваша позиция : все дерьмо я Д`артаньян смотрится как-то странно
(2) h00k ЦИБ - стоит нормальных денег, плюс без подготовки и обучения понять что-то в ЦУПе сложно (ИМХО).
platonov.e; Nikola_N; user792548; igor.ofitserov; ivv1970; shalimski; murat_; Vary; AlexO; Babuin; JohnyDeath; + 11 – Ответить
Причины медленной работы клиент-серверной информационной базы 1С могут быть связаны не только с вопросами производительности, параллельности, оборудования, но и банально с настройками кластера серверов 1С. Загляните в параметры кластера. Если возникнут вопросы, приходите на курс Запуск и настройка кластера серверов 1С!
Читайте также: