Утром в канале, вечером в Красноярске)

Открыто голосование за доклады на октябрьский Инфостарт

https://infostart.ru/event/tech2026/agenda/

Выбирайте, голосуйте, приезжайте!)

Системные администраторы, с праздником! 🎉🎉🎉

Именно системное администрирование было моим началом в ИТ)

Статистика по временным таблицам в PostgrePRO - другой подход

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

При этом лучшая в мире платформа 1С, после заполнения каждой временной таблицы даёт команду ANALYZE ##tt1, где ##tt1 имя нашей временной таблицы.

При этом статистика считается по каждой колонке временной таблицы.

Это влечёт за собой серьёзные траты ресурсов сервера на расчёт статистики именно по временным таблицам.

Расширение pgpro_temp_stats предлагает интересный подход к решению этой проблемы, побочным эффектом которого может стать ускорение запросов с временными таблицами!

Кратко:
1. При включении параметра pgpro_temp_stats.skip_analyze - игнорируем команды ANALYZE по целым таблицам, т.е. пока не греем воздух просто расчётом статистики
2. При включении параметра pgpro_temp_stats.create_statistics - расширение считает статистику только по тем столбцам временной таблицы, которые задействованы в запросе.
Более того, считается не просто статистика, а расширенная статистика, т.е. не по каждому столбцу в отдельности, а по всем столбцам из запроса сразу.
Что позволяет планировщику получить более оптимальный план запроса.
3. Так же расширение запоминает уже посчитанную статистику для таблицы, так как мы же можем её и второй раз использовать. Если в новом запросе поля те же, то статистика не считается, так как она уже есть, если же поля другие, то считаем по новому набору полей.
Сколько таких запоминать регулируется параметром pgpro_temp_stats.ts_max_items

Расширение доступно в 17 и 18 версиях PGRPO Enterprise.

Мы протестировали - нам понравилось!)

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

Сегодня особенный день — мой день рождения!
Хочу поблагодарить всех, кто делает мою жизнь ярче и интереснее. Каждый день я учусь чему-то новому и встречаю замечательных людей.
Пусть этот год принесет ещё больше возможностей, успехов и приятных моментов. 🌟
С днём рождения меня! 🎂

P.S. С днем рождения мою сестру-двойняшку 😘

🎉🎉🎉🎉🎉🎉

Дампы аварийного завершения процессов 1С

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

Так как же настроить сбор дампов и сделать так чтобы это не приводило к падению сервера по нехватке места на диске?

В настройке ТехЖурнала (файл logcfg.xml) для сбора дампов в ОС Windows (в Linux всё по другому) нужно добавить/отредактировать строку:
<dump location="D:\dumps\" create="1" type="3" externaldump="1"/>
Тип дампа (type) нужно поставить 3, так как это минимально необходимый объём информации для действенного разбора дампа.
Дамп такого типа при формировании будет иметь размер равным размеру оперативной памяти, которую занимал процесс на момент формирования дампа.

Очень важно указать location не на системном диске С и не на диске где у нас расположены сеансовые данные и/или каталог временных файлов пользователя процесса rphost.
Желательно выделить для этого отдельный логический/физический диск с объёмом свободного места не менее всего объёма оперативной памяти, так как в крайнем случае дамп будет размером во всю оперативку.

Затем нужно сделать скрипт и поставить его в шедуллер на выполнение раз в 5 минут (меньше получится только используя cron, там раз в минуту), который будет архивировать файл дампа.
Архив дампа очень часто занимает в десять раз меньше места чем оригинал.

Настроить систему мониторинга или в самом скрипте архивации прописать сообщение ответственному админу 1С о факте формирования дампа.

Что делать с дампами потом и какие они бывают?

Дамп в ОС Windows имеет достаточно понятное имя файла:
<имя процесса>_<версия платформы>_<смещение>_<годмесяцденьчасминутасекунда>_<PID процесса>.mdmp
Например: rphost_8.3.27.1606_547f1b52_20260810051328_13432.mdmp

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

В имени много важной информации, и отдельно нас интересует смещение.
Если у нескольких дампов смещение одинаковое, то и причина падения с 99% вероятностью тоже одна, поэтому на расследование достаточно отправить пару дампов, а остальные просто сохранить в сторонке.

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

Это поведение зависит от настроек кластера 1С (на скриншоте), а именно:

❗️Менять их нужно крайне осознанно полностью понимая что делаешь, несколько раз прочитав документацию и поняв её!

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

Другие настройки это Период проверки (1000 мс) и Таймаут проверки (5000 мс), вот их нужно кратно увеличить до тех пор пока падения не прекратятся.

НО, сам факт таких дампов говорит о том что процессы реально не отвечают системе отслеживания и с этим нужно разбираться.
И о УЖАС - разбираться с этим нужно АДМИНИСТРАТОРАМ 1С, а не 1С-кам!!!

Вот выдержка из документации (ссылка выше), которая с этим поможет:

Для этого каждые 10 секунд в технологический журнал записывается статистика проверки соединений за прошедшие 10 секунд. В частности, выводится информация о среднем времени ответа и о максимальном времени ответа. Эта информация позволяет выставить оптимальные значения таймауты проверки, которые не будут приводить к ложным срабатываниям системы проверки, но, в тоже время, обеспечат надежное функционирование самой системы. В технологическом журнале информация фиксируется в событии CONN.

