Антон Дорошкевич | маяк в мире 1С и СУБД

Pg_dump это не только ценный бэкап, но и средство диагностики целостности базы На этой неделе столкнулись с очень интересной проблемой. Проявлялось это так: - 1С практически не шевелится - Если удалось зайти в 1с, то при совершенно разных операциях получаем ошибки СУБД с разным набором таблиц, которые почти ни о чём не говорят, кроме как что-то пошло не так - Нагрузка ЦПУ на сервере PostgreSQL под 100% Запрашиваем список активных сессий на СУБД

select * from pg_stat_activity

И получаем список транзакций. Которые длятся минуты и десятки минут с текстом:

select * from public._scheduledjobs...;

и т.д. Попытка завершить транзакции средствами СУБД ни к чему не приводит. Тем временем прод стоит, паника нарастает… Всё это происходит на PostgresPRO Enterprise с встроенным кластером BiHA. Система определяет что мастер не отвечает и перекидывает всю нагрузку на другую ноду кластера – всё совершенно корректно, как доктор прописал! И что мы видим? – Буквально за 10 минут теперь и "новый мастер" так же уходит в нагрузку по ЦПУ в 100%. Снимаем отладочную информацию со всех процессов мастера и «нового» мастера командой

kill <pid> -40

для ТехпПоддержки PostgresPro. И хоть я и очень не люблю так делать, но аварийно останавливаем PostgreSQL через

kill <pid> -9

и на мастере и на «новом» мастере. Блокируем 1С. Стартуем PostgreSQL. И для быстрой диагностики запускаем vacuum analyze only в несколько потоков на базе. И опять получаем «зависшие» транзакции analyze на разных scheduledjobs… Поясню – analyze читает не все данные в таблице, а только количество строк = 300*default_statistic_target. Обычно default_statistic_target = 100, т.е. мы читаем только 30 000 строк в таблице, и даже при этом уже получаем зависание системы. Вот это уже страшно… Опять снимаем crash_info, рестартуем службу Postgres и начинаем расстраиваться… Всё больше подозрений на битые страницы данных… И тут встаёт вопрос, как быстро проверить все данные в базе? Ответ – pg_dump, ведь по сути это select * по всем таблицам базы и сбор информации о DDL схемах как самих таблиц, так и индексов. Но, база не маленькая и дамп будет формироваться достаточно долго… Вспоминаем что можно вместо сохранения дампа на диск отправить его в «чёрную дыру» /dev/null, но при этом сохранив логи самого процесса дампа.

pg_dump -h 127.0.0.1 -p 5432 -U postgres -d ERP> /dev/null 2> dump.log

Такой дамп формируется намного быстрее. Запускаем и получаем в логе сообщение: pg_dump: ошибка: ошибка при выполнении запроса: ERROR: index "pg_attribute_relid_attnum_index" contains unexpected zero page at block 2349 ПОДСКАЗКА: Please REINDEX it. Вот это поворот! Что-то не так с данными системной таблицы атрибутов.. Ну чтож, есть подсказка, давайте ей и воспользуемся:

REINDEX TABLE pg_catalog.pg_attribute;

И после этого опять запускаем analyze, чтобы проверить починилось ли и да, база починилась, analyze прошёл. Запускаем 1С – проверяем, всё работает. Запускаем пользователей и естественно у них «такая же нога, но болит!..», а именно, при различных операциях получаем ошибку СУБД с текстом:

ERROR: heap tid from tuple … offset 204 of block 4 in index “pg_namespace_nspname_index”…

Запускаем

REINDEX INDEX pg_namespace_nspname_index;

- ошибка ушла. Причина по которой разрушились системные индексы пока ещё выясняется. ❗️Сама история говорит о том, что базу надо периодически регламентно проверять на целостность, а лучше не базу, а весь кластер командой: pg_dumpall -h 127.0.0.1 -p 5432 -U postgres > /dev/null 2> dump.log При этом лог будет пустой, если дамп не обнаружит ошибок. Если же хочется иметь лог всей работы дампа в любом случае, то команда будет такой:

pg_dumpall -h 127.0.0.1 -p 5432 -U postgres -v > /dev/null 2> dump.log

Ну и на всякий случай канал в MAX https://max.ru/explorer1c

