🔤🔤🔤 8.3.27.1989 (возможно что и 1964) Ошибка при запуска фонового

Если кто-то собирается обновиться на свежую 8.3.27, то нужно подготовиться!

Есть очень критичная проблема:
При запуске Фонового задания от пользователя, у которого не установлена возможность авторизации средствами 1С по логину и паролю, будет выходит ошибка как на скриншоте.

Такие Фоновые запускаются при Длительных операциях. например:
- Поиск в общем поле поиска
- Формирование ОСВ и т.д.

Есть зарегистрированная ошибка:
https://bugboard.1c.ru?state=prj-plt8gen-er-70139365

❗️Если обновление всё таки необходимо, то заранее проставьте у всех пользователей возможность авторизации средствами 1С и задайте очень большой и сложный пароль. Вводить его не придётся и пользователям его сообщать не надо.

1️⃣🔤 Сервис проверки ТНФ

Всем привет!

10 лет к ряду постоянно сталкиваемся с некорректным пониманием того, как же на самом деле работают Требования Назначения Функциональности в кластере Лучшей в мире платформы 1С!

Поэтому вместе с командой РКЛ-ИнфоСофт написали сервис по проверке ТНФ на технологии 1С.Элемент и предлагаю вам им воспользоваться

https://lk-rkl.is1c.ru/tnf-checker-free

Что он умеет:
1. Анализировать файл реестра вашего кластера (никакие данные никуда не сохраняются, так что не переживайте!)
2. Визуализировать структуру вашего кластера со всеми ТНФ
3. Показывать как будет назначен сервис с учётом Объекта требования, имени базы и дополнительных параметров.
4. Можно выключать/включать сервера и затем проверять назначение
5. Можно добавлять/изменять/удалять ТНФ и опять проверять как сработает требование при новой структуре
6. Можно менять порядок следования ТНФ

❗️Сервис написан на основании описания ИТС и нашем опыте!

Если вы нашли неточность в определении пути требований сервисом в вашем кластере, то:
1. Пришлите мне в личку файл реестра кластера почистив его от паролей админов и субд.
2. Опишите в чём неточность

Мы всё посмотрим, и либо исправим неточность либо объясним почему ТНФ будут работать именно так как показал сервис.

Надеюсь сервис окажется очень полезным, так как красивый он уже 😄

Чуть не забыл главное!
Список требований отсортирован как и список баз! 😄

🔤🔤🔤 Когда фоновый процесс обновления статистики может стать виновником блокировок и что с этим можно сделать?

Не смотря на то что в целом Автовакуум это неблокирующая операция, всё таки есть возможность получить таймаут на блокировке...

Тонкость состоит в том что автовакуум, даже когда он пришёл только лишь обновить статистику накладывает блокировку на схему БД.

Т.е. нельзя во время работы автовакуума с таблицей менять в ней состав колонок или удалять таблицу целиком.

И тут нам в мире 1С очень "повезло" так как это же операции реструктуризации как версии 1 так и версии 2.

В итоге мы при реструктуризации можем получить очень неприятную ситуацию:
1. Автовакуум (автообновление статистики) на таблице занимает более 20 сек
2. Реструктуризация как раз касается этой самой таблицы
3. Через 20 сек после попытки начала реструктуризации этой таблицы получаем ошибку таймаута блокировки и реструктуризация прерывается.

Что делать?

Если у вас планируется реструктуризация большой таблицы. а обновление статистики более 20 сек может быть только на очень приличной по объёму и количеству строк таблицы, то есть 2 варианта:

1. Отключить на время реструктуризации автовакуум на сервере:

ALTER SYSTEM SET autovacuum = off;
select pg_reload_conf();

после реструктуризации включить обратно:

ALTER SYSTEM SET autovacuum = on;
select pg_reload_conf();

либо, если по умолчанию автовакуум включен был, то

ALTER SYSTEM RESET autovacuum;
select pg_reload_conf();

2. Отключить автовакуум на конкретной таблице (_inforg38) на время реструктуризации

ALTER TABLE IF EXISTS public._inforg38 SET ( autovacuum_enabled = false);
select pg_reload_conf();

после реструктуризации включить обратно:

ALTER TABLE IF EXISTS public._inforg38 SET ( autovacuum_enabled = true);
select pg_reload_conf();

Хочется назвать это костылём, но большие таблицы/базы не живут без таких оптимизаций 😄

Ну и не лишним будет напомнить, что канал есть в MAX

🔖 Как не дать конфигурации 1С положить сервер: профили, кластеры и логи

