Содержание
Этим текстом мы начинаем серию заметок на тему “Я у мамы инженер” или «Сделай сам». В них будут описываться реальные ситуации из нашей работы с вариантами решения задач. Внимательный читатель может извлечь из этих статей практическую пользу, в виде самостоятельного разруливания возникающих проблем с использованием наших методов.
Погнали. Случай номер раз.
“Без даты документ” Ошибка обмена в РИБ
У клиента две торговые точки. Работают в старой доброй Управлении торговлей 10.3. Развернута распределенная информационная база (в народе РИБ или распределенка). В один дождливый весенний день обмен между базами накрывается бездной…
Симптоматика такая: центральная база принимает и отправляет сообщения, но делает это очень долго. Периферийный узел только отправляет сообщения, а принимать отказывается, что характерно, делает это тоже очень долго (около 5 минут).
Выясняем 2 вещи: что за ошибка, и почему так долго. Текст ошибки как правило километровый, но самое интересное кроется в конце после слов “…ошибка метода контекста…”. В этом случае наблюдалось то, что поле Дата не может быть пустым. Соответственно, центральный узел в числе прочего пытается передать какой-то документ, в котором из-за системной ошибки затерлось поле Дата. А периферийный узел, как свирепый поборник дисциплины, отказывается принимать битые данные.
Что со временем обмена? Идем в папку DropBox, через которую узлы перебрасываются сообщениями. И видим, что исходящее сообщение от центральной базы весит 17 мегабайт, будучи затоптанным в архив. Это очень много, т.к. обычно размер таких файлов не превышает 500 килобайт. Отсюда и ноги растут. Узнаем у клиента, действительно, несколько дней назад они массово перепроводили документы за последние полгода, и как следствие файл обмена распух до неприличия.
Поскольку время ограничено, решаем проблему максимально коротким путем. Вместо разбора полетов и длительных поисков битого документа, просто заново создаем образ периферийного узла, который уже будет содержать все не полученные данные. Причем и здесь можно срезать маршрут. Делаем копию центральной базы, закидываем ее на периферийный комп через тот же DropBox. Удаляем все записи (кроме нужных) из вкладки Пользователи ИБ справочника Пользователи. Удаляем все записи из Плана обмена — Полный, кроме центрального и проблемного узлов. Удаляем все настройки обмена, кроме одной. Меняем константу Префикс информационной базы на нужную (Константы — Обмен данными). И теперь главный финт — меняем местами наименование и код у центрального и периферийного узла. Т.е. Центральный переименовываем в Периферийный и наоборот. После этого пользуемся хитрой обработкой “Установка главного узла” из нашего арсенала (простой и в то же время незаменимый инструмент в администрировании 1С), и готово. Осталась только пара штрихов: меняем наименование настройки обмена, нумерацию входящих и исходящих сообщений, и очищаем регистрацию (Настройки РИБ — Монитор обмена)
Проверяем. Обмен проходит за 8 секунд, все документы на месте. Время, затраченное на полную настройку периферийного узла в полтора раза меньше, чем на одно только создание образа стандартными средствами.
В данной рубрике будут описывать интересные случаи, типичные ошибки, а главное их решения, которые могут помочь вам избежать или даже восстановить работоспобность 1С самостоятельно.
Если вы не найдете решение своей проблемы в этой рубрике то всегда можете позвонить нам и оставить заявку на решение вашей проблемы.
Перенос 1С на новый Сервер
Любая база данных, наполняясь информацией, рано или поздно разрастается. Когда она достигает неприличных размеров, ее пересаживают в горшок побольше на SQL. Процедура эта сопряжена со значительными финансовыми затратами на лицензионное ПО, и, естественно, организации стремятся эти затраты максимально сократить.
Самым экономичным вариантом считается переезд на сервер с бесплатной операционной системой семейства Linux, и установка бесплатной СУБД PostgreSQL. Однако стоимость работ по установке и настройке как правило выше, просто потому что они более трудоемкие, и популяция специалистов-линуксоидов гораздо меньше, чем виндузятников.
Себя я отношу ко вторым, но отказываться от сложной и интересной задачи, это все равно, что расписаться в собственной некомпетентности. А задача такая поступила — взять файловую базу Управление торговлей 11, и бережно перенести ее на новый сервер. Всего навсего. Осталось начать, и закончить.
Первым делом стал знакомиться с сервером. Клиент не стал покупать собственное железо, а арендовал выделенный сервер. Находится он в Германии, в дата-центре Hetzner-online. Прелесть такого выбора (в отличии от покупки собственной железяки) в том, что не надо сразу вываливать кучу денег за сервер, условия его содержания соответствуют всему, чему только можно соответствовать, и присматривает за ним команда матерых профессионалов. Железо досталось весьма благопристойное — Intel Core i7-6700, 32 ГБ оперативной памяти, пара накопителей SSD на 500 ГБ. Связь с сервером вполне себе годная, не обрывается, хотя пинг и длинноват. В целом проблем в работе быть не должно. Месяц аренды такой машины обойдется в 50 евро.
Постучавшись по адресу сервера, обнаружил, что на него уже поставили операционку — CentOS 7.4. Это несколько обрадовало, т.к. с такой я уже имел дело, и велосипед, который придется изобретать, не так уж и страшен. Хотя отсутствие привычных окошек с параметрами и простого алгоритма “Далее-Далее-Готово” все же напрягало. По сути основную часть работы придется проделать, прописывая в бездушном черном окне консоли различные магические заклинания вроде yum install. Но это не беда, дорогу осилит идущий.
Составляем порядок действий:
- Установить сервер SQL, сделать первоначальную настройку
- Установить сервер 1С
- Залить тестовую базу
- Оптимизировать настройки для улучшения производительности
- Отметить это дело
Поскольку своего опыта в такой работе у меня, прямо скажем, маловато, я решил, образно выражаясь, встать на плечи гигантам. Выражаясь более прозаично — нагуглить инструкции и рекомендации по установке.
За основу взял инструкцию с Инфостарта, где расписаны основные этапы установки. Кроме того, восполнял пробелы в знаниях линуксовых команд путем нехитрых поисковых запросов (как копировать файлы по SSH, как в консоли Linux посмотреть аппаратные характеристики компа)
Первый этап прошел без проблем. Подключил репозиторий, установил последнюю версию Postgres с патчами от 1С, прописал необходимые параметры, и инициализировал служебные базы данных. Служба запустилась с первой попытки, вселяя уверенность в то, что и оставшаяся работа будет легкой прогулкой.
Взялся за настройки параметров работы сервера. Это именно та часть, на которую стоит обращать самое пристальное внимание. По большей части от нее зависит, будет ли сервер работать шустро. При этом каких-то конкретных, универсальных значений нет. Все настройки зависят от характеристик сервера, количества пользователей, и даже характеристик самой базы данных. 1С приводит лишь общие рекомендации по ключевым параметрам. Исходя из имеющихся характеристик железа, выставил первоначальные значения. Это уже не убогие настройки по-умолчанию, но позже их еще придется оптимизировать.
Установка сервера 1С тоже особых затруднений не вызвала. Единственный момент, на который стоит обратить внимание — явное указание командного интерпретатора #!bin/bash в /etc/init.d/srv1cv83. Если этого не проделать, 1С наверняка начнет тупить, глючить, и вообще откажется запускаться.
Теперь возвращаемся из мрачного мира консоли в родные окна. Поставил платформу 1С.Предприятие 8.3 соответствующего релиза, при установке добавил средства администрирования. Через оснастку “Администрирование серверов 1С” подключился к серверу, создал кластер и в нем базу данных. Ерзая от нетерпения, запустил Конфигуратор, и подключение прошло на радость быстро и безболезненно.
При активации лицензии указал адрес и порт сервера в разделе “Дополнительно”. Это важно. Иначе лицензия установится на тот комп, откуда производилась настройка.
Предчувствуя скорую развязку, залил резервную копию рабочей базы на сервер. Собрался уже было открывать пивас. И тут началось самое веселье. Тонкий клиент отказался запускаться. Его величество не обнаружило библиотеки с адским названием libfontconf.so и libWand.so, и предложило немедленно пойти прочь. Странно, ведь про установку дополнительных пакетов для работы 1С я прочитал, все рекомендации выполнил. Какого банана ему еще надо? Стал искать на сервере эти файлы, попутно освоил синтаксис команды find. Нашел, много думал. Ничего не придумав, стал гуглить. После километров прочитанных форумов, и десятков поисковых запросов, удалось выяснить, что такая беда постигла очень многих моих предшественников, но однозначного решения у проблемы нет. Причина крылась в том, что разработчики 1С не особо охотно следят за обновлениями Linux, и рекомендуемые для установки пакеты, могут запросто положить нужные файлы совсем не туда. Да и названия файлов вполне могли поменяться. Пришлось устанавливать недостающие библиотеки через такой хитрый дымоход, что я несколько раз пожалел, что связался с этим сервером.
Махровые линуксоиды естественно поднимут меня на смех — мол, “это же элементарно, Ватсон, вы дебил!” Но я считаю, что для дебюта все равно получилось довольно успешно. Кроме того пилить дрова лобзиком, и забивать шурупы молотком — развлечение сомнительное.
После того, как в базу все же удалось зайти, было решено прогнать сервер тестом производительности. Для этого я воспользовался нагрузочным тестом Гилева. Слабых мест он не показывает, просто оценивает индекс производительности. Результаты не сильно обрадовали, но и не разочаровали. Первый этап показал результат выше оценки “Удовлетворительно”, второй зашкалил за “Отлично”. Имея эти данные, можно вернутся к конфигурационным файлам сервера, и плавно экспериментируя с параметрами, добиться оптимального результата. Чем я собственно и занялся. После экспериментов с параметрами effective_cache_size и temp_buffers, платформа зашевелилась повеселее. Дело в том, что в разных источниках содержится разная информация по этим параметрам. К примеру 1С рекомендует устанавливать temp_buffers в 256МБ, а на профильных форумах встречаются рекомендации выставлять эту настройку из расчета 1/20 от объема оперативной памяти сервера.
Итоговые результаты будут, когда сервер перейдет в “боевой” режим, и к нему потянутся виртуальные щупальца рабочих станций. На данном этапе задача выполнена, жертв нет, ни один сервер не пострадал.
Права доступа VS Печать отчета
Столкнулся сегодня с не совсем обычным случаем в практике распедаливания проблем с 1С.
Анамнез: Звонит девочка-кассир, и тоненьким голосом слезно просит распечатать ей отчет о розничных продажах. За нераспечатанный отчет её грозится побить директор, а вместо нужной формы на экран выводится отчет кассира-операциониста.
Начинаем раскуривать эту беду. Под административной учетной записью без проблем распечатываю искомый отчет, спасая жизнь бедной девушке. Смотрим в чем беда. Воевать предстоит с этой вот кнопкой, обзываемой в кругу эльфов и программистов “Печать по умолчанию”.
При нажатии на нее из-под учетной записи кассира действительно выводится печатная форма, и действительно не та, что требуется.
А открыть сам отчет, чтобы просто поменять себе то, что будет распечатываться, кассир не может. Их директор держит своих сотрудников в ежовых рукавицах, и обращался к нам когда-то за нашим решением Права доступа. Вещь в умелых руках нужная и полезная, но можно и переборщить с затягиванием гаек. Выглядит это так:
Для заранее созданного профиля настроек заполняется таблица, в которой указывается сколько дней сотрудник сможет читать, создавать, проводить и т.д. любой тип документов, справочников и отчетов. По умолчанию таких детальных ограничений Управление торговлей не умеет.
Конкретно в этом клиническом случае права были выставлены аккурат как на скриншоте. А это значит, что если кассир замешкается, и не распечатает отчет ровно в день его формирования, войти в него для простого выбора печатной формы (что казалось бы тут криминального) он уже не сможет. После — розги, и стояние на горохе в углу.
Сложившуюся экосистему менять не стал, раз уж так заведено в организации. Добавил один день на чтение этих отчетов под административной учеткой, зашел под всеми кассирами, и выбрал печатную форму по умолчанию для каждого горемыки. Вернул права на место.
Ни один кассир при проведении этой спецоперации не пострадал, жертв и разрушений нет.