Смена dbowner у базы 1С на PostgreSQL Согласно check-list по настройке 1с рекомендуется «для каждой продукционной информационной базы создавать отдельного пользователя». Так же Информационная безопасность тоже требует чтобы мы работали под уникальными пользователями с каждой базой и при этом у этих пользователей нужен только минимально необходимый набор прав. Казалось бы, что может быть проще? Ну выполним аналог команды MS SQL

EXECUTE sp_changedbowner 'ERP';

и готово. Но оказалось что всё не так просто, а иногда и невозможно… ❗️Так повелось у многих, что создаём базы не просто из пользователя с правами SUPERUSER, а именно из под пользователя postgres. Какие есть пути решения есть: 1. Сменить владельца базы

ALTER DATABASE "ERP" OWNER TO "ERP";

Получаем следующие эффекты: ❗️Владельцем таблиц остаётся postgres. Ок, мы не робкого десятка и умеем писать скрипты... В цикле бежим по всем таблицам и выполняем

ALTER TABLE OWNER TO

❗️Но при запуске 1С пишет «База данных непригодна для использования»… Дело в недостаточном разрешении для lc_messages Ок, выполняем

grant set ON PARAMETER lc_messages to " ERP ";

❗️И всё равно при запуске базы получаем:

42501: ERROR: must be owner of extension mchar

🚫И вот тут первое нерешаемое – назначить владельца для расширения невозможно. 2. REASSIGN OWNED - Команда затрагивает только объекты в текущей базе данных. Обычно её нужно выполнять в каждой базе данных, которая содержит объекты, принадлежащие удаляемой роли. Как раз то что нужно!!! Если бы мы изначально не создали базу из под пользователя postgres Команда

REASSIGN OWNED BY postgres TO ERP

❗️– не выполнится, с ошибкой: Изменить владельца объектов, принадлежащих роли postgres, нельзя, так как они нужны системе базы данных. ⛔️Всё, тупик. К сожалению для баз созданных из под postgres изменить полноценно владельца невозможно! И тут решение только одно – dump/restore базы во вновь созданную, владельцем которой назначен другой пользователь без прав SUPERUSER. Ну а на будущее – после разворачивания сервера PostgreSQL нужно первым же делом создать себе нового пользователя с правами SUPERUSER и работать под ним, а Супер-SEPERUSER postgres оставить на крайний случай прописав ему например доступ только по 127.0.0.1 в pg_hba.conf Ну и на всякий случай канал в MAX https://max.ru/explorer1c

Всем привет! 18 июня, 17-30 Новосибирск, Ядринцевская 21 1С митап CDEK https://cdek-meetup.timepad.ru/event/4010555/ Приходите, будет интересно! После выступления отвечу на все вопросы, какие накопились!)

Почему добавление ресурсов может привести к «слёту» программной лицензии 1С Мы же с вами чётко помним, что программная лицензия «слетает» только при удалении, а не при добавлении устройств, которые были в системе на момент активации лицензии. Но при этом часто видим историю, когда именно добавление ресурсов виртуальной машины приводит к тому что лицензия становится неактуальной. Например, нам понадобилось увеличить объём оперативной памяти виртуальной машины – кажется, что это почти тоже самое что добавить в физический сервер плашку оперативки. «Да, но нет» - часто, чтобы увеличить объём памяти гипервизор виртуальной машины меняет ей модель процессора, и в итоге мы получаем не только добавление памяти, но и смену ЦПУ. То же самое касается добавления ядер или увеличения суммарной герцовки ЦПУ у виртуалки, в итоге мы получаем именно изменение (удаление старого ЦПУ и добавление нового). Ситуацию усугубляет то, что после подобных изменений 1С может спокойно запуститься и работать видя все лицензии. Администратор уверен, что значит всё прошло хорошо и переактивировать ничего не требуется. А потом в «неожиданный» момент система перестаёт воспринимать лицензии. Такое поведение возможно, так как параметры привязки лицензии к параметрам ПК проверяются не чаще одного раза в сутки. Это не значит что у нас есть 24 часа после любых изменений! Это значит что у нас есть сколько-то времени (сколько неизвестно) до следующей проверки параметров. ❗️Ну и наконец, есть ещё один очень важный момент! Как я написал выше «мы же с вами чётко помним…», так вот, оказывается что мы помним это со времён версии Лучшей в мире платформы 1С 8.3.11!!! Напомню, что последний релиз этой ветки вышел чуть более 8 лет назад 13/05/2018 года. А уже с версии 8.3.12 описание поменялось на «Если в процессе работы будет изменен хотя бы один из ключевых параметров, то будет необходимо повторно активировать программную лицензию (с использованием нового пин-кода). Параметры компьютера опрашиваются не чаще одного раза в сутки.». Вот ссылка , на ИТС для 27 версии и ИТС для 12 версии платформы ветки 8.3. ну и на всякий случай для версии 8.5.4 Итак, правильный порядок действий при планировании изменений параметров железа и при самом изменении этих параметров: 1. Проверяем что у нас есть запасной пин-код для всех программных лицензий, активированных на данном ПК. Если у вас нет пин-кода, то его можно или получить на сайте https://portal.1c.ru/support/license в онлайн режиме или запросить у 1С по почте lic@1c.ru. Количество пин-кодов не ограничено, но получить можно только один пин-код за один раз. Получить 10 шт на всякий случай не выйдет. 2. Точно знать какой пин-код активирован на данный момент, его будет необходимо указать при активации нового 3. Провести изменение оборудования 4. Переактивировать все программные лицензии

