Первым делом, после установки кластера 1С ранее нужно было создать рабочие процессы. Как оказалось, процессы кластера начали создаваться автоматически в зависимости от нагрузки базы.
Пробный запуск фоновых заданий основной базы заставило кластер 1С бесконечно перегружать rphost.exe и дополнительный rphost.exe никак не хотел создаваться. Покопавшись в настройках все стало понятно.
Максимальный объем памяти рабочих процессов - это объем памяти, который могут использовать рабочие процессы вместе. Нужно быть очень внимательными при установке параметра, измеряется в байтах. Если установить неверное значение (недостаточное для нормальной работы пользователей) пользователям будет выдана ошибка "Недостаточно свободной памяти на сервере 1С". Так же эту ошибку можно получить, когда на сервере 1С закончилась квота по памяти.
Безопасный расход памяти за один вызов - позволяет контролировать расход памяти при серверном вызове, измеряется в байтах. Если вызов использует больше памяти чем положено, этот вызов будет завершен в рамках кластера 1С без перезапуска рабочего процесса (rphost.exe). Соответственно "неудачник", который выполнил вызов сервера, утратит сеанс с базой 1С без влияния на работу других пользователей.
в одном ГБ - 1073741824 Байт, следовательно в 2 ГБ - 2147483648 Байта
Объем памяти рабочих процессов, до которого сервер считается производительным - при превышении этого параметра сервер в кластере 1С перестанет принимать новые соединения.
Количество ИБ на процесс - позволяет изолировать информационные базы по рабочим процессам. По умолчанию у текущего кластера 1С было установлено значение - "8", но на протяжении нескольких часов работы сервер себя очень нестабильно, сеансы пользователей зависали. После изоляции каждой информационной базы (значение - "1") проблемы пропали.
Количество соединений на процесс - по умолчанию значение "128". Так как у текущей базы очень большая нагрузка фоновыми заданиями (расчет логистики, анализ прайсов, анализ конкурентов и прочее) было принято решение уменьшить количество до "25".
Немного изменились настройки и самого кластера 1С:
Уровень отказоустойчивости - это количество рабочих серверов, которые могут одновременно выйти из строя, и это не приведет к аварийному завершению работы пользователей. Резервные сервисы запускаются автоматически в количестве, необходимом для обеспечения заданной отказоустойчивости. В реальном режиме времени выполняется репликация активного сервиса на резервные.
Режим распределения нагрузки - есть два варианта параметра: "Приоритет по производительности" - памяти сервера тратится больше и производительность выше, "Приоритет по памяти" - кластер 1С экономит память сервера.
Сервер 8.3 характеризуется переработанным заново внутренним кодом, хотя «снаружи» может показаться что это слега доработанный 8.2.
Сервер стал более «авто настраиваемым», часть параметров типа количества рабочих процессов теперь не создается вручную, а рассчитывается исходя из описаний требований задач по отказоустойчивости и надежности.
Это снижает вероятность неправильной настройки сервера и понижает требования к квалификации админов.
Получил развитие механизм балансировки нагрузки, который можно использовать либо для повышения производительности системы в целом, либо использовать новый режим «экономии памяти», который позволяет работает «с ограниченной памятью» в случаи если используемая конфигурация «любит отъедать память».
Стабильность работы при использовании больших объемов памяти определятся новыми параметрами рабочего сервера.
Особенно интересен параметр «безопасный расход памяти за один вызов». Для тех кто плохо представляет что это такое - лучше не тренируйтесь на «продуктивной» базе. Параметр «Максимальный объем памяти рабочих процессов» позволяет при «переполнении» не обваливать весь рабочий процесс, а только один сеанс «с неудачником». «Объем памяти рабочих процессов, до которого сервер считается производительным» позволяет заблокировать новые соединения как только будет преодолен этот порог памяти.
Рекомендую изолировать рабочие процессы по информационным базам, к примеру указать параметр «Количество ИБ на процесс = 1″. При нескольких высоконагруженных базах это позволит уменьшить взаимное влияние как по надежности, так и по производительности.
Отдельный вклад в стабильность системы вносит «расходование» лицензий/ключей. В 8.3 появилась возможность использования «менеджера программных лицензий» напоминая менеджер «аладина». Цель - возможность вынести ключ на отдельную машину.
Реализован он в виде еще одного «сервиса» в менеджера кластера. Вы можете использовать к примеру «свободный» ноутбук. Добавьте его в кластер 1с 8.3, создайте на нем отдельный менеджер с сервисом «сервис лицензирования». В ноутбук можно воткнуть аппаратных hasp-ключ, или активировать программные лицензии.
Наибольший интерес для программистов должен представлять «Требования назначения функциональности».
Требования назначенной функциональности 1с
Так на ноутбуке с ключом защиты чтобы не запускать пользователей на сервер кластера надо добавить «требования» для объекта требования «Клиентское соединение с ИБ» - «Не назначать», т.е. запретить рабочим процессам данного сервера обрабатывать клиентские соединения.
Еще больший интерес предоставляет возможность запускать «только фоновые задания» на рабочем сервере кластера без сеансов пользователей. Таким образом можно высоконагруженные задачи (код) вынести на отдельный машины. При чем можно одно фоновое задание «закрытия месяца» через «Значение дополнительного параметра» запускать на одном компьютере, а фоновое задание «Обновление полнотекстового индекса» на другом.Уточнение происходит через указание «Значение дополнительного параметра». Например если указать BackgroundJob.CommonModule в качестве значения, то можно ограничить работу рабочего сервера в кластере только фоновыми заданиями с любым содержимым. Значение BackgroundJob.CommonModule.<Имя модуля>.<Имя метода> - укажет конкретный код.
Кластер 1С 8.2
Сеансы позволяют выполнять балансировку загруженности и отказоустойчивости в управляемом приложении.
Менеджер кластера теперь стал сложнее. Часть функций теперь можно выделить в отдельный процесс и даже разместить на другом рабочем сервере кластера. Это позволяет балансировать загруженность сервера.
Отказоустойчивость сервера 8.2 достигается за счет:
Хранение информации о сеансе работы пользователя.
Пользователь не привязан больше к рабочему процессу.
Резервирование рабочих процессов в кластере.
Должно быть несколько рабочих процессов, в том числе резервируемые
Резервирование кластеров.
Указывается запасной кластер, при подключении - перечисляются в строке соединения
Это позволяет обеспечить непрерывность работы!
При разрыве физического соединения клиента с кластером (уборщица выдернула кабель, отключилось питание сетевого оборудования, неполадки у провайдера) не приходится заново подключаться к информационной базе и начинать всю работу сначала. После восстановления физического соединения пользователь может продолжить работу с того места, на котором она была прервана.
Если требуется техническое обслуживание компьютеров кластера, их можно выключать прямо во время работы, не останавливая работу пользователей с информационной базой.
При выходе из строя любого сервера кластера работа пользователей не остановится она будет автоматически переведена на резервный кластер и/или на резервные рабочие процессы. Для пользователей такой переход будет незаметным.
Если один из рабочих процессов кластера завершится аварийно, подключенные к нему пользователи будут автоматически переведены на другие или резервные рабочие процессы. Такой переход также будет незаметен для пользователей.
Ставя очередное обновление Бухгалтерии получил ошибку "Я работаю только на 8.3.4", ну вот... пришло время поставить 8.3.4. и так:
Процесс скачивания и установки новой платформы я описывать не буду, там все просто.
Служба Агент Сервера 1С
По умолчанию он ставиться на порт 1540, а там у меня крутится 8.2, поэтому меняем в ветке рееста
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\1C:Enterprise 8.3 Server Agent Параметр ImagePath
меняем номера портов, добавляя смещение: "C:\Program Files\1cv8\8.3.4.365\bin\ragent.exe" -srvc -agent -regport 1741 -port 1740 -range 1660:1691 -d "C:\Program Files\1cv8\srvinfo"
Запускаем Агента и Открываем консоль Администрирования серверов 1С и создаем кластер 8.3
Указал имя сервера и настроил на порт 1740 (на 1540 работает 8.2)
Создаем кластер + чуток оптимизировал( У меня всего небольшой ОДИН сервер, поэтому - указываю Интервал перезапуска рабочих процессов и объем памяти. т.к у меня один сервер - уровень отказоустойчивости - 0)
Теперь подробнее:
1. Интервал перезапуска: 86400 сек (24 часа). Момент перезапуска не регламентируется, видимо с момента установки параметров, либо запуска сервера приложений.
2. Также можно указать допустимый объем памяти: 3000000 Кб (3 Гб) - Для сервера с 4 ГБ оперативы, Если ее меньше, то не заполняйте этот параметр!.
3. Интервал превышения допустимого объема памяти — это непрерывный интервал времени превышения допустимого объема памяти, после которого сервер перезапустит процесс. Если указано 0 сек — будет ждать вечно.
4. Количество Рабочих процессов расчитывается автоматически на основании Ваших настроек
5. Уровень отказоустойчивости можно задавать уровень отказоустойчивости кластера как количество рабочих серверов, которые могут одновременно выйти из строя, и это не приведет к аварийному завершению работы пользователей. Резервные сервисы запускаются автоматически в количестве, необходимом для обеспечения заданной отказоустойчивости; в реальном режиме времени выполняется репликация активного сервиса на резервные.
6. Режим распределения нагрузки, который можно использовать либо для повышения производительности системы вцелом, либо использовать новый режим «экономии памяти», который позволяет работает «с ограниченной памятью» в случаи если используемая конфигурация «любит отъедать память».
Рабочий сервер
Сервер у меня простенький, 2 Gb оперативы всего и на нем будет всего 2 базы, поэтому настрою его так:
параметр Количество ИБ на процесс ставлю равным 1, т.е. хочу чтобы для каждой ИБ запускался свой процесс - это позволит уменьшить взаимное влияние как по надежности, так и по производительности. Вы же настраивате под характеристики своего сервера!
Информационная база
Добавляю ИБ:
В стартере пописываю базу:
Требования назначения функциональности
Я у себя это не настраиваю но думаю надо сказать об этом:
Управление кластером заключается в том, что администратор определяет состав компьютеров (рабочих серверов), на которых размещается кластер. Кроме этого (при необходимости) он может определить "требования" к ним: какие сервисы и соединения с информационными базами должны работать на каждом из рабочих серверов. Менеджеры кластера и рабочие процессы запускаются автоматически, исходя из назначенных "требований". "Требования" к рабочим серверам могут быть заданы интерактивно, из консоли администрирования кластера, или программно, из встроенного языка.
Так на ноутбуке с ключом защиты чтобы не запускать пользователей на сервер кластера надо добавить «требования» для объекта требования «Клиентское соединение с ИБ» — «Не назначать», т.е. запретить рабочим процессам данного сервера обрабатывать клиентские соединения. Еще больший интерес предоставляет возможность запускать «только фоновые задания» на рабочем сервере кластера без сеансов пользователей. Таким образом можно высоконагруженные задачи (код) вынести на отдельный машины. При чем можно одно фоновое задание «закрытия месяца» через «Значение дополнительного параметра» запускать на одном компьютере, а фоновое задание «Обновление полнотекстового индекса» на другом. Уточнение происходит через указание "Значение дополнительного параметра". Например если указать BackgroundJob.CommonModule в качестве значения, то можно ограничить работу рабочего сервера в кластере только фоновыми заданиями с любым содержимым. Значение BackgroundJob.CommonModule..- укажет конкретный код.
Профили безопасности
Профили безопасности служат для того, чтобы запретить прикладному решению выполнять действия, которые могут быть потенциально опасны для функционирования кластера серверов.
Администратор кластера может назначить любой информационной базе один из существующих в кластере профилей безопасности. И тогда потенциально опасная функциональность прикладного решения будет ограничена в тех пределах, которые описаны в этом профиле.
Стандартно, после создания, профиль безопасности запрещает выполнение всех потенциально опасных действий:
-обращение к файловой системе сервера;
-запуск COM-объектов;
-использование внешних компонентов 1С:Предприятия;
-запуск внешних обработок и отчётов;
-запуск приложений, установленных на сервере;
-обращение к ресурсам Интернета.
Таким образом защититься от нежелательных действий незнакомого прикладного решения очень просто: нужно создать пустой профиль безопасности и назначить его информационной базе. Далее, если есть необходимость, можно расширять этот профиль, описывая в нём действия, которые разрешается выполнять прикладному решению.
Расположение служебных файлов менеджера кластера в 1С Предприятии 8.3
Если при установке системы! «1С:Предприятие» был выбран вариант запуска сервера «1С:Предприятия» как сервиса, то первый запуск агента сервера будет выполнен еще в процессе установки системы. При этом сервис будет запущен от имени пользователя, выбранного в диалоге установки системы, но служебные файлы кластера серверов будут расположены в каталоге <каталог установки системы 1С:Предприятие>\srvinfo (в параметрах сервиса будет в явном виде указан ключ запуска -d).
Если при установке системы «1С:Предприятие» был выбран вариант запуска сервера как приложения, то запуск сервера в процессе установки системы не выполняется; агента сервера необходимо запустить самостоятельно, после того как установка системы будет закончена. При этом если ключ запуска -d указан не будет, служебные файлы кластера серверов будут расположены в каталоге по умолчанию: %USERPROFILE%\LocalSettings\ApplicationData\lC\lCv8 (%LOCALAPPDATA%\lC\lCv8 для ОС WindowsVista и старше).
ВНИМАНИЕ! Если однажды на данном центральном сервере уже был создан кластер, то при смене варианта запуска агента сервера (сервис, приложение) или при смене пользователя, от имени которого работает агент сервера, всегда следует заботиться о правильном указании пути к каталогу служебных файлов кластера серверов. Если в процессе запуска агент сервера не обнаружит список кластеров, он создаст новый кластер на данном сервере.
В операционной системе Linux служебные файлы кластера серверов будут расположены в папке /home/usrlcv8/.lcv8/lC/lcv8 (или сокращенный вариант записи - ~/.1cv8/1C/1cv8).
Тем, кто не сталкивался с 8.2 и всеми проблемами, особенно ранних версий платформы на системах с большим количеством пользователей меры, описанные в этой статье окажутся избыточными. Но все действия продиктованы только опытом, и проверены практикой.
1) Резервный центральный кластер создавать нужно. Это аксиома. Если у вас более 10 пользователей и в течение дня в 1С ведется хоть какая-то работа - выделите хотя бы обычный компьютер с не серверным "железом" под резервный центральный кластер - это пригодится.
2) Резервный центральный кластер - это не кластер включенный в группу резервирования.
Это полноценный центральный кластер, который является копией существующего. Да, это возможно; более того - это нужно делать. Только нужно отключить фоновые задания на резервном кластере серверов. Я не уверен по поводу лицензионного соглашения с 1С, но если в каждый момент времени будет использоваться только один центральный кластер ничего страшного в этом нет. Но сами понимаете, чтобы "подмена" кластеров была "горячей" кое что придется сделать... как минимум сбегать в серверную и переставить ключик. Кроме того резервный центральный кластер можно запускать с ключем -debug (в реестре: HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services\1C:Enterprise 8.2 Server Agent параметр "imagePath"). И использовать для отладки серверного кода разработчиками. Резервирование центрального кластера в случае использования штатного механизма 1С - штука наверное хорошая, вот только у меня лично она не сработала. Дело в том, что она не работает в случае "подвисания" процесса центрального кластера "rpmngr" - т.е. процесс есть, определить его отсутствие ещё не удаётся, механизм использования резервного центрального кластера не включается. А пока что с центральным кластером чаще всего случались проблемы "зависания" а не "падения".
3) Про 1cestart.exe забудьте. Моё личное мнение конечно, но по-моему этот блок в 1С отдали писать каким-то студентам (что вполне возможно, т.к. стартер не является частью платформы и не особо критичен). Столько ошибок в его работе находили в релизах, столько "глюков" было обнаружено в это простом инструменте, что пользоваться им решительно не советую, особенно в свете того, что далее будет специальный скрипт запуска 1С.
4) Для запуска 1С разработал специальный скрипт:
В данном скрипте "Сетевая папка" нужно заменить на адрес общедоступной папки, в которую вы поместите файлы настроек. По умолчанию файл может быть один. Но так же существует возможность для разных баз использовать разные сервера центрального кластера и разные файлы настроек. Это нужно, к примеру, чтобы сперва в работе новую версию платформы "протестировала" бухгалтерия, а потом уже перешли на новую версию основные торгующие подразделения.
файл настроек при этом будет иметь вид:
Всего 2 строчки. В первой - версия платформы, во второй - имя центрального кластера серверов
Этот скрипт нужно положить в ту же сетевую папку (если безопасность у вас в сети позволяет запускать скрипты из сетевых папок). Если не позволяет - на локальные компьютеры пользователей, и создать ярлыки для баз 1С со строками вида:
Где Base - имя базы в кластере для запуска. Пример скрипта, самосотятельно определяющего текущий EXE-шник 1С:
После этого изменением одной строчки в файле настроек вы сможете переключить запуск пользователей на другую платформу или на другой центральный кластер 1С. Не один раз этот простой скрипт спасал от долгого простоя.
Если имя сервера используется где-то при установке COM соединений - его тоже нужно поменять.
Соответственно при окончательном и бесповоротном падении основного сервера нужно сделать:
а) Останавливаете службу сервера если она ещё сама не остановилась (обязательно нужно это сделать чтобы на сервере не осталось активных пользователей, а то может сбоить нумерация объектов)
б) Переключаете в файле запуск на новый сервер
в) net send * "Перезайдите в 1С"
г) Запускаете 1С с новго сервера - вызываете на всякий случая "ОбновитьНумерациюОбъектов"
д) Включаете фоновые задания но новом кластере серверов
После этого "чините" основной сервер (починка чаще всего заключается в очистке каталога C:\Program Files\1cv82\srvinfo)
И в конце дня те же самые процедуры (кроме оповещения) проделываете для переключения обратно на основной сервер.
Если падение сервера наблюдается после обновления платформы, то к данным действиям нужно еще добавить восстановления COM соединителя на всех клиентских компьютерах (если вы используете COM или OLE) - нудно через установку и удаление программ выбрать нужную вам версию платформы и нажать "восстановить". т.к. COM соединения обычно не используются в критических процессах - они чаще всего нужны для интеграции, то их восстановление "терпит" и вы можете позволить себе обновлять машины, или сделать это групповой политикой, если разрешения для клиентских рабочих станций позволяют.
5) Резервная копия перед обновлением. Обязательно конечно - были уже релизы где все субконто очищались... так что лучше не рисковать
6) Проверка запуска после обновления. Тоже обязательна. И обратите внмание на время запуска... Оно может вдруг увеличиться до оочень большого.
Собственно эта методика позволяет "почти безболезненно" обновлять платформу, и быстро "откатываться" к "старым" релизам в случае возникновения проблем. Так же позволяет быстро переключиться на резервный центральный кластер в случае отказа основного. Успешно работает и опробована в случае работы в едином домене и преимущественно в терминальном режиме. В случае когда не единый домен и пользователи работают не не терминальных серверах появятся ещё "заморочки" с обновлением платформы на клиентских машинах (для них придётся использовать политики групп) и создании общей папки (если не единый домен), но возможности WSH позволяют считать файл из любого места - с этим проблем не будет.
Автор: Олег Филиппов
Утилита администрирования клиент-серверного варианта предназначена для решения следующих задач:
* создание, изменение и удаление кластеров серверов;
* модификация существующих кластеров: создание, изменение параметров и удаление рабочих серверов, рабочих процессов кластера, информационных баз, входящих в состав кластера;
* управление списками администраторов центральных серверов кластеров и списками администраторов кластеров;
* мониторинг соединений пользователей с информационными базами и служебных соединений;
* отключение пользователей от информационной базы;
* мониторинг объектных блокировок 1С:Предприятия 8 и блокировок клиентского соединения;
* оперативный анализ транзакционных блокировок системы управления базами данных;
* управление блокировкой установки соединений пользователей с информационной базой;
* управление блокировкой выполнения регламентных заданий.
Утилита представляет собой подключаемый модуль MMC (Microsoft Management Console), и может быть использована на компьютерах, на которых установлено соответствующее программное обеспечение (для операционных систем Windows 2000/XP/Server 2003 это программное обеспечение является стандартным). Все функции администрирования сервера 1С:Предприятия 8 также доступны средствами встроенного языка.
Блокировка установки соединений пользователей с информационной базой
Блокировка установки соединений пользователей с информационной базой позволяет запретить пользователю соединение с информационной базой в заданный период времени.
При этом администратор системы может указать сообщение, которое будет выдано пользователю, при попытке соединения:
Такая возможность позволяет упростить администрирование системы в тех случаях, когда для выполнения регламентных операций с информационной базой требуется монопольный доступ к базе данных. Блокировка установки соединений пользователем может быть выполнена как интерактивно, так и средствами встроенного языка.
Блокировка выполнения регламентных заданий
Блокировка выполнения регламентных заданий позволяет запретить автоматический запуск регламентных заданий (в соответствии с расписанием) в тех случаях, когда их выполнение может затруднить регламентные действия с информационной базой, например, обновление конфигурации. Блокировка выполнения регламентных заданий может быть установлена для каждой информационной базы в отдельности как в процессе создания, так и в процессе работы информационной базы(в свойствах ИБ).
Блокировка выполнения регламентных заданий в процессе создания ИБ:
Профайлы содержат информацию, не оказывающую влияния на логику функционирования системы на базе 1С:Предприятия 8.1. Такая информация не является необходимой, но ее сохранение может, например, повысить комфортность работы пользователя. В профайлах можно хранить формат и расположение окон и диалогов, настройки шрифтов, цветов, отборов и т. п. Потеря такой информации НЕ может привести к нарушению работоспособности системы.
Профайлы различаются по принадлежности хранимой в них информации. Примеры хранимых данных и их расположение: - Настройки текстового редактора.
<Данные приложений пользователя>/1C/1Cv81/1Cv8.pfl, например: C:/Documents and Settings/User/Application Data/1C/1Cv81/1Cv8.pfl
Информационная база - Режим аутентификации при старте 1С:Предприятия из отладчика.
- Каталог последнего сохранения хранилища конфигурации в файл.
Таблица files базы данных, в которой размешена информационная база.
Информационная база и пользователь - Настройки динамических списков.
- Настройки отборов по журналу регистрации.
Таблица files базы данных, в которой размешена информационная база.
Компьютер и информационная база - Настройки сравнения файлов конфигураций.
- Настройки глобального поиска по текстам конфигурации.
<Данные приложений пользователя>/1C/1Cv81/<Идентификатор информационной базы>/1Cv8.pfl, например:
C:/Documents and Settings/User/Application Data/1C/1Cv81/ 4129dbdb-b495-41cb-99ea-ef315060a03e/1Cv8.pfl
Компьютер, информационная база и пользователь - Расположение окна синтакс - помощника.
- Список переменных для быстрого просмотра в отладчике.
<Данные приложений пользователя>/1C/1Cv81/<Идентификатор информационной базы>/<Идентификатор пользователя>/1Cv8.pfl, например:
C:/Documents and Settings/User/Application Data/1C/1Cv81/ 4129dbdb-b495-41cb-99ea-ef315060a03e/ E8D87DA4-A087-4145-95E7-D613E0F7CB64/1Cv8.pfl
1С:Предприятие 8.1 в режиме Конфигуратора - Расположение окон конфигуратора.
- Цвета редактора модулей в конфигураторе.
<Данные приложений пользователя>/1C/1Cv81/1Cv8cmn.pfl, например:
C:/Documents and Settings/User/Application Data/1C/1Cv81/1Cv8cmn.pfl
1С:Предприятие 8.1 в режиме Предприятия - Расположение окон конфигуратора.
- Цвета редактора модулей в конфигураторе.
<Данные приложений пользователя>/1C/1Cv81/<Идентификатор информационной базы>/<Идентификатор пользователя>/1Cv8cmn.pfl, например:
C:/Documents and Settings/User/Application Data/1C/1Cv81/ 4129dbdb-b495-41cb-99ea-ef315060a03e/ E8D87DA4-A087-4145-95E7-D613E0F7CB64/1Cv8cmn.pfl
Диалог запуска 1С:Предприятия 8.1 - Размеры и расположение диалога запуска.
- Настройки диалогов установки параметров информационных баз.
<Данные приложений пользователя>/1C/1Cv81/1Cv8strt.pfl, например:
C:/Documents and Settings/User/Application Data/1C/1Cv81/1Cv8strt.pfl
Данные из профайлов читаются при старте 1С:Предприятия 8.1 и записываются при его штатном завершении. По этой причине в случае нештатного завершения некоторые пользовательские настройки могут не сохраниться.
Наряду с профайлами в каталоге данных приложения могут содержаться и другие файлы с информацией, сохранение которой делает работу пользователей с 1С:Предприятием 8.1 более удобной. Среди них:
def.usr - хранится в каталоге <Данные приложений пользователя>/1C/1Cv8/<Идентификатор информационной базы> (например, C:/Documents and Settings/User/Application Data/1C/1Cv81/4129dbdb-b495-41cb-99ea-ef315060a03e/def.usr) и содержит имя пользователя который последним открывал данную информационную базу. ibases.v8i - хранится в каталоге <Данные приложений пользователя>/1C/1Cv81 (например, C:/Documents and Settings/User/Application Data/1C/1Cv81/ibases.v8i) и содержит список информационных баз, зарегистрированных на данном клиентском компьютере. Этот список отображается в диалоге "Запуск 1С:Предприятия". v8cscadr.lst - хранится в каталоге <Данные приложений пользователя>/1C/1Cv81 (например, C:/Documents and Settings/User/Application Data/1C/1Cv81/v8cscadr.lst) и содержит адрес каталога шаблонов конфигураций. GenTempl.st - стандартный файл шаблонов текста расположен в каталоге загрузочных модулей 1С:Предприятия (например C:/Program Files/1CV81/bin). appsrvrs.lst - хранится в каталоге <Данные приложений пользователя>/1C/1Cv81 (например, C:/Documents and Settings/User/Local Settings/Application Data/1C/1Cv81/appsrvrs.lst) и содержит список серверов 1С:Предприятия, зарегистрированных в утилите администрирования информационных баз в варианте клиент-сервер. srvribrg.lst - хранится на центральном сервере кластера в каталоге <рабочий каталог центрального сервера> (например, C:/Program Files/1cv81/server/srvribrg.lst) и содержит список кластеров, зарегистрированных на данном компьютере сервера 1С:Предприятия. Содержащиеся в нем данные необходимы для нормальной работы приложений, использующих данный сервер 1С:Предприятия. В каталогах DBNameCache, ConfigSave, Config, SICache хранится множество файлов, кеширующих различные компоненты конфигурации. Эта информация является производной от конфигурации информационной базы, хранимой в базе данных, и служит для ускорения запуска клиентских приложений и повышения их производительности. Кеш конфигурации располагается в каталоге данных приложений текущего пользователя, например, C:/Documents and Settings/User/Local Settings/Application Data/1C/1Cv81/7b0a6294-d6a3-41c5-a23e-dc9e5301ad22/DBNameCache. В каталоге 1Cv8FTxt хранятся данные, используемые службой полнотекстового поиска. Они располагаются на компьютере центрального сервера 1С:Предприятия в каталоге <рабочий каталог кластера>/<идентификатор информационной базы>. Например: C:/Program Files/1cv81/server/reg_1541/7eac7609-c0cb-4701-83cf-9ff5f8961de8/1Cv8FTxt. Группа файлов CACHE/ddb<n>.snp хранится в каталоге хранилища конфигурации и служит для кэширования запрошенных версий конфигурации из этого хранилища. Наличие этих файлов не является обязательным и позволяет ускорить получение версий конфигурации.
Временные данные нужны только в течение нескольких пересекающихся во времени или одного сеанса 1С:Предприятия.
К нескольким пересекающимся во времени сеансам относятся данные совместного использования, которые относятся к файловой информационной базе в целом и нужны, в частности, для реализации блокировок данных информационной базы. Такие данные хранятся в том же каталоге, что и файл информационной базы.
* Файл 1Cv8.1cl является носителем блокировок объектов базы данных, расположенной в файле 1Cv8.1cd.
* Файл 1Cv8Tmp.1cd хранит служебную сеансовую информацию, в частности список активных пользователей.
* Файл 1Cv8Tmp.1cl является носителем блокировок данных, расположенных в файле 1Cv8Tmp.1cd.
Для хранилища конфигурации 1С:Предприятие 8.х в режиме Конфигуратора создает временные файлы аналогичного назначения, расположенные в каталоге хранилища конфигурации:
* Файл 1Cv8ddb.1cl является носителем блокировок данных из хранилища конфигурации.
* Файл 1Cv8dtmp.1cd хранит служебную сеансовую информацию, в частности список активных пользователей хранилища конфигурации.
* Файл 1Cv8dtmp.1cl является носителем блокировок данных, расположенных в файле 1Cv8ddb.1cd.
Данные, используемые только в течение одного сеанса 1С:Предприятия, размещаются во временных файлах, создаваемых в каталоге, определенном в системе Microsoft Windows как каталог временных файлов. При этом для клиентского приложения используется каталог временных файлов текущего пользователя Windows, например, C:\Documents and Settings\User\Local Settings\Temp. Для сервера 1С:Предприятия используется или системный каталог временных файлов или каталог данных приложений пользователя, от имени которого запускаются рабочие процесса сервера 1С:Предприятия, например, C:\WINNT\Temp. Как очистить кэш 1С?
Добавление рабочего процесса
Добавление рабочего процесса, в отличие от просмотра, возможно, только для конкретного сервера кластера.
Для добавления нового рабочего процесса сервера кластера следует выбрать в дереве центральных серверов требуемый сервер, выбрать требуемый кластер, выбрать требуемый сервер кластеров выбрать ветку «Процессы» и выполнить команду контекстного меню "Создать - Процесс", галочкой Включить процесс.
По поводу перезапуска рабочих процессов - с какого момента начинается отсчет указанный в настройке кластера?
С момента старта процесса. Например стартовал в 18:00:00. Период перезапуска 86400 секунд, т.е. 24 часа. Соответственно через сутки в 18:00:00 процесс остановится и будет создан новый процесс.
Оптимизация рабочих процессов:
1. Интервал перезапуска: 86400 сек (24 часа). Момент перезапуска не регламентируется, видимо с момента установки параметров, либо запуска сервера приложений.
2. Также можно указать допустимый объем памяти: 3000000 Кб (3 Гб).
3. Интервал превышения допустимого объема памяти — это непрерывный интервал времени превышения допустимого объема памяти, после которого сервер перезапустит процесс. Если указано 0 сек — будет ждать вечно.
После разнесение сервера 1С:Предприятия и SQL-сервера на разные машины при загрузке dt-файла в базу расположенную на SQL-сервере стали получать ошибку "Недостаточно свободной памяти на сервере 1С:Предприятия".
или (Ошибка СУБД: Microsoft OLE DB Provider for SQL Server: there is insufficient memory in resource pool ‘default’ to run this query. HRESULT=80040E14 )
Решение проблемы:
1. При возникновении ошибки перезапустить службу сервера 1С.
2. Использовать много процессов(В свойствах кластера поставить галочку "Много процессов"). Добавить рабочие процессы, оптимальное значение 4-5 процессов.
3. Использовать регламентный перезапуск рабочих процессов. Но это не снимет проблему. Просто сократит "утечку" памяти.
4. Для операций с базой данных, например копирование базы данных использовать средства ms sql, а не работу с файлами dt.
5. Включите запись событий DBMSSQL в Технологический журнал
(Смотрите текст файла "logcfg.xml" ниже или воспользуйтесь обработкой с ИТС НастройкаТехнологическогоЖурнала.epf) и определите, на загрузке какой таблицы происходит ошибка. Если config, то выполните загрузку в файловый вариант и очистку конфигурации поставщика:
5.1 Для этого надо проверить конфигурацию на наличие некорректной информации. Для этого следует выполнить команду меню Конфигурация - "Проверка конфигурации" (НЕ ТЕСТИРОВАНИЕ!) с ОДНИМ установленным флажком "Проверка логической целостности конфигурации". При выявлении проблем будет выдано сообщение. Некорректная информация при этом будет удалена автоматически
5.2 Если Ваша конфигурация находится на поддержке, следует подобным образом проверить конфигурацию поставщика. Для этого в настройке поддержки следует сохранить конфигурацию поставщика в cf файл, загрузить его в новую базу и выполнить описанную в пункте 1 процедуру. В случае, если было получено сообщение об исправлении ("Удалена некорректная информация о метаданных"), значит конфигурация поставщика содержит некорректную информацию. В этом случае следует снять Вашу конфигурацию с поддержки и заново поставить путем объединения со свежим релизом конфигурации поставщика.
Добавление рабочего процесса
Добавление рабочего процесса, в отличие от просмотра, возможно, только для конкретного сервера кластера.
Для добавления нового рабочего процесса сервера кластера следует выбрать в дереве центральных серверов требуемый сервер, выбрать требуемый кластер, выбрать требуемый сервер кластеров выбрать ветку «Процессы» и выполнить команду контекстного меню "Создать - Процесс", галочкой Включить процесс.
Если процесс НЕ добавляется, то проверьте и сделайте следующее:
1. В свойствах Кластера должна стоять галочка "Много процессов"
2. В свойствах Рабочего сервера Увеличьте Диапозон IP адресов
По поводу перезапуска рабочих процессов - с какого момента начинается отсчет указанный в настройке кластера?
С момента старта процесса. Например стартовал в 18:00:00. Период перезапуска 86400 секунд, т.е. 24 часа. Соответственно через сутки в 18:00:00 процесс остановится и будет создан новый процесс.
Оптимизация перезапуска рабочих процессов:
1. Интервал перезапуска: 86400 сек (24 часа). Момент перезапуска не регламентируется, видимо с момента установки параметров, либо запуска сервера приложений.
2. Также можно указать допустимый объем памяти: 3000000 Кб (3 Гб).
3. Интервал превышения допустимого объема памяти — это непрерывный интервал времени превышения допустимого объема памяти, после которого сервер перезапустит процесс. Если указано 0 сек — будет ждать вечно.