Плановая дата обязательного перехода на Платформу 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

Как понять хватает ли памяти серверу PostgreSQL 2.0

Ранее мы уже получили верхнеуровневую информацию о заполненности кэша СУБД
https://t.me/explorer1c/68

Но этой информации не всегда достаточно чтобы принять решение хватает ли нам уже выделенного объёма.

Тут нам на помощь приходит ещё один столбец из pg_buffercache_summary(), а именно usagecount_avg, который даёт информацию о среднем значении счётчика использования буферов в кэше.

select usagecount_avg from pg_buffercache_summary()

Сам процесс "нагревания" и "охлаждения" буферного кэша основан на алгоритме Clock-Sweep.

Краткий смысл алгоритма:
Процесс "нагревания" - при каждом обращении к странице в кэше счётчик её использования (usage_count) увеличивается на единицу.

Чтобы избежать зацикливания в бесконечном круге горячих страниц максимальное значение ограничено, например в postgresql, числом 5.

Процесс "охлаждения" - циклически обходим страницы в буферном кэше.
- Если usage_count > 0, то уменьшаем его значение на единицу.
- Если usage_count = 0, то эта страница может быть вымещена из кэша, а на её место загружена новая.

Таким образом эффективность кэша можно оценить значением usagecount_avg > 2,5.
Если же значение usagecount_avg часто оказывается меньше единицы, то буферного кэша недостаточно и страницы постоянно оттуда вымещаются.
Сильно высокое значение usagecount_avg (4-5) наоборот говорит о том, что у нас слишком большой буферный кэш и его можно уменьшить.

Более подробную раскладку, какое количество страниц с каким значением счётчика в кэше можно получить запросом:
select usage_count, buffers from pg_buffercache_usage_counts()

Получив, например такой расклад:
usage_count | buffers
0 | 441196
1 | 236729
2 | 81823
3 | 44989
4 | 214970
5 | 159941

При этом usagecount_avg = 1,86

❗️Конечно и это ещё не вся информация для тончайшей настройки PostgreSQL, но надеюсь что она даст ещё больше понимания как работает кэш и что с ним можно делать и нужно ли это делать.

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

Обновление минорной версии PostgreSQL – практически обязательно!

Обычно к обновлению минорной версии ПО (последняя цифра в номере версии) относятся как к необязательной процедуре вычитывая новшества и примеряя их на себя.
Но за последние несколько месяцев, и это по моему мнению пока самое полезное применение Больших Лингвистических Моделей (ИИ, хотя он ещё вообще не ИИ))) ) в ИТ, с помощью ИИ найдено очень большое количество уязвимостей в самом широком спектре ПО.

Огромный плюс ИИ в этой работе в том, что он не ленив и не чурается старого кода, в котором все были уверены на протяжении десятков лет и код ревью человека туда никогда бы не заглянул.

В последних минорных версиях PostgreSQL 18.6, 17.11, 16.15, 15.19 и даже в 14.24 исправили 32 CVE!

❗️Обратной стороной ИИ в ИТ является использование найденных уязвимостей с генерацией сценариев использования с нечеловеческой скоростью, поэтому обновления, которые раньше можно было отложить, теперь откладывать нельзя!

Канал в MAX https://max.ru/explorer1c

У многих сервисов был свой дом в Яндексе....
Тёплый, уютный, надёжный!
Желаю всем кто сейчас восстанавливает эти ит-дома и работает на пределе физических возможностей огромной удачи, чтобы всё получалось с первого раза!
Я уверен, что все ИТ-шники сейчас с вами!
❤️❤️❤️

Как один небольшой "недогляд" привёл к проблеме после миграции базы с MS SQL на PostgreSQL через ibcmd

Обычно я пишу про то, как нужно делать, но сегодня напишу про то как НЕ нужно!))
При этом я остаюсь верен себе и пишу только про свою практику, а соответственно этой мой недогляд...

Итак, всё было хорошо, процесс миграции протестирован минимум 10 раз!

Настало время миграции прода и по началу казалось что всё прекрасно, сама миграция завершилась сообщением "[INFO] Репликация информационной базы успешно завершена"!
Ура, можно выдыхать!

Но буквально через несколько минут от пользователей посыпались жалобы что в некоторых справочниках задвоились данные...
Не веря глазам своим идём на СУБД и запрашиваем выборку из справочника (на картинке) и видим, что действительно, задвоенные записи с одинаковым значением поля _code и при этом разными значениями поля version...

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

Достаточно долго просто удивлялись - как так то!?!?!? И что это вообще такое!?!?!?

Затем, проанализировав масштаб проблемы, выяснилось что она есть только в двух справочниках и только у предопределённых элементов.

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

Вот это поворот! Откуда тогда эти элементов по 2 версии??? И почему только в этих справочниках, а с остальными предопределёнными всё хорошо?

Развязка:
Оказалось, что мигрируя базу мы НЕ заблокировали базу назначения!
И пользователи начали заходить в базу в момент миграции, некоторые предопределенные элементы ещё не успели приехать с MS SQL и были заполнены значениями из конфигурации, а потом ещё приехали через ibcmd в процессе миграции и записались с новой версией...

Удалили "неверные" элементы, получили в некоторых документах "ссылки на несуществующий объект" и были уверены что победили!

Но не тут то было!
Такие записи продолжили появляться в базе...
Заблокировали базу, все пользователи вышли, зашли заново - не помогло.
У кого то всё равно по 2 значения с одинаковым кодом в справочниках, у кого-то по одному, а при этом в СУБД то уже ТОЧНО по одному значению!

Опять в документацию - там написано что надо бы обновить конфигурацию и тогда счастье наступит...

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

❗️Вывод: База назначения при миграции должна быть надёжно заблокирована от входа пользователей до того момента, пока миграция не закончится!

И опять про критичные обновления...

Для PHP выпущены исправления для двух критических уязвимостей (CVE-2026-109618 и CVE-2026-109619). оценка угрозы 9,2 из 10!

Обновите PHP до исправленной версии

➖ 8.5.12
➖ 8.4.27
➖ 8.3.36
➖ 8.2.35

По неофициальным данным, уязвимости затрагивают PHP начиная с 5.4.0
НО исправления выпущены только для ветки 8.2.+, версии 8.1 и старше больше не получают обновлений от проекта PHP.

Если оперативно обновить версию PHP невозможно, то есть рекомендуемые временные меры https://www.php.net/archive/2026.php

Да, согласен, 1С и СУБД тут не при чём, но PHP настолько распространён, что знать будет не лишним!