Как понять хватает ли памяти серверу PostgreSQL Это очень интересный вопрос, так как на него нет ни простого ни точного ответа… Для начала нужно разделить потребляемую память на 2 вида: ▫️ Память на соединение ▫️ Память на весь сервер Сначала давайте попробуем понять, как мониторить хватает ли нам памяти на соединение? Для ограничения потребления памяти в сеансе используется 3 параметра temp_buffers, work_mem и maintenance_work_mem. Для отслеживания достаточности у нас есть на данный момент только один инструмент – логирование имён и размеров временных файлов, которое включается параметром log_temp_files. Итак, допустим у нас temp_buffers = 128 MB, work_mem = 256 MB, а maintenance_work_mem = 512 MB тогда параметр log_temp_files лучше всего задать равным меньшему из этих значений, т.е. log_temp_files = 128 MB. Тогда, в логах будет может появиться запись вида:

СООБЩЕНИЕ:  временный файл: путь "base/pgsql_tmp/pgsql_tmp33513.6.sharedfileset/0.0", размер 317964288

Как видно, был создан временный файл размером 317 964 288 байт. А ниже этой строчки будет строка с текстом запроса, который вызвал создание временного файла такого размера:

ОПЕРАТОР:  CREATE UNIQUE INDEX _inforg2483_2 ON public._inforg2483 USING btree (_fld12588, _fld4134rref, _fld4133_type, _fld4133_rtref, _fld4133_rrref);

И вот тут придётся соотносить смысл запроса с параметрами, ограничивающими потребление оперативной памяти на сеанс, в данном примере этот временный файл был сформирован в оперативной памяти, так как параметр maintenance_work_mem больше чем размер файла. А дальше делать вывод – повышать ограничение, если это не разовая, а массовая операция и при этом оперативки ещё много, а диски уже взывают о помощи. Или пренебречь разовыми выплесками и оставить настройки как есть. С другой стороны, если за релевантный для вашей системы период в логах нет таких записей, то стоит понизить значение параметра log_temp_files, например в 2 раза и собрать информацию. Затем, возможно принять решение об уменьшении параметров, так как оперативки на сервере уже не хватает. Теперь давайте посмотрим что у нас с памятью на сервер? За объём выделенной памяти отвечает параметр shared_buffers, который по умолчанию рекомендуется ставить в 25% от всей оперативной памяти сервера. Тут одновременно и сложнее и интереснее… В анализе нам очень поможет расширение pg_buffercache. Оно работает на таблицу, поэтому перед использованием необходимо выполнить команду создания расширения: CREATE EXTENSION IF NOT EXISTS pg_buffercache; После этого мы можем узнать общее состояние буфера командой pg_buffercache_summary(); Ну и тут будет сразу видно, если у вас число неиспользуемых буферов buffers_unused достаточно большое относительно числа используемых buffers_used, то видимо переборщили с количеством кэша и его можно уменьшить. ❗️Важное замечание – параметр shared_buffers задаётся в байтах, а значения полей buffers_unused и buffers_used выдаётся в количестве буферов, один буфер = 8КБ. ❗️Ну и наконец, с помощью этого расширения мы можем узнать какие именно таблицы базы и сколько именно буферов в общем кэше занимают. Это можно получить следующим запросом на каждую базу, который выдаст 20 таблиц-лидеров потребления кэша:

