Содержание
На сервере 1С со временем увеличивается в размерах папка
reg_1541, содержащая журналы регистрации 1С. Расположена эта папка в директории С:\Program Files\1cv82\srvinfo. И как следствие может возникнуть проблема свободного пространства на системном жестком диске. Чтобы избежать роста папки srvinfo необходимо периодически очищать журнал регистрации 1С.
Удаление неиспользуемых журналов регистрации из папки Srvinfo
В журнале регистрации фиксируется все изменения объектов баз 1С — документы, справочники, регистры и т.д.
Для каждой базы данных 1С существует своя директория хранения журнала регистрации и выглядит она таким образом:
C:\Program Files\1cv8\srvinfo\\\1Cv8Log
Папка <Имя кластера сервера> по-умолчанию называется reg_1541.
После удаления базы данных с сервера 1С папка журнала регистрации не удаляется из Srvinfo. Поэтому из множества папок в
Srvinfo могут находиться и те, которые давно не используются и просто занимают место на жестком диске.
Вычислить эти папки можно открыв файл 1CV8Clst.lst, который находится так же в reg_1541.
Копируем <Идентификатор базы на сервере> из папки Srvinfo и ищем в файле 1CV8Clst.lst. Если идентификатор в файле не найден, то папку можно удалять.
1CV8Clst.lst
В директории Srvinfo находится папка с названием вида snccntx+<Идентификатор базы на сервере>. Эта папка содержит сеансовые данные и ее лучше не удалять без необходимости т.к. много места она не занимает.
Настройка и очистка журнала регистрации 1С
Запускаем 1С в режиме конфигуратора и переходим в меню «Администрирование/Настройка журнала регистрации»
настройка журнала регистрации 1С
В настройках журнала регистрации можно выбрать какие события будут регистрироваться:
Ошибки — информация о сбоях
Предупреждения — важные уведомления, не ошибки
Информация — все изменения базы данных
Примечания — все остальные уведомления
Для очистки журнала регистрации нажимаем кнопку «Сократить»
очистка журнала регистрации 1С
Здесь можно будет увидеть диапазон дат, за который хранятся данные.
В поле «Удалить события до:» выбираем дату до который будем очищать журнал регистрации.
Удаляемые события рекомендуется записать в файл, чтобы при необходимости можно было их восстановить
Автоматизация процесса очистки журнала регистрации
Автоматизация процесса через командную строку Windows выглядит таким образом:
«\1cv8.exe» CONFIG /Out /ReduceEventLogSize -saveAs
— строка подключения к информационной базе. Т.к. речь идёт о серверном варианте, эта строка будет иметь вид «/S /N /P». Пользователь должен иметь право администрирования.
— путь к файлу, в котором будут сохранены сообщения системы при выполнении этой операции.
— дата, по которую будет укорочен журнал регистрации в формате yyyy-mm-dd
— путь к файлу в формате *.elf, к которым можно будет обратиться в случае необходимости проводить расследования давних операций с информационной базой.
Операцию необходимо выполнять когда нет активных подключений к базе 1С.
Образец скрипта для PowerShell
# # backup & shrink 1c logs # param ( $1cexe = «C:\Program Files (x86)\1cv82\8.2.15.319\bin\1cv8.exe», $1cbase = «srvrname\ibname», $1cuser = «username», $1cupassword = «password», $1coperlog = «s:\logs\1cshrink.txt», $1cdaysoflogstore = 7, # (get-date).Date.AddDays(-$1cdaysoflogstore).ToString(«yyyyMMdd») $1clogsarchive = «s:\backup\6months\», # $1clogfilename = $env:COMPUTERNAME.ToLower() + «-1clog-» + ($1cbase.split(«\»)) + «-» + (get-date).Date.ToString(«yyyyMMdd») + «.elf» ) $1clog = $1clogsarchive + $1clogfilename cmd /c «`»`»$1cexe`» CONFIG `/s$1cbase `/N`»$1cuser`» `/P`»$1cupassword`» `/Out$1coperlog `/ReduceEventLogSize $((get-date).Date.AddDays(-$1cdaysoflogstore).ToString(«yyyy-MM-dd»)) -saveAs`»$1clog`»`»»
Внимание! Данные для подключения к базе 1С обезличены. Необходимо заменить на свои.
Перенос журнала регистрации на другой диск
Чтобы избежать переполнения системного диска файлами журнала регистрации 1С папку SRVINFO можно перенести на другой диск. Выполнить это можно изменив параметры запуска службы «Агент сервера 1С:Предприятия 8.3» в реестре Windows.
редактирование запуска службы «Агент сервера 1С:Предприятия 8.3» в реестре Windows
Время от времени у меня возникает ощущение, что с какой-то проблемой никто, кроме меня, не сталкивался. То ли остальные не считают это проблемой и не видят смысла обсуждать, то ли секретную инструкцию вовремя прочитали и тем более молчат. В общем, никого вокруг проблема не беспокоит, хотя надо бы. А мне и спросить не у кого.
Именно такая ситуация возникла, когда я несколько лет назад занялся администрированием серверов 1С. А конкретно проблема заключалась в потерянных сеансах пользователей, мешающих обслуживать базы на сервере. Коллеги в таком случае просто открывали консоль администрирования и жали мышкой на красный крестик, да и то лишь когда им позвонят и попросят удалить сеансы.
Меня такой подход совершенно не устраивал, тем более что приближались новогодние каникулы. Бухгалтера, как водится, собирались ударно поработать чуть ли не со 2 января, а я вовсе не горел желанием чего-то там удалять мышкой по крестику, отвлекаясь от личных дел.
Средства, предусмотренные на этот случай разработчиками платформы (Конфигуратор – Администрирование – Параметры ИБ – Время засыпания пассивного сеанса, Время завершения спящего сеанса), почему-то работали как хотели и не гарантировали результат. Возможно, они до сих пор точно так же халтурят. Давно не проверял за ненадобностью.
Когда я стал искать в интернете готовый рецепт, довольно легко нашел, как удалять соединения, но не сеансы. Недоумение переросло в беспокойство. У меня-то проблем с соединениями не было, у меня проблема с сеансами! У меня что, платформа какая-то не такая, как у всех?
Но все же через синтакс-помощник и путем экспериментов решение было найдено достаточно быстро. Первый вариант внешней обработки был готов к нужному моменту, и результат стоил того. С тех пор накопился реальный опыт применения, обработка неспешно обросла опциями и в своем нынешнем виде прикреплена к этой статье. А здесь хотелось бы поговорить о том, как этим средством пользоваться.
Алгоритм удаления
Алгоритм, предлагаемый платформой 1С для получения сведений о сеансах, а заодно и удаления, в схематичном виде выглядит так:
Процедура ОбходКластеров(Сервер1С, База, АдминКластера = «», ПарольАдминКластера = «») // Все аргументы — тип Строка Коннектор = Новый COMОбъект(«v83.COMConnector»); Исключение … Агент = Коннектор.ConnectAgent(Сервер1С); Исключение … Кластеры = Агент.GetClusters(); Для каждого Кластер из Кластеры Цикл Агент.Authenticate(Кластер, АдминКластера, ПарольАдминКластера); Исключение … Сеансы(Агент, Кластер, База); КонецЦикла; КонецПроцедуры // ОбходКластеров() Процедура Сеансы(Агент, Кластер, База) Сеансы = Агент.GetSessions(Кластер); Для каждого Сеанс из Сеансы Цикл Если Сеанс.InfoBase.Name = База Тогда Агент.TerminateSession(Кластер, Сеанс); Исключение … КонецЕсли; КонецЦикла; КонецПроцедуры // Сеансы()
Здесь АдминКластера и ПарольАдминКластера – это логин и пароль администратора кластера серверов 1С. На практике их обычно можно не задавать. Значения по умолчанию – пустая строка.
Посмотрите еще раз на процедуру Сеансы(). В свойствах объекта Сеанс содержится все, что нужно, чтобы отличить одни сеансы от других. Ну, кроме того, чего в платформе все равно нет. А нет там хоть какого-то признака потерянных сеансов.
Есть еще свойства, значения которых сообщаются только для толстого клиента, конфигуратора и фонового задания. Это номер процесса (Сеанс.Process.PID) и номер соединения (Сеанс.Connection.ConnID). Учитывая все большее распространение тонкого клиента, эти сведения приходится признать бесполезными. Скорее всего, таким способом вам не удастся выяснить связь конкретного процесса rphost.exe с какой-либо базой. Кстати, в консоли администрирования мы наблюдаем ту же картину.
А еще жаль, что в длинном списке свойств нет явного указания на тот самый сеанс, в котором работает наша программа. Ведь его ни в коем случае нельзя удалять. Значит, придется самим организовать паспортный контроль. Например, вот так:
СтрокаСоединения = СтрокаСоединенияИнформационнойБазы(); СтрокаСоединения = СтрЗаменить(СтрокаСоединения, «;», Символы.ПС); ФлагСерверныйРежим = (Найти(Врег(СтрокаСоединения), «SRVR=») = 1); Если ФлагСерверныйРежим Тогда // Имя базы содержится в подстроке Ref=»имя_базы» внутри СтрокаСоединения // Далее имя базы будет в переменной ТекущийСеанс_ИмяИБ … КонецЕсли; … ТекущийСеанс = ПолучитьТекущийСеансИнформационнойБазы(); … ЭтоТекущийСеанс = Сеанс.InfoBase.Name = ТекущийСеанс_ИмяИБ И (Сеанс.UserName = ТекущийСеанс.Пользователь ИЛИ (Сеанс.UserName = «DefUser» И Строка(ТекущийСеанс.Пользователь) = «»)) И Сеанс.Host = ТекущийСеанс.ИмяКомпьютера И Сеанс.SessionID = ТекущийСеанс.НомерСеанса И Сеанс.StartedAt = ТекущийСеанс.НачалоСеанса И Сеанс.AppID = ТекущийСеанс.ИмяПриложения;
У объекта ТекущийСеанс есть еще свойство НомерСоединения, но надежность этого признака может зависеть от того, когда объекту присваивается значение – в начале работы или непосредственно перед проверкой. Ну, и замечание, сделанное выше, тоже надо иметь в виду.
Впрочем, даже показанный здесь набор условий выглядит избыточным. Наверняка хватило бы имени базы и номера сеанса, ведь остальные свойства – по сути атрибуты сочетания база + сеанс. Но, сдается мне, лучше воздержаться от такой оптимизации. Никто ведь не гарантировал корректность паспортных данных у потерянных сеансов и невозможность случайных совпадений.
Лучше обратите внимание на то, что проверка имени пользователя должна учитывать подвох, возникающий, например, при работе с пустой базой или при запуске фоновых заданий в отсутствие активных пользователей.
Ну, а если кому-то необходимо посмотреть или удалить соединения, то вместо процедуры Сеансы() нужно вызвать процедуру Соединения(), показанную ниже, но тогда еще потребуются логин и пароль администратора информационной базы:
Процедура Соединения(Сервер1С, Коннектор, Агент, Кластер, База, АдминКластера, ПарольАдминКластера, АдминИБ, ПарольАдминИБ) Процессы = Агент.GetWorkingProcesses(Кластер); Для каждого Процесс из Процессы Цикл Порт = Процесс.MainPort; РабПроц = Коннектор.ConnectWorkingProcess(Сервер1С + «:» + Порт); Исключение … РабПроц.AuthenticateAdmin(АдминКластера, ПарольАдминКластера); Исключение … РабПроц.AddAuthentication(АдминИБ, ПарольАдминИБ); Исключение … ИнформационнаяБаза = РабПроц.CreateInfoBaseInfo(); ИнформационнаяБаза.Name = База; СоединенияБазы = РабПроц.GetInfoBaseConnections(ИнформационнаяБаза); Исключение … Для Каждого Соединение Из СоединенияБазы Цикл РабПроц.Disconnect(Соединение); Исключение … КонецЦикла; КонецЦикла; КонецПроцедуры // Соединения()
Разбирая весьма неочевидную последовательность действий, описанную в этой процедуре, можно догадаться, почему в свое время на каком-то форуме нашлась подсказка именно насчет соединений. Для прохождения этого квеста нужен опытный проводник, а с сеансами можно и самому разобраться.
Впрочем, для меня до сих пор остается загадкой, зачем кому-то может потребоваться удалять соединения. Они и сами исправно отваливаются. Лично мне они никогда не мешали.
К тому же, сеанс может быть без соединения, если не нуждается в нем в данный момент. Если сеанс не обращается к кластеру (то есть пользователь бездействует), соединение ему не назначается. Так что для нас объект охоты – сеансы, а не соединения.
Объект охоты
Ну так вот, что, собственно, мы собираемся удалять, если у сеансов нет никакого специально предусмотренного флажка вроде ЭтоПотерянный? Как отличить хороших от плохих?
А никак. Нет ведь флажка. Это и есть правильный ответ. Но меня он совершенно не устраивал.
Поэтому моя обработка удаляет сеансы, которые выглядят потерянными. Первый кандидат на это звание – заснувшие сеансы, созданные тонким или толстым клиентом. Просто с другими клиентами я до сих пор не сталкивался, так что пусть пока будет так.
И пусть такие сеансы удаляются автоматически с некоторой периодичностью, например, раз в минуту, что совсем не трудно реализовать. А также при нажатии кнопки, что еще проще.
И вот тут возникает пара совершенно справедливых вопросов.
Во-первых, как быть с сеансами, заснувшими во время перерыва на обед? Пользователи будут несколько удивлены, вернувшись к рабочим местам. В конце концов им просто надоест каждый день читать сообщения про сеансы, удаленные за ненадобностью.
А во-вторых, как быть с сеансами, которым не спится? Как ни заглянешь в консоль, у них последняя активность вот только что была. Звонишь пользователю – нет никого. Пингуешь компьютер – опять никого. А сеанс все трудится, занят непонятно чем.
В ответ обработка обзавелась парой самых важных опций.
Во-первых, предусмотрен период бездействия, то есть время, в течение которого автоматическое удаление не выполняется. Границы периода задаются с учетом обстоятельств.
Например, если у вас лицензия на 50 подключений, в консоли стабильно наблюдаются 45-48 реальных сеансов, а денег на еще одну лицензию не дают, значит бездействуем только в обед и немного до и после него. Здесь главная задача – обеспечить резерв подключений, чему пользователи будут только рады. Их гораздо больше раздражает невозможность подключиться к базе, когда очень надо.
Если пользователей мало, лицензий гарантированно хватает, к тому же пользователи славятся дружным уходом домой в конце рабочего дня, тогда можно никого не беспокоить весь рабочий день с небольшим запасом.
А если за вашими пользователями замечена склонность работать с утра до ночи, а вам все-таки надо когда-то бэкапить базы, закрывайте интервал с шести утра до трех ночи. С трех до шести спят все, вот тогда и бэкапьте. А кто не спит – пусть получают окошки с сообщениями.
Кроме того, параметр «Время засыпания пассивного сеанса» все-таки чаще работает, чем не работает. Можно увеличить его с традиционных 20 минут до часа, и это сильно сократит количество жалоб.
Вторая важная опция – возможность удалять сеансы, созданные вчера или еще раньше, но не позднее заданного количества часов назад. Последнее условие позволяет не обрушивать ровно в полночь всю работу. По умолчанию задано 12 часов в расчете на тех, кто приступил к работе после обеда.
Не стоит легкомысленно относиться к этому параметру. Мало ли кто засиделся за компом, нервно смотрит на часы и хочет домой. Кофе давно допит, отчетность вот-вот будет сдана, а тут бац – и карета превращается в тыкву. Тут уж не сомневайтесь – утром придет злая мачеха, и вы узнаете о себе много такого, о чем, в принципе, догадывались.
Необходимо сделать важное замечание, связанное с сеансом самой обработки. Очевидно, что ее выполнение не должно зависеть от пользователей. Самый простой способ добиться этого – специально создать пустую базу и запускать обработку поверх нее. Разумеется, в этом случае база с обработкой займет лишний сеанс.
Сеанс, в котором запущена сама обработка, игнорируется. Но тут есть пара нюансов. С одной стороны, ничто не мешает запускать несколько экземпляров обработки с разными настройками, причем каждый в своем сеансе. С другой стороны, при перезапуске сервера сеанс базы с обработкой может восстановиться, но стать недоступным для управления, то есть по сути потерянным.
Из этих и не только этих соображений предусмотрена возможность указывать базы, исключенные из проверки, а для быстрого заполнения списков добавлены галочки «Проверять все базы» и «кроме этой базы». По умолчанию база с обработкой игнорируется.
Со временем появилась еще пара опций, требующихся редко, даже очень редко, но иногда полезных.
Во-первых, иногда коллеги-админы забывают закрыть конфигуратор после обслуживания базы на сервере. Пришлось предусмотреть возможность удалять такие сеансы. Но это только возможность, а вовсе не обязанность!
Только не забудьте, что если вы решили с помощью обработки расчищать дорогу для бэкапа, а бэкап баз 1С делаете запуском конфигуратора из командной строки, то придется как-то развести по времени удаление чужих сеансов конфигуратора и запуск своих. Тут период бездействия будет как раз кстати.
Ну, а во-вторых, один раз за свою не слишком долгую практику я наблюдал потерянные сеансы фоновых заданий. Уж не помню, что там за катаклизм приключился, но сеансы дружно повисли в консоли. Ладно, пусть будет и такая галочка. Опять же только возможность, а не обязанность.
Поскольку здесь обсуждались индивидуальные настройки процесса удаления для каждого конкретного сервера, возникает вопрос, не обзавелась ли моя обработка, как любая уважающая себя программа, файлом конфигурации? Да, есть такой. Назовем его файлом параметров, чтобы не путаться в терминах. Но об этом ниже.
Quick start
В командной строке приложений 1С предусмотрены два очень полезных ключика. Ну, не считая других, разумеется. Это /Execute и /C.
Благодаря им установка и первый запуск моей обработки на сервере выглядят так:
1. Копирую на сервер комплект файлов:
собственно обработка
v8i-файл для ее запуска
файл параметров
cmd-файл для регистрации библиотеки comcntr.dll
2. Создаю пустую базу. Пусть будет emptybase, к примеру.
3. Регистрирую на сервере библиотеку comcntr.dll, если это до сих пор еще не сделано.
4. В меню стартера 1С добавляю готовый v8i-файл запуска базы с обработкой, хотя это можно и не делать.
5. И запускаю.
Где взять файл обработки, сказано в конце статьи.
Файл для регистрации comcntr.dll сделан из файла RegMSC.cmd. В нем просто заменено имя библиотеки. Ну, и запускать его надо в подкаталоге bin каталога нужной версии платформы.
Файл для запуска базы с обработкой выглядит примерно так:
Connect=Srvr=»SRVR»;Ref=»emptybase»; ID=db847d2c-c326-4ece-bc72-0a19833a02dd OrderInList=6359 Folder=/ OrderInTree=393472 External=0 ClientConnectionSpeed=Normal App=Auto WA=1 Version=8.3 AdditionalParameters=/executeD:\EPF\УдалитьПотерянныеСеансы.epf /CD:\EPF\setup.txt
Уверен, вы знаете, как им пользоваться. Самое интересное написано в последней строке.
Ну и наконец, файл параметров. Здесь он называется setup.txt. Одновременно он служит руководством по написанию таких файлов. Вот реальный пример:
// Сервер1С = «SRVR» ИнтервалПовтора = 10 ФлагУдалитьВчерашние = Да СозданНеМенее = 16 ПериодБездействияНачало = 5:00 ПериодБездействияКонец = 2:50 // Если обработка запускается с помощью параметра командной строки /Execute, в // параметре /C можно передать имя файла параметров, содержащего значения // реквизитов формы, отличные от значений по умолчанию // Формат строки файла параметров: // ИмяРеквизита = значение // Значения типа Булево: 1, ДА, ИСТИНА (в любом регистре) — Истина; // 0, НЕТ, ЛОЖЬ (в любом регистре) — Ложь // Значения типа Время: ожидаются форматы ЧЧ:ММ:СС, Ч:ММ:СС, ЧЧ:ММ, Ч:ММ // Пробелы и символы табуляции в начале и конце строки, а также прилегающие к // знаку «=», игнорируются // Строки, начинающиеся не с имени реквизита или не содержащие знак «=» после // имени реквизита, игнорируются, поэтому любая такая строка может быть // комментарием // Строки, содержащие некорректные значения (не соответствуют типу, не входят в // допустимый диапазон, записаны с нарушением формата), игнорируются // Строки, начинающиеся с имен реквизитов, не включенных в список, фактически // игнорируются, так как инициализация этих реквизитов происходит после чтения // файла параметров // Имена и типы значений реквизитов // Сервер1С, Строка — Сервер 1С:Предприятие // СписокБаз, Строка — Информационные базы // ИсключитьБазы, Строка — Базы, исключенные из проверки // Базы можно задать списком, разделенным пробелами, запятыми или точками с // запятой // ФлагЭтотСервер, Булево — Сервер с базой, с которой запущена эта обработка // ФлагВсеБазы, Булево — Проверять все базы, кроме исключенных // ФлагИсключитьЭтуБазу, Булево — Исключить только базу, с которой запущена эта // обработка // ФлагСократитьОтчет, Булево — Сократить отчет // ФлагПовторять, Булево — Автоматически повторять операцию // ИнтервалПовтора, Число, 2, 0, Неотрицательное — Интервал повтора (минут) // ФлагПериодБездействия, Булево — Задан период бездействия // ПериодБездействияНачало, Время — Начало периода бездействия // ПериодБездействияКонец, Время — Конец периода бездействия // ФлагУдалитьВчерашние, Булево — Удалить вчерашние сеансы // СозданНеМенее, Число, 2, 0, Неотрицательное — Сеанс создан не позднее (часов // назад) // ФлагКонфигуратор, Булево — Удалить сеансы конфигуратора // ФлагФоновые, Булево — Удалить сеансы фоновых заданий // АдминКластера, Строка — Администратор кластера серверов 1С // ПарольАдминКластера, Строка — Пароль администратора кластера серверов 1С
Поскольку я в основном работаю в среде Windows, файл сделан в Блокноте в кодировке ANSI. Кто работает в Linux, надеюсь, разберется сам, как тут быть.
Желаю успеха! Мне этот инструмент реально помогает каждый день в течение нескольких лет.