Платформа 1С не превращает произвольный доверенный серверный код в идеальную песочницу. Но она умеет: ограничивать опасные возможности, уменьшать радиус поражения, разделять полномочия и давать нормальные инструменты расследования

➡️ Что вообще считать опасным кодом в 1С
Вредоносный, чрезмерно доверенный, привилегированный, ресурсоубивающий.
➡️ Что реально ограничивает действия кода
Безопасный режим, профили безопасности, запрет опасных возможностей.
➡️ Что уменьшает ущерб, если код уже плохой
Разные пользователи ОС для компонентов кластера, разнесение центрального и рабочих серверов, выделенные сервера под тяжёлые/подозрительные сценарии, управление потреблением ресурсов.
➡️ Что управляет доступом, но не sandbox’ит код
Разделение админов, внешнее управление сеансами.
➡️ Что помогает после пожара
История данных, журнал регистрации, техжурнал, мониторинг кластера, дампы.
➡️ Что на счет отладки
Отладка на сервере или как дать злоумышленнику исполнить произвольный код

Приглашенный гость:
😶‍🌫️ Антон Дорошкевич, Руководитель проектов, ИнфоСофт

😉 Стрим на YouTube
😄 Запись после стрима
🥰 Запись после стрима

🗓 Дата: 17 марта в 19:00

Выложены записи:
😉 Запись на YouTube
😄 Запись на VK Video
🥰 Запись на Rutube

1️⃣🔤 Мифы о DT

Достаточно часто в работе даже с КОРП-клиентами сталкиваемся с тем, что на выгрузку/загрузку DT возлагаются неоправданные надежды основанные на давних мифах…

Давайте разберём некоторые из них:

1. Выгрузка dt происходит в тот каталог куда мы указали.
В итоге – да, но сам процесс выгрузки выглядит иначе, а именно:
- конфигуратор выгружает базу в файл с расширением .n1 и выгрузка эта происходит в каталог временных файлов пользователя процесса rphost
- после окончания выгрузки файл переименовывается и перемещается в каталог, который мы указали при выгрузке
❗️Для успешной выгрузки базы необходимо обеспечить достаточно места не только в каталоге выгрузки, но и в каталоге временных файлов пользователя процесса rphost

2. Большую базу невозможно выгрузить в dt
Тут всё просто – точно возможно, если прочитать п.1 и обеспечить достаточно места.
А вот сколько места – это вопрос интересный, но в среднем dt занимает в 8 раз меньше чем объём базы данных.
Если у вас PostgreSQL, то dt будет занимать примерно столько же сколько резервная копия базы, созданная через pg_dump, так как dt как и pg_dump не содержит индексы.

3. Выгрузка/загрузка dt поможет убрать ошибки учёта или «красные» ошибки
Точно нет, тут даже обсуждать особо нечего…
А вот пересчёт итогов, причём даже в пользовательском режиме без необходимости монопольного доступа, как в случае пересчёта через ТИИ, действительно может починить ОСВ (почему итоги могут испортиться – это отдельная история)

4. Выгрузка/загрузка dt пересчитает итоги
И опять нет, такое было только в 1С 7.7

5. После выгрузки/загрузки dt база станет работать быстрее
Тут уже интереснее – база может начать работать быстрее по двум причинам:
- Поскольку таблицы создались заново, то их распухание и фрагментация стремятся к нулю
- Индексы так же создались заново

Но всё то же самое можно сделать средствами PostgreSQL выполнив неблокирующий reindex concurrently (вместо реиндексации в ТИИ или dt) или выполниd vacuum full (вместо реструктуризации в ТИИ или dt)

В MS SQL распухание таблиц редкое явление и практически не влияет на скорость работы, а неблокирующую реиндексацию можно сделать с галкой «в сети»

6. Имена таблиц на СУБД останутся такими же как у базы с которой был выгружен dt
Это не так, имена нумеруются согласно ИТС и никакой гарантии что они останутся такими же нет.
Например, в базе было 3 справочника с именами на СУБД _Reference1, _Reference2, _Reference3
Затем один справочник удалил (_Reference2) и добавили другой (_Reference4)/
В итоге у нас в базу на уровне СУБД 3 справочника - _Reference1, _Reference3, _Reference4
При загрузки dt, выгруженного с той базы имена справочников будут пронумерованы с начала и идти по порядку и мы получим в новой базу имена - _Reference1, _Reference2, _Reference3.

7. Есть один очень интересный сценарий, когда именно выгрузка/загрузка dt ускорит базу кардинально.