SELECT current_database() AS database_name, CASE WHEN d.relname IS NULL THEN c.relname ELSE d.relname END AS table_name,
count(*) AS buffers_size, cast (100*count(*)/cast ((SELECT buffers_used + buffers_unused FROM pg_buffercache_summary()) as numeric) as numeric(5,2)) AS percent_buffers_used
             FROM pg_buffercache b JOIN pg_class c
             ON b.relfilenode = pg_relation_filenode(c.oid) 
    LEFT JOIN pg_class d
    ON c.oid = d.reltoastrelid 
    AND b.reldatabase IN (0, (SELECT oid FROM pg_database WHERE datname = current_database()))
             GROUP BY CASE WHEN d.relname IS NULL THEN c.relname ELSE d.relname END
             ORDER BY 3 DESC
             LIMIT 20;

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

1️⃣🔤 Менеджер лицензий Протестировали Менеджер лицензий: 1. Работает! Выдаёт и программные и USB лицензии. Ограничения работают что на уровне ip что на уровне гибких ограничений по типу клиентского приложения, пути до базы и т.д. Всё достаточно удобно и наглядно. 2. ❗Работает только с клиентами на платформе 8.5.4! Ни 8.5.1 ни 8.3.27 не могут прдключиться к Менеджеру лицензий. К сожалению, не нашли такое ограничение в документации, так что пока ориентируемся на результаты теста.

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

Катастрофическое падение скорости при обновлении В последнее время флагманские конфигурации 1С выпустили достаточно «тяжёлые» обновления ERP, УХ, KA и т.д. Особенностью этих обновлений, помимо большого количества реструктуризаций объектов так же является большое количество монопольных обработчиков после обновления (это когда идёт «градусник» в пользовательском режиме) и в ход в 1С заблокирован. Мы в рамках инцидентов РКЛ уже несколько раз столкнулись с тем, что процесс этого монопольного обновления затягивается на несколько часов или даже суток! Систематизация проблемы показала, что она существует только при использовании MS SQL и при этом полностью отсутствует на PostgreSQL и там этот этап проходит буквально за минуты. Дальнейший анализ показал, что проблема возникает не всегда и не у всех – что с одной стороны сильно затрудняет её решение (так как по классике – такая же нога и не болит), с другой стороны есть что с чем сравнить (тех у кого быстро и тех у кого медленно, при сопоставимом количестве записей в регистрах – чтобы ощутить проблему, этих записей должны быть миллионы и десятки миллионов). Разбор процедур обработчика показал, что происходит регистрация к изменению всех строк определённых регистров для дальнейшей постобработки в фоновом режиме, когда вход пользователей уже возможен, но функционал может быть ограничен. Тонкость регистрации изменений состоит в том, что сначала проверяется есть ли уже такие зарегистрированные изменения (на уровне СУБД это запрос SELECT), и если таковых нет, то происходит уже сама регистрация (на уровне СУБД это запрос INSERT). И по Технологическому журналу 1С мы получали чудовищную деградацию скорости именно при SELECT, если по началу он длился тысячные доли секунды, то затем вырастал до десятков секунд. Разбор плана запроса показал что статистика чудовищно ошибается в предположении сколько строк уже зарегистрировано, например статистика предполагает что их 638 шт, а по факту оказывается 3 564 175 шт. А у тех у кого обновление было быстрым – статистика не ошибалась… В итоге было обнаружено, что всему виной отключенный Автоматический расчёт статистики на базе (аналог autovacuum_analyze в PostgreSQL) – на картинке видно где это включается. Причина отключения достаточно известна – есть прекрасная статья, конкретно отключение автообновление статистики начинается с заголовка «Нестандартные ожидания на блокировках». Что делать? ❗️Выключать автообновление статистики нужно только если вы фиксируете ожидания с типом LCK_M_SCH_S. Придётся теперь следить и за этим параметром, и включать автоматический расчёт статистики, если вы ожидаете огромный объём регистрации к изменению. Ну а при обновлении конфигурации – нужно включать автоматический расчёт на постоянной основе, просто как часть процесса и только после окончании всех процессов обновления, в том числе и фоновых уже выключать автообновление статистики, если на вашей базе это необходимо.

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>

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