Плановая дата обязательного перехода на Платформу 8.5 для конфигураций ERP/KA/УТ– не ранее 30.04.2027

Многие спрашивают - сколько ещё сможем жить на ламповой 8.3?
Фирма 1С дала ответ.

https://1c.ru/news/info.jsp?id=34779

Так что пора уже понемногу планировать переход на 8.5.

❗Особенное внимание нужно уделить переходу на новый сервис лицензирования при наличии USB-ключей, так как 8.3 не видит новый сервис, а 8.5.4 не умеет работать с lm-hasp.

Небольшой анонс поездок и мероприятий с моим участием:

08-10/09 - Обучение по кластеру 1с и PostgreSQL, Москва
11/09 - Хакатон-ИнфоСофт, Новосибирск
18/09 - Жёлтая конфа, Москва
26-27/09 - Партнёрский семинар 1С, Москва
08-10/10 - Infostart Tech Event, Санкт-Петербург

Сентябрь беспощаден!)

Как собрать для анализа запроса все временные таблицы с их содержимым?

Все мы хорошо знаем, что количество временных таблиц, создаваемых и используемых во время работы 1С огромно.
Очень часто нам для оптимизации скорости работы 1С требуется не только текст запросы и его план, но и содержание временных таблиц.
А это огромная проблема – таблиц может быть много, записей в них могут быть и тысячи и миллионы…
Какие только инструменты для этого не пытались использовать, и ТехЖурнал с записью всех запросов к СУБД, и трассировку запросов на уровне СУБД. А потом сбор всех этих данных и формирование таблиц с содержимым на основании этих данных.
Было очень тяжело и всегда неохота этим заниматься…

Насколько мне известно при работе с MS SQL так ничего и не поменялось.
А вот в PostgreSQL появилось расширение auto_dump.
«На пальцах» что делает расширение:
Следит за текстом запросов dump_on_query_string и когда находит нужный (например UPDATE _AccRg), то делает бэкап всех временных таблиц и их содержимым (можно и физических, но по моему мнению это достаточно опасно, ниже опишу почему), собирает предполагаемый и фактический планы запроса, сохраняет текст самого запроса, складывает это всё в каталог указанный в параметре output_directory
Так же можно настроить чтобы собирались запросы только длительнее чем auto_dump.timeout
Или запросы у которых по нашему мнению плохой план из-за большой разницы в предполагаемых и фактических значениях bad_plan_count_threshold и/или bad_plan_percent_threshold

Чем опасен параметр dump_persistent_tables, который позволяет сразу дампить физические таблицы?
Тем что физические таблицы могут быть огромного объёма и в итоге мы получим и тормоза и забитый диск.
Поэтому включать этот параметр нужно только полностью понимая что вы делаете.

Как потом работать с полученной информацией уже запросами к СУБД напрямую:
1. Создаём новую пустую базу из 1С. Это делается для того чтобы были созданы функции и типы данных, которые использует 1С.
2. Делаем dump физических таблиц, которые есть в запросе.
3. Восстанавливаем из дампа таблицы в базу созданную в п.1
4. Выполняем скрипт create_temporary.sql по созданию временных таблиц, который нам создал auto_dump
5. Выполняем скрипт insert_temporary.sql по наполнению временных таблиц, который нам создал auto_dump
6. Выполняем запрос query.sql, который нам создал auto_dump, на уровне СУБД и пытаемся его оптимизировать настройками СУБД, добавлением индексов (понимая как потом мы их сможем добавить на уровне 1С), улучшать план запроса манипулируя параметрами сбора статистики, менять сам запрос на уровне СУБД опять же понимая как мы потом это на 1С напишем и т.д.

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

Начнём...)

Теперь на багборде можно легко и быстро сравнить версии платформы по изменениям!

Уверен что это сильно упростит ответ на самый популярный вопрос - "А на какую платформу переходить?")))

Сегодня ровно год первому сообщению в канале!
Огромное спасибо всем вам!
Честно - было очень страшно начинать и я надеюсь, что держу свои обещания публикуя только практические кейсы без рекламы и воды!

С годовщиной, "Маяк в мире 1С и СУБД" 🎉🎉🎉🎉🎉🎉🎉

Можно ли сделать поведение PostgreSQL в отношении потребления памяти процессами более жестким чем "мягкий предел"?

Кратко - да, можно))

Проблематику расхода памяти процессами вкупе с работой пула соединений 1С затрагивал в
https://t.me/explorer1c/39 и https://max.ru/explorer1c/AZvZrNDcSXU

Но это же только часть проблемы, есть сценарии и похуже, когда мы не можем никак повлиять через idle таймаут поскольку запрос выполняется...
И вполне может произойти ситуация, когда на выполнение запроса не хватит оперативной памяти и опять придёт охранник ОС OOMKiller и прекратит это безобразие...

В версии PosrgresPro Enterprise есть параметр max_backend_memory - он как раз таки задаёт максимальный объём памяти на один рабочий процесс и при его превышении прекращает выполнение запроса.

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

Сейчас ведём работы совместно с командой PostgrePRO по следующей логике:

Раз мы как администраторы СУБД задали ограничение max_backend_memory, то значит когда мы прервали выполнение запроса, то будет логичным вообще завершить этот процесс аналогично механике idle_session_timeout, таким образом снижая вероятность перерасхода оперативной памяти в целом на сервере.

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