Для этого изначальная загрузка dt в базу должна была пройти не до конца и не создать все индексы, при этом загрузив все данные.
В этом случае всё будет работать, но медленно.
Реиндексация ни средствами ТИИ ни средствами СУБД не поможет, так как эти команды реиндексируют только уже существующие на СУБД индексы, и не формируют новые согласно Схеме базы данных 1С.
Такой сценарий нужно предварительно расследовать, чтобы понять что действительно состав индексов на СУБД не соответствует схеме бд 1С, например развернув чистую конфигурацию на тестовой базе получить состав таблиц и индексов и сравнить с рабочей базой хотя бы по количеству.

8. Ну и наверное самый старый миф – является ли dt резервной копией?
Тут есть много споров, а есть рекомендации 1С https://its.1c.ru/db/metod8dev/content/2922/hdoc

Где описаны некоторые недостатки резервного копирования с помощью dt, основными из которых по моему мнению является то, что необходимо обеспечить монопольный доступ к базе и однопоточность создания dt.

Но с другой стороны, только монопольный доступ гарантирует бизнес-целостность резервной копии, а копия снятая средствами СУБД – это консистентная только на уровне транзакций СУБД копия.

1️⃣🔤 🔤🔤🔤 Как ускорить загрузку DT в PostgreSQL

Давным давно, когда Postgres был мало знаком с 1С и их отношения только развивались DT в Postgres загружался гораздо дольше чем в MS SQL.

Те веремена прошли, а имидж остался.

Сегодня расскажу как ускорить загрузку DT в PostgreSQL, какие настройки нужно для этого поменять на PostgreSQL и что для ускорения загрузки было сделано со стороны лучшей в мире платформы 1С.

Этапы загрузки DT:
1. Создаём таблицы согласно схеме БД (константы, справочники, регистры и т.д.)
2. Заполняем таблицы данными
3. Создам индексы на таблицах, согласно схеме БД

Долгое время загрузка DT была однопоточной и в те времена (до версии 8.3.19) и главное падение скорости у PostgreSQL было на третьем этапе - Создание индексов.
Падение скорости было обусловлено тем, что MS SQL умел создавать индексы многопоточно, а PostgreSQL нет

Но теперь и 1С умеет многопоточно грузить DT и PostgreSQL умеет многопоточно создавать индексы и казалось бы это и есть максимальная скорость, но нет))

Дальше посмотрим какие настройки PostgreSQL могут ещё ускорить создание индексов и как сбалансировать скорость загрузки DT с мощностью сервера СУБД,

maintenance_work_mem - объём оперативной памяти в том числе и для создания индекса
max_parallel_maintenance_workers - количество параллельных потоков создания индекса

На время загрузки dt можно временно кратно увеличить эти значения

ALTER SYSTEM SET maintenance_work_mem = 2GB;
ALTER SYSTEM SET max_parallel_maintenance_workers = 2;
'select pg_reload_conf();

а после загрузки DT вернуть в исходное состояние

'ALTER SYSTEM RESET maintenance_work_mem;
'ALTER SYSTEM RESET max_parallel_maintenance_workers;
'select pg_reload_conf();

Тут важно подобрать параметры так, чтобы выставлять их минимально достаточными для максимальной скорости загрузки.
Какие именно будут параметры именно в вашем случае покажет только тестирование.
Но учтите, что количество потоков загрузки DT из конфигуратора = кол-ву ядер на сервере 1С.
Т.е. если у нас 12 ядер на сервере 1С и мы выставили параметры параллелизма в 2 и объём оперативной памяти в 2 ГБ, то мы должны обеспечить на сервере СУБД минимум 2*12=24 ядра и 2*12=24ГБ памяти только для этой процедуры.

Указать количество потоков загрузки dt можно только в пакетном режиме запуска конфигуратора с помощью параметра -JobsCount

Особо заметный эффект от настроек и балансировки будет, если в базе есть большие таблицы, как и в целом любой параллелизм хорошо себя показывает именно на больших данных, а на малых скорее вреден чем полезен.

1️⃣🔤 🔤🔤🔤 Копия базы данных 1С теперь работает и на репликах PostgresPRO

Это небольшой анонс серии постов, в один никак не смог уложить.

На прошлой неделе мы командами ИнфоСофт и Постгресс Профессиональный закончили тестирование работы физической реплики с механизмом копии базы данных 1С.

Раньше работа Копия БД была невозможна с физическими репликами PostgreSQL, так как на реплике нельзя было создавать временные таблицы и не только.

А ведь очень хотелось использовать реплики отказоустойчивого кластера для читающей нагрузки, а не только для отказоустойчивости.

Теперь это стало реальностью и позволит реализовать очень интересные сценарии работы высоконагруженных систем, точечно уведя читающую нагрузку на реплики.