1️⃣🔤 🔤🔤🔤 Копия базы данных 1С на репликах PostgresPRO Итак, давайте сначала определимся с целью. Цель: При наличии физической реплики (реплик) для отказоустойчивости (а мы с вами помним что продуктивного сервера СУБД без реплик не бывает, иначе это мёртвый сервер и вопрос не в том - умрёт ли, а только в том – когда умрёт…) сделать распределение читающей нагрузки 1С на реплику с помощью механизма копии базы данных 1С. Что уже есть в части работы этого механизма копии с PostgreSQL? 1. Внутренняя репликация. Это когда мы просто обменом 1С периодически обновляем нужные нам данные из рабочей базы 1С в базу копию. Полюсы – кросСУБДшность, т.е. мы рабочая база может быть на любой СУБД и копия может быть на любой СУБД и при этом они не обязаны совпадать. Например, рабочая на MS SQL, а копия на PostgreSQL. Минусы – обмен происходит периодически, т.е. данные в копии могут серьёзно отставать. Скорость обмена не всегда удовлетворяет требованиям бизнеса. 2. Внешняя репликация с помощью расширения dbcopiesupdates. Если кратко, то это обмен между двумя базами PostgreSQL основанный на вычитке WAL (журнала предзаписи транзакций). Плюсы – большая скорость и отсутствие ненужных перезаписей объектов. Минусы – обмен происходит периодически, т.е. данные в копии могут серьёзно отставать, так же нужно сохранять весь WAL между периодами синхронизации. Общий «минус» обоих вариантов – необходимо иметь дополнительный сервер для копии базы данных, при том что у нас же уже есть реплика, а чаще всего их даже две, так как кластер обязан состоять из нечётного числа узлов (узел рефери это отдельная история и пока её унесём за рамки). Рассмотрим сам процесс создания такой копии базы данных в 1С и проверим работает ли это «чудо»: 1. Функции технического специалиста – Управление копиями базы данных. Нажимаем Добавить, Выбираем тип – Внешняя, Тип СУБД – PostgreSQL, База данных – имя базы как у прода (тут как раз зарыта одна особенность), Пользователь и пароль на СУБД. (Рисунок 1) Поскольку это реплика, то в целом можно выбрать все метаданные, так как они в реальности там все есть. Поскольку метаданных много, то лучше снизу снять флажок «Обновлять информацию автоматически». Иначе колёсико ждуна будет почти вечно крутится. 2. Нажимаем ОК и получаем предупреждение (Рисунок 5), где нажимаем «Сохранить как есть». Предупреждение мы как раз и получаем из-за того, что у нас на реплике полная копия прода и там есть запись на каком сервере 1С расположена наша база. 3. В итоге копия подключается с Состоянием – включена и Состоянием обновления – неактивно, но на это не обращаем внимание, так как на ИТС написано, что будет использоваться копия с состоянием Включена. Теперь одно из самых приятных – подключаем копию БД к отчёту без привлечения разработчиков 1С. Возьмём для примера типовой отчёт ERP: Валовая прибыль предприятия (Рисунок 2) 1. Идём в Настройки – Ещё – Настройки для технического специалиста – Дополнительные настройки 2. Включаем «Выводить копию базы данных» - Свойства – Включать в пользовательские настройки 3. Включаем «Использование копии базы данных» - Свойства – Включать в пользовательские настройки Ну и формируем отчёт, сначала на проде (Рисунок 3) затем на копии (Рисунок 4), как видно цифры совпали, что несомненно радует!)))) ❗️Механизм копии БД не работает с расширенными данными!!! Это крайне важно, так как мода на расширения, расширяющие данные сейчас прям повальная... В ближайших релизах это станет доступно в версии PGRPOEnterprise. Отдельное спасибо Андрею и Роману из Постгресс Профессиональный за проделанную работу и терпение!

