Это интересно
- ОКД
- ЗКС
- ИПО
- КНПВ
- Мондиоринг
- Большой ринг
- Французский ринг
- Аджилити
- Фризби
Опрос
Полезные ссылки
РКФ
Все о дрессировке собак
Стрижка собак в Коломне
Поиск по сайту
Статьи. Тормозит журнал регистрации 1с
1С. Удаление журнала регистрации на сервере
При работе в клиент-серверном варианте со временем разрастается журнал регистрации. Сжатие его типовыми средствами результата не дают, будем удалять.
Различия данной операции на Linux и Windows минимальны, и обусловлены только различиями ОС. Ближе и роднее конечно Debian, потому основное описание и команды будут для него.
Для Windows отличается только размещения каталога кластера серверов(смотри по тексту), а остановить и запустить службу можно из соответствующего раздела в панели администирования.
Дано
Сервер с Debian x64 на борту и установленным сервером 1С:Предприятие 8.3.10.2580 x64. Со временем разросся журнал регистрации и занимает более 40 Гб, а терять такой объем на SSD не выгодно.
Решение
Первым делом необходимо остановить службу сервера 1С:Предприятие.Для этого выполним команду /etc/init.d/srv1cv83 stop на которую получим ответ
# /etc/init.d/srv1cv83 stop Stopping 1C:Enterprise 8.3 server: OKДля Windows по умолчанию это каталог %programfiles%\1cv8\srvinfo\reg_1541\Теперь проверим, что лежит в данном каталоге
# ls -h -l /home/usr1cv8/.1cv8/1C/1cv8/reg_1541/ -rw-r----- 1 usr1cv8 grp1cv8 2,0K окт 17 23:25 1CV8Clst.lst -rw-r----- 1 usr1cv8 grp1cv8 2,0K окт 8 18:40 1CV8Clsto.lst drwxr-xr-x 3 usr1cv8 grp1cv8 43,7G янв 27 2017 21528742-e4a5-11e6-4f8a-80ee7336f1fc drwxr-xr-x 4 usr1cv8 grp1cv8 1,2G янв 27 2017 5b53ab74-e4a5-11e6-4f8a-80ee7336f1fc drwxr-xr-x 4 usr1cv8 grp1cv8 3,4G мар 12 2017 90b8b40e-071d-11e7-7f90-80ee7336f1fc drwxr-xr-x 4 usr1cv8 grp1cv8 1,1G,янв 27 2017 e0293120-e4b9-11e6-4f8a-80ee7336f1fc drwxr-xr-x 2 usr1cv8 grp1cv8 4,0M окт 17 13:26 snccntxdbc54ce8-e3f3-11e6-e197-a7d6ea9824faПосмотрим на содержимое файла 1CV8Clst.lst, в нем хранится соответствие ИБ и вложенных каталогов. Файл имеет следующий вид (привожу только начальную часть текста с описанием первой ИБ)
{0, {da007f72-e3f3-11e6-0c8f-a349084f127d,"Локальный кластер",1541,"SRV1C",0,0,0,0,0,0,0, {1, {"SRV1C",1541} },0,0,0}, {3, {5b53ab74-e4a5-11e6-4f8a-80ee7336f1fc,"trade","Управление торговлей","PostgreSQL","SRV1C","trade","srv1c","g95WK23ghLi4v7ktux/t8cMLO+5jkGMPWFRRHR4fHcR08=","CrSQLDB=Y;DB=trade;DB$ {0,00010101000000,00010101000000,"","",""},0,1,"",0,"","",23},- 5b53ab74-e4a5-11e6-4f8a-80ee7336f1fc — Название каталога в котором расположен ЖР ИБ;
- trade — Имя указываемое в строке подключения к ИБ;
- Управление торговлей — Описание ИБ указанное в консоли серверов.
А необходимо это знание, чтобы удалить безвозвратно ЖР для тестовых ИБ, а от рабочей отломить и положить на полку переместить и сжать в архив.
Теперь знаем, в каких каталогах необходимо удалить ЖР. Собственно переходим в нужный каталог, находим каталог 1Cv8Log, а в нем файл 1Cv8.lgd или 1Cv8.lgf, удаляем или переносим его
# rm /home/usr1cv8/.1cv8/1C/1cv8/reg_1541/21528742-e4a5-11e6-4f8a-80ee7336f1fc/1Cv8Log/1Cv8.lgdОстается запустить службу сервера обратно, файл ЖР создастся автоматически
На этом операция по удалению журнала регистрации завершена, все заняло не более 10 минут.
guesto.ru
Чудеса с журналом регистрации в 1С 8.2.13.205
В конце мая пришлось столкнуться со следующей проблемой. После того как все пользователи выйдут из одной из информационных баз 1С (по причине обновления, перезапуска службы, перезагрузки сервера, либо просто все закончили работу и отправились по домам), подключение к этой же базе 1С занимало неоправданно долгое время - 3-5 минут. Потом, спустя эти самые 3-5 минут, наконец появляось окно для ввода логина и пароля, и никаких проблем в дальнейшем пользователи не испытывали. До тех пор пока все снова не выйдут из 1С. После этого ситуация повторялась. При этом, проблема возникала только на одной, основной, информационной базе. Из других баз пользователи могли входить и выходить когда им удобно, "злополучное" окно появлялось моментально. В качестве временной меры было выбрано такое решение - на моем компьютере, включенном постоянно, 1С не закрывалась никогда. Если мне тоже требовалось выйти из 1С, чтобы программисты могли обновиться - у нас была договоренность - до тех пор пока три человека не войдут в эту ИБ, они не закрывают конфигуратор. Естественно, это не избавляло нас от всех проблем. Во-первых, программисты могли забыть об этом и закрыть конфигуратор, во-вторых, сервер 1С "любит" перезагрузки. Увы, но это так, если не перезагружать его длительное время, начинаются непонятные тормоза в произвольные моменты времени у произвольных пользователей (к серверу СУБД это не имеет никакого отношения). Соответственно, время этих процедур увеличивалось на 5 минут, что было совершенно неприемлимо. С одной стороны, если бы это была какая-нибудь редкоиспользуемая ИБ, никто даже не обратил бы на это внимания, но именно для этой базы требовалось обеспечить максимальную скорость работы. Тогда, в мае, я обратил внимание на следующее: на любой копии базы, на любом сервере (как тестовом, так и на рабочем) проблема не появляется. При этом, процесс rmngr.exe (Менеджер кластера сервера 1С) потреблял 25 процентов процессорного времени, т.е. фактически захватывал одно ядро, на все 5 минут, которые длилось ожидание. После того, как он переставал "жрать" процессор, работа возобновлялась в нормальном режиме. Зная, что у 1С возможны проблемы с "локальным кэшем", я предположил, что серверный кэш так же может быть причиной проблемы. Однако, ни удаление всех "временных" папок, создаваемых 1С, ни удаление каталога snccntx, ни запуск сервера 1С под другим пользователем, ни даже полная переустановка платформы не приносили никакого результата. В результате, я удалил информационную базу с сервера 1С и создал ее под другим именем. И, о чудо, проблема решилась. Прошло 4 месяца. Возникла та же самая проблема. Программисты "выгнали" всех из 1С для проведения обновления, а когда работу можно было продолжить - оказалось, что войти в эту самую информационную базу, никто не может. Окно с предложением ввести логин и пароль появилось только через 5 минут... В этот раз, я твердо знал, что "пересоздание" информационной базы на сервере 1С поможет железно, но решил, что это решение не отличается ни простотой, ни красотой и следует найти что-нибудь более удобное. В первую очередь задумался: в чем разница между новой информационной базой и старой, при условии, что сама база данных на сервере СУБД остается нетронутой. И единственное различие, которое я увидел - это журнал регистрации. Да, журнал регистрации, в который могут записываться ошибки, предупреждения и просто все действия пользователей. У нас, это было известно точно, в журнал регистрации писалось все возможное и еще немного сверху. В то время когда мы принимали участие в проекте ЦКТП, программисты добавляли в журнал регистрации записи о времении выполнения самых важных для предприятия процедур. После завершения проекта было решено, продолжать записывать эти данные, поскольку по ним можно увидеть как себя ведет система с течением времени. Заглянув в каталог журнала регистрации (по адресу C:\Program Files\1cv82\srvinfo\reg_1641\id_базы\ - чтобы узнать id_базы посмотрите содержимое файла 1CV8Reg.lst) я увидел два каталога: 1Cv8FTxt и 1Cv8Log. Первый из которых содержал кучу файлов (период разделения ЖР установлен в "день") с совершенно нечитаемым содержимым, а второй содержал вполне привычные файлы журнала регистрации с расширениями .lgf и .lgp. Итак, поскольку, я решил, что проблема найдена, в Конфигураторе был выбран пункт меню Сервис->Настройки журнала регистрации и нажата кнопка "Сократить". Я сохранил сокращаемые записи ЖР в папку и решил, что проблема решена. Увы, это оказалось не так. Суммарный размер файлов журнала регистрации составлял 900 мегабайт до сокращения и 450 мегабайт после его сокращения. Казалось бы, минимум в два раза время ожидания должно сократиться. Но нет, время не уменьшилось, совсем. Готовясь плюнуть на все и "пересоздать" ИБ на сервере 1С, я, для успокоения совести, решил скопировать папки с ЖР на тестовый сервер, в идентичную базу и посмотреть что из этого получится. Как только копирование завершилось, я решил войти в эту ИБ конфигуратором - и, вот здесь произошло второе чудо, не смог. Тестовый сервер жалобно пыхтел одним ядром, а я любовался на белый квадрат в середине экрана. Окна с предложением ввести логин и пароль, не было. Спустя 35 минут окно появилось, конфигуратор открылся, rmngr.exe снова потреблял не больше 1-2 процентов процессорного времени. Таким образом, было очевидно - причина в журнале регистрации. Однако, уменьшение его в размере совершенно не помогало. Тут произошло третье чудо - я вспомнил про чудесную утилиту FileMon от Марка Руссиновича. Оказалось, что такого продукта больше не существует, а его место занял ProcMon, совмещающий в себе функционал как FileMon, так и RegMon. Скачать его можно здесь. Первым делом, нужно настроить фильтр, поскольку на работающей операционке каждую секунду производятся десятки и сотни вызовов к реестру, файловой системе, сети и другим ресурсам. В первую очередь я создал правило, исключающее всю информацию о процессах, имя которых отличается от "rmngr.exe" и еще одно правило, отсекало все записи, в которых путь не содержал в себе "C:\Program Files (x86)\1Cv82\" (это каталог в который устанвливается 32-х разрядная серверная и клиентская части 1С на 64-битной ОС). И вот что я увидел:
если сокращать журнал регистрации до определенного момента в прошлом, файл 1Cv8.lgf, проверяемый процессом rmngr.exe, не изменяется в размерах;
- если сокращать журнал регистрации на сегодняшний день, 1Cv8.lgf не изменяется;
- если выбрать дату завтрашнего дня - бинго! файл 1Cv8.lgf очищается.
Естественно, при выборе последнего (да и второго варианта) информационная база, фактически остается без журнала регистрации (т.е. встроенными средствами через Сервис->Журнал регистрации) его нельзя будет просмотреть, поэтому требуется, при сокращении, ЖР сохранять его в папку, доступ к которой должен быть у всех пользователей, работающих с журналом регистрации.
aronov-oleg.blogspot.com
sql1c.ru - Статьи
Предисловие.
Посвящается статься тем любознательным людям, которые добрались до этого ресурса и сейчас читают статьи для повышения своего уровня, для лучшего понимания бизнес- и технологических процессов работы 1С.
Что такое 1С?
Зайдя на сайт фирмы 1С и почитав о 1Сv8 (http://v8.1c.ru/overview/), мы в первой же строчке замечаем, что 1С – это «система программ». И состоит она из, как минимум, трёх элементов:
Далее приведу определение слова система. Система (др.-греч. σύστημα «целое, составленное из частей; соединение») – множество элементов, находящихся в отношениях и связях друг с другом, которое образует определённую целостность, единство. Соответственно, 1С – это набор взаимосвязанных программных элементов, обеспечивающих вместе решение определенных задач.
Что такое производительность?
Если мы говорим о производительности сервера или какого-либо IT решения, то, равно как и при обсуждении каких-либо сложных составных систем, нам необходимо определить, что мы понимаем под производительностью. В целом, это кажется очевидным. И эту очевидную часть давайте сформулируем следующим образом: производительность IT решения – это количество выполняемых операций в единицу времени. По-простому, чем быстрее – тем лучше.
Как измерить производительность?
Однако, когда мы подходим к вопросу количественной оценки производительности, нам уже приходится определить, что именно и как мы будем измерять. Логично предполагая, что нас интересует скорость обработки информации, связанной с рабочими процессами, мы говорим, что нам нужно быстро обрабатывать информацию, с которой мы имеем дело. Допустим, идет речь о бухгалтерии. Работникам необходимо быстро вводить документы, проводить документы, делать отчеты. Соответственно, скоростью работы можно назвать количество проведения данных операций в минуту. Но вполне вероятно, что работники бухгалтерии будут называть скоростью то, насколько быстро открывается документ, как быстро осуществляется поиск по справочникам, как быстро программа сохраняет или проводит документ и как быстро строятся отчёты. А если мы обсуждаем складской учёт, то для работников склада важным будет скорость введения данных в программу, а для человека, выполняющего анализ движений по складу – скорость построения отчётов. Уже получается весьма разветвлённая система оценки. Но, двинемся далее, чтобы вы могли увидеть своё решение 1С с другой стороны – изнутри.
Чем определяется производительность?
Полагаю, вы являетесь автовладельцем и хорошо водите машину. Быть может, вы, даже никогда и не интересовались тем, как машина устроена и как функционирует. Однако, смею предположить, что вы в курсе, что в автомобиле есть двигатель и именно его работа передается на колеса, которые, вращаясь, движут автомобиль вперед. Управляете работой двигателя вы из кабины, нажимая педаль акселератора, а поворачивая рулевое колесо, вы меняете направление движения авто. Полагаю, вы уже заметили, что, даже не упоминая тормозную систему, без которой эффективное передвижение невозможно, вы заметили, что работу автомобиля обеспечивает множество взаимодополняющих систем.
Точно то же самое и при работе IT систем. Треугольник в начале статьи – лишь само программное решение 1С. Сама система 1С, в свою очередь, работает на оборудовании и под управлением операционной системы, а данных хранит, предоставляет, обрабатывает СУБД – система управления базами данных, которая тоже функционирует на базе операционной системы и использует аппаратные мощности того или иного серверного оборудования. Применяя только что уяснённое, немного дополним схему:
Если возьмём вариант с использованием терминальных решений, то можем получить такие схемы:
Естественным путем приходим к следующему вопросу.
Что влияет на производительность?
В связи с тем, что элементы систем взаимосвязаны и работают вместе, нетрудно догадаться, что на производительность влияют все элементы системы. Это оборудование, на котором исполняются серверные части системы, это программные решения, которые определяют, какие данные и как хранятся и используются.
Какие направления есть в производительности сервера?
Иными словами, но с сохранением смысла: что же мы можем сделать, чтобы увеличить те самые «количество операций в единицу времени», что определили в начале статьи? Оптимальным будет подход начать с базовых, главных, крупных элементов системы. В нашем случае это будет оборудование, на котором функционирует наша система. Следующим шагом будет аудит работы операционных систем, на которых уже функционирует программное решение. После – разбор работы программных компонентов – тех, что обеспечивают работу системы в целом, так как именно они определяют логику и функционал системы. На каждом этапе возможно повышение производительности, даже не затрагивая тему обновления оборудования. Ведь, всем понятно, что если купить новый, более производительный сервер, спланировать перенос на него функционирующей системы, прервать её работу на время переноса, обеспечить возможность быстрого возврата к исходной конфигурации, в случае неудачного переноса, и осуществив перенос и тестирование, то, несомненно, производительность возрастёт. Однако, предупрежу вас сразу, что подобный подход будет вас радовать не долго. Так как данные накапливаются, сложность системы возрастает, изменения вносятся, а неэффективное использование ресурсов будет так же тормозить всю систему в целом и со временем всё более усугублять ситуацию.
www.sql1c.ru