И отдельное удовольствие состоит в том, что для направления выполнения отчёта на Копию БД не требуется разработчик 1С и его время, а требуется всего лишь пара кликов от пользователя 1С с достаточными правами.

1️⃣🔤 Как заваривать ТЖ

Довольно частый список вопросов у тех, кто начал нелёгкий путь разбора непонятных ситуаций с производительностью 1С или с непонятным поведением лучшей в мире платформы 1С:
- как настроить ТЖ?
- какие события там есть и что они значат?
- как это всё читать и желательно понимать?

Начнём по порядку и ответим сразу на оба первых вопроса:

Как настроить ТЖ, какие события там есть и что они значат?
Есть два отличных источника информации - это ИТС и статья на insoftart.
Конечно же сразу там ничего не понятно и понимание придёт только с опытом расследования конкретных ситуаций, когда вы будете читать ТЖ как Нео Матрицу...

Минимально необходимую и достаточную для большинства ситуаций настройку тж, основанную на опыте нашей команды РКЛ я для вас собрал ниже:
ТЖ для сервера 1С на Windows, платформа <= 8.3.24
ТЖ для сервера 1С на Windows, платформа >= 8.3.25
ТЖ для сервера 1С на Linux, платформа <= 8.3.24
ТЖ для сервера 1С на Linux платформа >= 8.3.25

В версиях для платформ >= 8.3.25 добавлен параметр format = "json", что сильно ускоряет разбор тж автоматическими средствами (их очень много, каждый выберет себе по вкусу), но в тоже время журнал становиться сложно человекочитаем.
Поэтому если планируете смотреть журнал вручную, то лучше не собирать его в json.

Как проверить что ваша настройка ТЖ корректна в части структуры?
Просто откройте файл logcfg.xml в браузере - у вас не должно появится никаких сообщений об ошибках и вы должны увидеть обычную xml структуру.

Как это всё читать и желательно понимать?
Это самый сложный вопрос и на него нет какого-то универсального и простого ответа.
К сожалению, тут работает только насмотренность ТЖ и опыт расследования.
На первоначальном этапе сильно помогут Инструменты разработчика и встроенный в них парсинг ТЖ.
Там нет никаких подсказок что делать с полученной из ТЖ информации, но она уже структурирована, сгруппирована и отсортирована, что сильно облегчает понимание.

Что ещё можно сделать, когда обычные настройки ТЖ не помогают?

Настроить сбор полного ТЖ с фильтром по базе или по базе и пользователю.

<log location="C:\TJ\full" history="2">
  <event>
  <ne property="name" value=""/>
  <eq property="p:processName" value="ИмяБазы"/>
  <eq property="Usr" value="ИмяПользователя"/>
  </event>
 <property name="all"/>  
</log>

❗️Даже такую таргетированную настройку не надо постоянно держать на серверах, так как она создаёт приличную нагрузку и может негативно влиять на производительность системы.
Настроили - воспроизвели/дождались проблему/мы, убрали настройку - сидим читаем.
Так же иногда полезно включить полный ТЖ на клиенте, настройка его аналогична, но там не имеет смысла фильтры по базе и имени пользователя, их просто удаляем из настройки.

Напоминаю про канал в MAX, мало ли...

1️⃣🔤 8.5.4 - революция в платформе

30 апреля вышла уже "настоящая" 8.5, а не технический клон 3.27 с возможностью нового интерфейса.

В платформе очень много новшеств - и работа кластера, и метрики, и работа с СУБД, и работа с копиями баз данных, и патчи для клиенстких приложений, и ещё и ещё и ещё...
Читайте, наслаждайтесь, готовьтесь к переходу - ссылка с описанием изменений и новой функциональности.

Ну и конечно, долгожданный менеджер лицензий, который по моему мнению снимет почти все вопросы и неудобства, если они были в работе с программными лицензиями.
Читайте, теструйте, пробуйте - вот ссылка на итс с описанием.

В свою очередь буду делиться тем, что будем использовать на практике.

Напоминаю про канал в MAX, мало ли...

1️⃣🔤 Менеджер лицензий

Протестировали Менеджер лицензий:
1. Работает! Выдаёт и программные и USB лицензии. Ограничения работают что на уровне ip что на уровне гибких ограничений по типу клиентского приложения, пути до базы и т.д.
Всё достаточно удобно и наглядно.

2. ❗Работает только с клиентами на платформе 8.5.4! Ни 8.5.1 ни 8.3.27 не могут подключиться к Менеджеру лицензий.
К сожалению, не нашли такое ограничение в документации, так что пока ориентируемся на результаты теста.