Копия базы данных 1С теперь работает и на репликах PostgresPRO Это небольшой анонс серии постов, в один никак не смог уложить. На прошлой неделе мы командами ИнфоСофт и Постгресс Профессиональный закончили тестирование работы физической реплики с механизмом копии базы данных 1С. Раньше работа Копия БД была невозможна с физическими репликами PostgreSQL, так как на реплике нельзя было создавать временные таблицы и не только. А ведь очень хотелось использовать реплики отказоустойчивого кластера для читающей нагрузки, а не только для отказоустойчивости. Теперь это стало реальностью и позволит реализовать очень интересные сценарии работы высоконагруженных систем, точечно уведя читающую нагрузку на реплики. И отдельное удовольствие состоит в том, что для направления выполнения отчёта на Копию БД не требуется разработчик 1С и его время, а требуется всего лишь пара кликов от пользователя 1С с достаточными правами.

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С пройдёт 1C DevCon 2026 - конференция Разработчиков Лучшей в мире платформы 1С для Разработчиков на лучшей в мире платформе 1С! Если вам интересно куда движется сама платформа 1С, 1.Элемент, EDT, 1С.Напарник и т.д., то лучшего времени и лучшего формата просто не найти! Приходите, будет интересно!

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

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

Первый опыт прямого эфира Если что, то 19:00 по Мск)

🔖 Как не дать конфигурации 1С положить сервер: профили, кластеры и логи Платформа 1С не превращает произвольный доверенный серверный код в идеальную песочницу. Но она умеет: ограничивать опасные возможности, уменьшать радиус поражения, разделять полномочия и давать нормальные инструменты расследования ➡️ Что вообще считать опасным кодом в 1С Вредоносный, чрезмерно доверенный, привилегированный, ресурсоубивающий. ➡️ Что реально ограничивает действия кода Безопасный режим, профили безопасности, запрет опасных возможностей. ➡️ Что уменьшает ущерб, если код уже плохой Разные пользователи ОС для компонентов кластера, разнесение центрального и рабочих серверов, выделенные сервера под тяжёлые/подозрительные сценарии, управление потреблением ресурсов. ➡️ Что управляет доступом, но не sandbox’ит код Разделение админов, внешнее управление сеансами. ➡️ Что помогает после пожара История данных, журнал регистрации, техжурнал, мониторинг кластера, дампы. ➡️ Что на счет отладки Отладка на сервере или как дать злоумышленнику исполнить произвольный код Приглашенный гость: 😶‍🌫️ Антон Дорошкевич, Руководитель проектов, ИнфоСофт 😉 Стрим на YouTube 😄 Запись после стрима 🥰 Запись после стрима 🗓 Дата: 17 марта в 19:00

🔤🔤🔤 Когда фоновый процесс обновления статистики может стать виновником блокировок и что с этим можно сделать? Не смотря на то что в целом Автовакуум это неблокирующая операция, всё таки есть возможность получить таймаут на блокировке... Тонкость состоит в том что автовакуум, даже когда он пришёл только лишь обновить статистику накладывает блокировку на схему БД. Т.е. нельзя во время работы автовакуума с таблицей менять в ней состав колонок или удалять таблицу целиком. И тут нам в мире 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️⃣🔤 Сервис проверки ТНФ Всем привет! 10 лет к ряду постоянно сталкиваемся с некорректным пониманием того, как же на самом деле работают Требования Назначения Функциональности в кластере Лучшей в мире платформы 1С! Поэтому вместе с командой РКЛ-ИнфоСофт написали сервис по проверке ТНФ на технологии 1С.Элемент и предлагаю вам им воспользоваться https://lk-rkl.is1c.ru/tnf-checker-free Что он умеет: 1. Анализировать файл реестра вашего кластера (никакие данные никуда не сохраняются, так что не переживайте!) 2. Визуализировать структуру вашего кластера со всеми ТНФ 3. Показывать как будет назначен сервис с учётом Объекта требования, имени базы и дополнительных параметров. 4. Можно выключать/включать сервера и затем проверять назначение 5. Можно добавлять/изменять/удалять ТНФ и опять проверять как сработает требование при новой структуре 6. Можно менять порядок следования ТНФ ❗️Сервис написан на основании описания ИТС и нашем опыте! Если вы нашли неточность в определении пути требований сервисом в вашем кластере, то: 1. Пришлите мне в личку файл реестра кластера почистив его от паролей админов и субд. 2. Опишите в чём неточность Мы всё посмотрим, и либо исправим неточность либо объясним почему ТНФ будут работать именно так как показал сервис. Надеюсь сервис окажется очень полезным, так как красивый он уже 😄