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

Всем привет!

Ещё один опыт, теперь аудио-подкаста, с Марией Серёгиной (радио аналитик).
Постарался "на пальцах" рассказать аналитикам про СУБД.
Спасибо Марии за приглашение и интересные вопросы!

https://itanalyst.mave.digital/ep-77

🔤🔤🔤 Журнал транзакций в PostgreSQL и MS SQL

Во время обучения по PostgreSQL часто встречаю заблуждения по поводу лога транзакций (в PostgreSQL это Журнал предзаписи (Write-Ahead Logging) - что гораздо точнее отражает его суть.

Давайте попробуем прояснить главные отличия этого механизма у двух СУБД.

1. Как хранится журнал транзакций
MS SQL - по умолчанию хранит в одном файле на каждую базу
PostgreSQL - по умолчанию хранится в файлах по 16МБ на весь сервер

2. Нужен ли журнал транзакций для "отката" транзакции
MS SQL - да
PostgreSQL - нет

❗️Тут давайте остановимся чуть подробнее.
"Откат" транзакции в MS SQL происходит с помощью чтения Журнала транзакций с момента начала "отката" до момента начала транзакции в обратном хронологическом порядке и в базе "отыгрываются" все произведённые этой транзакцией изменения.
Соответственно, чтобы обеспечить возможность "отката" транзакции СУБД обязана сохранять весь журнал транзакций с момента её начала.
Из-за этого в MS SQL журнал может неожиданно неконтролируемо вырасти и либо занять всё место на диске либо упереться в максимальный размер файла, заданный в настройках базы.

"Откат" транзакции в PostgreSQL происходит путём смены одного бита в служебной таблице pg_xact, где для каждой транзакции есть запись со статусом committed или aborted.
Поэтому "откат" транзакции в PostgreSQL происходит мгновенно и не требует хранения журнала транзакций (WAL).
Соответственно и роста каталога с WAL по причине долгой транзакции происходить не может.

3. На что влияет операция checkpoint
MS SQL - именно эта операция делает сброс всех "изменённых" страниц с кэша в базу и ставит "метку" в файле Журнала транзакций об этом факте. Теперь журнал транзакций "левее" этой метки может быть заархивирован либо перезаписан новыми данными. (Если нет реплик)
PostgreSQL - Так же делает сброс всех "изменённых" страниц с кэша в базу и ставит "метку" в файле Журнала транзакций об этом факте. Теперь файлы в каталоге с WAL "левее" этой метки могут быть заархивированы либо удалены. (Если нет реплик)

4. Реплики и их влияние на журнал транзакций
MS SQL - будет сохранять журнал пока реплика его весь не заберёт себе. В случае если журнал прирастает быстрее чем его забирает реплика может произойти переполнение диска или максимального размера журнала транзакций и остановка сервера СУБД
PostgreSQL - будет сохранять файлы журнала предзаписи пока реплика созданная со слотом репликации не заберет себе эти файлы. Помним что файлы по 16 МБ, т.е. они и удаляться будут постоянно со скоростью, с которой реплика успевает их себе забрать.
Таким образом даже если общий объём журнала предзаписи за промежуток времени превышает объём диска по WAL, то всё равно место скорее всего не закончится.
Но, если реплика не успевает катастрофически или вообще отключилась, то у нас есть риск переполнения диска.
Для избегания этого риска в PostgreSQL есть настройка: max_slot_wal_keep_size - задаёт максимальный размер файлов WAL, который может оставаться в каталоге pg_wal для слотов репликации после выполнения контрольной точки.
Если объём файлов в каталоге превысит это значение, то слот репликации, которому нужны самые старые файлы WAL будет выключен и каталог будет очищен максимально для продолжения безопасной работы СУБД.

5. Архивирование журнала транзакций
MS SQL - заархивировать можно только журнал "левее" последнего checkpoint. Если у нас не происходит checkpoint или не работает/"завис" процесс архивирования, то сервер будет накапливать журнал и мы упрёмся или в место на диске или в ограничение размера файла журнала транзакций.
PostgreSQL - заархивировать можно любой файл WAL, кроме текущего. НО если у вас по какой-то причине процесс архивирования не работает или "завис", то сервер будет копить файлы WAL и мы придём опять к ситуации окончания места на диске.

Понимание этих основных отличий работы СУБД с журналами транзакций (предзаписи) поможет в понимании механизмов и разборе ситуаций с окончанием места на дисках СУБД.

❗️Место на дисках - САМАЯ ЧАСТАЯ проблема остановки или неадекватного поведения продуктивных серверов как СУБД так и 1С!

Всем привет!
Открыли голосование за доклады на весенний Инфостарт
https://event.infostart.ru/2026team/agenda

Голосуйте, от вас зависит насколько интересно будет на конференции!

1️⃣🔤 Нужно ли менять параметры ограничения потребления оперативной памяти Рабочим сервером 1С и если нужно, то в каких случаях?

Что это за параметры:
▫️Безопасный расход памяти за один вызов (КОРП)
▫️Критический объём памяти процессов (ПРОФ)
▫️Временно допустимый объём памяти процессов (ПРОФ)
▫️Интервал превышения допустимого объём памяти (ПРОФ)

Значения по умолчанию:
▫️Безопасный расход памяти за один вызов = 0 (10% от Временно допустимого объёма памяти процессов)
▫️Критический объём памяти процессов = 0 (95% от объёма памяти в ОС)
▫️Временно допустимый объём памяти процессов = 0 (80% от объёма памяти в ОС)
▫️Интервал превышения допустимого объём памяти = 300 сек

❗️Объём памяти в ОС считывается только один раз при старте службы 1С и затем не обновляется. Это очень важно понимать в случае работы с виртуализацией - крайне не рекомендую работать с динамическим объёмом оперативной памяти ОС или менять её объём "налету" без перезапуска службы 1С.

Когда стоит оставить настройки по умолчанию?
Если у вас в Операционной системе кроме сервера 1С больше ничего не работает и соответственно не потребляет большой (более 5%) оперативной памяти ОС.

Когда стоит менять значения по умолчанию?
Если у вас есть другие потребители большого объёма оперативной памяти на этой же ОС.

Например на одной ОС у нас работают:
▫️Сервер 1С и сервер СУБД
▫️Несколько служб 1С
▫️Несколько кластеров в одной службе 1С

На какие значения менять?
Тут всё достаточно просто и сложно одновременно))

Из простого:
Лучше всего соблюсти те же пропорции параметров Критического и Временного объёма от оперативной памяти ОС для этой службы/этого кластера 1С что и по умолчанию, т.е. 80% и 95%

Из сложного:
Определить какой объём памяти ОС вы выделяете службе/кластеру 1С.

Рассмотрим на простом примере "Сервер 1С и сервер СУБД на одной ОС"
Если мы можем ограничить сервер СУБД в потреблении оперативной памяти (в случае с MS SQL), то тогда -
Память для 1С = Память ОС - Память для SQL
Допустим у нас на ОС 128ГБ, серверу СУБД мы выделили 48ГБ, тогда Память для 1С = 80ГБ

Соответственно устанавливаем:
▫️Критический объём памяти процессов = 0 (95% от объёма Память для 1С), в нашем примере это 76ГБ
▫️Временно допустимый объём памяти процессов = 0 (80% от объёма Память для 1С), в нашем примере это 64ГБ
▫️Безопасный расход памяти за один вызов = 0, я не вижу особого смысла трогать этот параметр. так как он зависит от Временно допустимого объёма памяти процессов

Если же у нас вариант, когда на одной ОС несколько служб 1С или внутри одной службы несколько кластеров 1С, то тут только вы сами можете определить какой объём оперативной памяти вы выделяете каждой службе/кластер 1С и уже от этого значения посчитать %% для Критического и Временного ограничений.

У нас остался ещё один параметр "Интервал превышения допустимого объём памяти".
Этот параметр стоит менять только если ваш сценарий использования 1С подразумевает более долгое чем на 5 минут превышение 80% оперативной памяти и при этом оно не достигает 95%, тогда смело меняйте этот параметр в бОльшую сторону.

Что будет, если "побочный" потребитель оперативной памяти есть, а мы не учли это в настройках?
❗️Возможна ситуация, полной остановки ОС или прихода OOMKiler в случае Linux, например когда кто-то запустил в 1С процедуру с огромным потреблением оперативной памяти.
Кластер 1С не сможет вовремя защитить себя и ОС от перерасхода оперативки, так как не знает что она уже кончилась считая что вся оперативка ОС была отдана ему одному.

1️⃣🔤 По предыдущему посту поступил сразу от нескольких подписчиков вопрос:

При правильной настройке кластера у пользователей при входе в базу возникает сообщение "Информационная база была перемещена или восстановлена из резервной копии"

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

Но мало кто замечает что снизу справа есть кнопка Ещё, а там галка "Проверять имя сервера".
❗️Так вот, при работе в кластере с несколькими центральными серверами 1С эту галку нужно снять.

Хорошо, сделали, но тогда возникает следующий вопрос: Что делать когда мы действительно восстановили базу в тестовую среду или среду разработки?
Ведь теперь у нас не будет задан такой вопрос и мы не отключим опасные регламенты!

Отвечаю: на средах разработки и тестирования, да и вообще при любом случае создания копии рабочей базы, она должна быть зарегистрирована в кластере 1С с установленной в ОБЯЗАТЕЛЬНОМ порядке галкой "Блокировка регламентных заданий включена" в свойствах базы в кластере 1С.

В 99,9% сценариев работы с копией рабочей базы регламенты не нужны.
Так как даже для проверки работы регламента достаточно просто запустить его по кнопке "Выполнить".

Ну а если всё таки вам необходимо какие-то из них включить, то сначала нужно в самой базе выключить все ненужные регламенты, оставить только нужные.
Затем из нужных надо отключить опасные, которые являются заданиями интеграции.
Проанализировать эти опасные операции, поменять все адреса на тестовые и только потом включить обратно это регламентное.
❗️И после того как вы точно уверены что с этой копии базы никакие данные никуда не полетят в ненужном направлении можно снять в свойствах базы галку "Блокировка регламентных заданий включена".

1️⃣🔤 Неправильные подходы к отказоустойчивости кластера 1С со стороны клиентского подключения

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

Сценарий будет очень простым: есть два боевых сервера 1С, оба центральные + сервер 1С с ТНФ - Сервис лицензирования - Назначать (будем называть его Сервером лицензирования, хоть это и неправильно), хотим из них сделать отказоустойчивый кластер 1С.
Уровень отказоустойчивости в кластере = 1.

▫️Первый вариант - DNS.
Берём и прописываем IP адреса обоих Центральных серверов 1С под одним DNS-именем.
Например: Server1c - 192.168.0.1, 192.168.0.2
И соответственно в стартере 1С прописываем: Srvr="server1c";Ref="erp";

Казалось бы - всё прекрасно, и действительно - всё работает!
НО, до того момента пока "живы" оба наших Центральных сервера 1С,
Когда же выйдет из строя или просто станет недоступен по сети один из серверов, то пользователи начнут в случайном порядке получать ошибки работы в 1С (кто в ней уже был) и ошибки входа в 1С.
Так как DNS не анализирует доступность IP адресов, а просто выдаёт их по запросу в случайном порядке, а операционная система берёт первый из выданных адресов и пытается обратиться по нему, не пытаясь перебирать эти адреса.

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

▫️Второй вариант - разные proxy (nginx, haproxy, citrix и т.д.).
Тут в целом очень похоже на первый вариант, но немного сложнее.
Сложность в том что proxy подменяют IP адреса наших Центральных серверов 1С своим IP адресом.
И мы получаем, что клиент 1С общается с сервером 1С не по прямому IP что помимо задержек в общении может приводить вообще к неработоспособности 1С с очень "волшебными" ошибками сетевой недоступности серверов 1С.

Основная мысль в том, что не надо ничем заменять встроенную в Лучшую в мире платформу 1С отказоустойчивость!

А как же тогда правильно делать отказоустойчивость со стороны клиентского подключения?

Всё очень просто - нужно в адресе базы указать два наших центральных сервера: Srvr="server1c-1,server1c-2";Ref="erp";
При такой настройке сам клиент 1С, будет им Тонкий или Толстый клиент, либо Веб-браузер обратится сначала к server1c-1 для подключения и если он недоступен, то к server1c-2.

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

Напоминаю, что резервная копия канала есть в MAX.

1️⃣🔤 После старта сервера 1С стартуют все регламенты...

❗️Достаточно часто встречаюсь с непониманием ситуации - почему после старта службы 1С стартуют все регламенты в базе, хотя у нас же настроено расписание?

▫️Во-первых, - не надо перезапускать сервера 1С, это очень нехорошая практика... Настройте перезапуск рабочих процессов - этого достаточно для стабильной работы Лучшей в мире платформы 1С!

▫️Во-вторых, - почему-же после запуска сервер запускает регламенты 1С?
Причина в том, что сервер 1С "помнит" когда последний раз запускал регламент в оперативной памяти менеджера кластера (rmngr).
Дата окончания у всех заданий - <не определено> (скриншот 1)

Но тут возникает следующий вопрос: почему стартует задание с расписанием "каждый день; с 5:25:23 один раз в день" (скриншот 2). когда сейчас только час ночи?

Когда в расписании указано только Время начала и при этом регламентное никогда не выполнялось по мнению менеджера кластера, то сервер запустит этот регламент неважно настало это время или нет!

Та же самая ситуация будет в кластере с двумя центральными серверами и уровнем отказоустойчивости = 0 при выходе одного из них из строя (а именно на нём был сервис заданий).
В этом случае вам необходимо установить уровень отказоустойчивости = 1 и тогда информация о Дате окончания будет синхронизироваться между обоими серверами и всё будет хорошо.

Если же вы хотите чётко определить время запуска регламента, то помимо Времени начало в расписании необходимо задать Время окончания (не путать с Завершать после - это совсем другой параметр).

Итак, зададим нашему регламенту расписание "каждый день; с 5:25:23 по 5:25:30 один раз в день" (скриншот 3).
И вот только в этом случае, даже при старте сервера в час ночи, наш регламент стартанёт ТОЛЬКО в промежутке 7 секунд с 5:25:23 до 5:25:30.

Посмотрите расписания регламентов в своих базах и настройте его правильно согласно бизнес-логике.
Конечно периодические регламенты (раз в 30 минут, 30 сек и т.д.) так настраивать нет смысла.

Выдержка из итс: В механизме расписаний существует соглашение, что если какой-то элемент расписания не указан, то он не участвует в создании расписания. Например, если мы не указали дату окончания, то расписание будет выполняться неограниченно долго. Также, если мы не указали дату начала, то расписание будет выполняться от текущего момента. Расписание не будет выполняться до даты начала, и после даты окончания расписания.

🔤🔤🔤 Резервное копирование в PostgreSQL и его мифы часть 2

В этой части поговорим про другой вид резервного копирования в PostgreSQL. а именно про pg_basebackup

Главное отличие от pg_dump состоит в том, что pg_basebackup это резервная копия всего сервера, а не отдельной базы.

Процесс создания резервной копии включает 3 этапа:
▫️Выполнение контрольной точки
▫️Копирование журналов транзакций (WAL)
▫️Копирование самих данных (каталог сервера СУБД)

Последние 2 этапа идут параллельно, и копирование журнала транзакций заканчивается сразу после того как закончилось копирование самих данных.
Таким образом резервная копия консистентна на момент окончания процедуры копирования.
Резервная копия pg_basebackup всегда идёт в 1 поток и содержит как данные так и индексы, так как является по факту копией каталога.
Резервная копия pg_basebackup не имеет обратной совместимости, т.е. копия созданная на версии 15 будет работать только с версией 15.

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

Процесса восстановления из полной резервной копии pg_basebackup не существует, это просто сервер PostgreSQL готовый к старту и чтобы восстановить резервную копию достаточно стартануть СУБД с указанием каталога: pg_ctl start -D /backup/full_copy

Процесс же восстановления из полной копии плюс набор инкрементных включает в себя сначала сборку каталога кластера и затем уже старт PostgreSQL в этом каталоге: pg_combinebackup /backup/full1 /backup/inc1 -o backup/full_combined и затем уже старт: pg_ctl start -D /backup/full_copy

Как снять инкремент:
▫️В postgresql.conf установить wal_level =replica или logical, summarize_wal = on
▫️Также указать wal_summary_keep_time в минутах (по умолчанию 10 дней) - это параметр, отвечающий за то какой глубины вы сможете снимать копии
▫️Создаём полную копию pg_basebackup -D /backup/full1 (в каталоге копии помимо самой копии появится файл backup_manifest, содержащий информацию и контрольные суммы по всем файлам)
▫️Содаём инкремент указывая от какой копии этот инкремент pg_basebackup -D /backup/inc1 -i /backup/full1/backup_manifest

Так же в 17-ой версии появился инструмент проверки резервной копии: pg_verifybackup /backup/full1, НО процедура контроля, выполняемая утилитой pg_verifybackup не включает в себя все проверки, которые будет выполнять сервер, если его запустить с этой копией данных

Помимо "ванильных" средств резервного копирования существует так же несколько вариантов платных и бесплатных ПО со своими плюсами и особенностями.
Чуть позже расскажу про pgpro_backup. так как мы и используем именно это ПО и знаем как оно работает не по наслышке.

🔤🔤🔤 Резервное копирование в PostgreSQL и его мифы

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

Заблуждение № 1:
Резервная копия PostgreSQL будет настоящей только если выгнать всех пользователей из базы 1С и заблокировать базу.

Заблуждение № 2:
Резервное копирование PostgreSQL это только Dump.

Заблуждение № 3:
Резервное копирование PostgreSQL это только весь сервер с помощью basebackup, а базу отдельно забэкапить невозможно.

Заблуждение № 4:
Резервная копия PostgreSQL не имеет обратной совместимости, т.е. копия сделанная на версии 14 не сможет быть восстановлена на версии 15 и новее (сейчас есть уже 18).

Заблуждение № 5:
Резервная копия PostgreSQL может быть только полной и не умеет делать дифференциальные или инкрементные копии.

Как обстоят дела на самом деле:
Резервная копия (бэкап) субд PostgreSQL является что ни на есть настоящей и консистентной даже если сделана во время работы базы и не требует ни отсутствия пользователей в 1С ни блокировки базы.
В отличии от MS SQL где есть только один вид резервного копирования, PostgreSQL имеет два основных вида:
▫️PG_Dump
▫️PG_BaseBackup

В чём их особенности:
PG_Dump - это логическое чтение всех данных со всех таблиц базы данных.
В следствии этого копия созданная утилитой pg_dump консистентна на начало копирования (в отличии от MS SQL, резервная копия которого консистентна на момент окончания копирования).
Так же pg_dump поскольку является по факту просто запросом select с выводом в файл имеет много гибких настроек.
Можно исключить определенные таблицы из копии (очень полезно при создании копии для среды разработки и тестирования, например можно выкинуть иэ бэкапа таблицу истории данных или версионирования данных)
Так же dump не содержит индексов, а содержит только команды их создания. Из-за этого бэкап сделанный с помощью dump занимает намного меньше места чем копия созданная на СУБД MS SQL, которая как раз таки содержит и индексы.
Копия созданная утилитой pg_dump имеет обратную совместимость, т.е. нет никаких проблем в том чтобы создать копию на версии 14 и восстановить её на версии 17.
Единственный нюанс состоит в том, что использовать утилиту восстановления pg_restore нужно в этом случае именно версии 17.

Это ещё не всё про pg_dump)))
Формат резервной копии этой утилиты может быть трёх видов:
▫️-Fp - plain
▫️-Fc - custom
▫️-Fd - directory

Plain - просто текстовый формат, выходной файл будет состоять из команд insert.
Особенность в том что этот формат однопоточный, НО можно немного схитрить и отправить результат команды не в файл, а в поток, а этот поток уже многопоточно сжать через pigz для windows или любого аналога для Linux и тем самым кратно ускорить создание резервной копии | c:\util\pigz\pigz.exe -p4
Плюсы - квазимногопоточность создания бэкапа
Минусы - восстановление только в один поток и предварительно необходимо распаковать файл резервной копии

Custom - это встроенный формат бэкапа, сжимается на лету
Плюсы - многопоточное восстановление. Не требует предварительной распаковки
Минусы - однопоточное создание бэкапа

Directory - бэкап на уровне каталога.
Особенность - гарантированно выполняется только на заблокированной базе, если же базу не блокировать, то возможно что система затребует блокировку таблицы, которую ещё не забэкапили и тогда pg_dump прервёт свою работу по ошибке.
Плюсы - многопоточное создание и восстановление. Не требует предварительной распаковки
Минусы - гарантированное выполнение только на заблокированной базе.

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

Про особенности, плюсы и минусы pg_basebackup расскажу в следующий раз.

Всем привет!

Возможно вы заметили статус A+ у канала.
Это означает что канал прошёл проверку РКН!

Теперь канал есть и в MAXe https://max.ru/explorer1c

Присоединяйтесь!)

Коллеги, привет!
Я никуда не исчез, но меня свалила сильная простуда и температура под 40...
Как только поправлю этот баг в своей платформе обязательно продолжим))

Всем крепкого здоровья!

1️⃣🔤 Во время выполнения действия была потеряна связь с сервером...

Достаточно давно, периодически (естественно почти не подтверждаемая на тестах) как у наших клиентов РКЛ так и у клиентов нашего Облака стала возникать ошибка как на скриншоте.
Причём возникает она просто при работе клиента с 1С ни с того ни с сего.

В результате попыток понять что-же это за проблема было обнаружено два момента:
▫️Ошибка возникает только при работе с базами по http/https, по TCP всё хорошо
▫️Ошибка возникает только если обращение к базе 1С идёт через NGINX, если работать напрямую с apache/iis, то всё хорошо

Ок, определили что с NGINX что-то не так.
Но как всегда, до этого же всё работало!)))
Поэтому сильно хочется начать поиски ключа там где светло, а не там где потерял ключ...

Включаем лог ошибок в NGINX

в файл nginx.conf вверху добавляем строку:
error_log /var/log/nginx/error.log error;
nginx -t (проверить корректность настройки)
nginx -s reload (перечитываем настройки)

В лог ошибок во время получения ошибки пользователем в 1С фиксируется запись:

[error] 3408371#3408371: *954123377 upstream timed out (110: Connection timed out) while reading response header from upstream, client:

Т.е. у нас срабатывает таймаут чтения ответа от проксируемого сервера...

Ок, идём на итс и смотрим какие настройки таймаутов рекомендует 1С и там видим рекомендацию:

proxy_read_timeout 300s;

Но проблема в том, что у нас в настройках уже есть этот параметр и более того он выставлен в значение 3600s, что больше чем рекомендуемое в 20 раз.

Ок, может мы чего-то не понимаем, ставим 300s.
Ситуация поменялась, но уже в части другого.
Ошибок у пользователей осталось как было, а вот других записей в лог ошибок NGINX резко прибавилось:

connect() failed (110: Connection timed out) while connecting to upstream, client:

Вернули параметр в 3600s, всё стало как прежде.

Ну и если честно, то тут прям взяли грех на душу и посчитали что во всём виновато обновление на платформу 1С 8.3.27, так как вроде бы обращения пользователей коррелируют с временем обновления.

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

Так в расстройстве прошло какое-то время, но червячок всё таки грыз понемногу - что ну не может такого быть!)))

Поиск в интернете по ошибке "upstream timed out (110: Connection timed out) while reading response header from upstream," всё равно приводил к параметру proxy_read_timeout, что нам не помогало...

И только в одном из форумов был намёк "попробуйте установить значение параметра "proxy_send_timeout" в больше чем по умолчанию (60s)

Ну когда ничего не остаётся надо идти читать документацию)))
▫️proxy_read_timeout - Задаёт таймаут при чтении ответа проксированного сервера.
▫️proxy_send_timeout - Задаёт таймаут при передаче запроса проксированному серверу

Ну и опять же, вроде мы не тупим - ошибка "while reading response header from upstream" как раз про чтение ответа, а это параметр proxy_read_timeout.
Опять тупик...

С другой стороны, вроде бы нам ничего не мешает установить и значение параметра proxy_send_timeout в 3600s.

Делаем, и вуаля!!!
Ошибки исчезли!

Вот так разное описание параметра в документации и реакции сервера на этот параметр в логе привело в нескольким неделям блужданий в темноте...

❗️Так что если у вас наблюдается ошибка потери связи и при этом у вас есть NGINX, то попробуйте установить параметр proxy_send_timeout в значение 3600s.

1️⃣🔤 "Падение" кластера 1С из-за лицензии разработчика

Недавно в рамках РКЛ разбирали очень интересную ситуацию.

Кластер 1С состоит из трёх серверов:
▫️Server1 - Центральный сервер (ТНФ отсутствуют)
▫️Server2 - Рабочий сервер (ТНФ: Клиентские соединения - Авто, Для всех - Не назначать)
▫️ServerLic - Рабочий сервер (ТНФ: Сервис лицензирования - Назначать, Для всех - Не назначать). На этом сервере активированы обе серверные лицензии 1С (для Server1 и Server2) и какое-то количество клиентских лицензий 1С.

Ожидаемое поведение кластера 1С:
Клиентские соединения равномерно (по производительности серверов 1С) распределяются по серверам 1С.

❗️Всё именно так и работало долго и успешно, но в один "прекрасный" момент соединения перестали назначаться на Server2 и все пользователи работали только на Server1

В консоли администрирования было видно что рабочий процесс Server2 не имел лицензии.
Сначала казалось что проблема именно в этом, было идея что серверную лицензию Server2 занял какой-то другой кластер.
Подробно я разбирал это здесь: https://t.me/explorer1c/21
Анализ показал что это не так и лицензию никто не занимает.

Ок, решили тогда попробовать удалить Server2 из кластера и добавить заново...
Вот тут то мы и получили ошибку со скриншота,

Ошибка регистрации рабочего сервера в кластере:
Ошибка операции администрирования
Лицензия для разработчиков позволяет использовать только один рабочий в кластере...

Казалось бы - фигня делов, сейчас исправим! Мы же знаем где хранятся файлы программных лицензий!

Не тут то было, ни в одном из каталогов хранения программных лицензий никаких лицензий разработчиков не оказалось.
Поиск файлов по всей системе по маске *.lic выдал только 3 файла на сервере ServerLic:
▫️Серверная лицензия для Server1
▫️Серверная лицензия для Server2
▫️Клиентская лицензия на 500 пользователей

Что делать когда предыдущий опыт не помогает?
ВЕРНО! Читать ИТС!!!
Но и там не оказалось ничего про то где и как хранится лицензия для разработчиков...

Опытным путём, а именно пересобиранием кластера было выяснено что лицензия разработчика активирована именно на Server2.

❗️В итоге попробовали на Server2 переименовать каталог reg_1541 (каталог кластера 1С) и о чудо всё заработало, кластер собрался без ошибок!

Пошли выяснять дальше, оказалось что лицензия разработчика хранится в каталоге сеансовых данных сервера 1С. Достаточно почистить этот каталог и проблема вместе с лицензией разработчика исчезает.
Это было очень неожиданно!

❗️И теперь самое важное: пока не просматривается сценария защиты на уровне платформы от этого, так как активировать лицензию можно не только из Конфигуратора, но и из пользовательского режима...
Достаточно при активации просто выбрать в пункте "Дополнительно" сервер кластера 1С.

❗️❗️❗️Что мы можем сделать чтобы всё таки уменьшить вероятность:
▫️Закрыть доступ по TCP опубликовав базу по https и настроить сетевой экран на серверах 1С на запрет доступа по портам 1540,1541,1560-1591 (по умолчанию) всем кроме серверов 1С кластера 1С и web-сервера с публикацией 1С.
▫️Написать и применить расширение, блокирующее пункт в меню "Получение лицензии".
▫️Остаётся конфигуратор - тут только знание, что не надо на продовых кластерах и базах пытаться активировать лицензию разработчика.

1️⃣🔤 Как понять какой кластер обслуживают какие процессы "сервера лицензирования"

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

Но, затем встаёт вопрос - а как понять кого обслуживает наш сервер лицензирования?

Вспоминать и бежать по всем кластерам/серверам 1С и смотреть состав рабочих серверов и их ТНФ? - очень долго и ненадёжно, так как можем просто забыть что-то.
Вести какую-то табличку? - она точно устареет и будет неактуальной.
Видеть всё где-то в одном месте? - классно, но пока такого инструмента нет (ждём 8.5.2).

❗️Сейчас же у нас всё таки есть возможность узнать какие кластера 1С обслуживает наш сервер лицензирования, а именно:

Для Windows:
▫️Открываем Диспетчер задач на сервере лицензирования - вкладка "подробности"
▫️Правой кнопкой мыши по имени любого столбца - Выбрать столбцы
▫️Ставим галку "Командная строка". Теперь у нас в Подробностях появился столбец с отображением Командной строки приложения
▫️Ищем процессы rmngr и rphost отсортировав список по колонке "Имя"

В командной строке мы видим надпись "-reghost SERVER1C-2" - это и есть имя сервера к которому в кластер его службы 1С был добавлен наш сервер лицензирования.

Для Linux - инструмент htop, в остальном всё точно так же.

Таким образом мы видим факт обслуживания, что является объективной информацией.

На примере из скриншота видно что SERVER1C обслуживает помимо самого себя (на нём есть кластер с базами) ещё и сервер SERVER1C-2.
Идём на SERVER1C-2 и видим что там server1c является сервером лицензирования.

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

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

Это тоже можно реализовать:
▫️На сервере лицензирования запускаем ДВЕ службы 1С на разных портах ( прод -1540, 1541, 1560-1591, разработка (2540, 2541, 2560-2591) и под разными пользователями (прод - user1cprod, разработка - user1cdev)
▫️Ограничиваем Сетевым экраном доступ по портам на сервер лицензирования только с сервера прода и сервера разработки
▫️На файл программной серверной лицензии для прода ставим запрет для пользователя user1cdev и разрешение для user1cprod
▫️На файл программной серверной лицензии для разработки наоборот ставим запрет для пользователя user1cprod и разрешение для user1cdev
▫️На файл программной клиентской лицензии разрешение для user1cdev и для user1cprod
▫️На каждой службе сервера прода и разработки задать РАЗНЫХ администраторов сервера в консоли администрирования
▫️На каждой службе сервера лицензирования задать соответствующих администраторов сервера в консоли администрирования

Таким образом мы ограничим на уровне сети и знания логинов/паролей администраторов сервера 1С сценарий, когда на любой машине в локальной сети устанавливается серверная часть платформы и в созданный по умолчанию кластер добавляется наш сервер лицензирования.
А в момент долгого (более 20 минут) отсутствия одного из серверов (прод или разработки) сервер лицензирования высвободит их лицензию и отдаст неизвестному серверу по его требованию. И мы получим проблемы с работой нужных серверов.
Внутри сервера лицензирования мы с помощью прав на файлы сделали так чтобы службы разработки не смогла занять файл прода и наоборот.

❗️Нужен именно комплекс мер, а не что-то одно.
Тогда вероятность случайного/умышленного "угона" лицензии на другой кластер будет крайне мала.

Мой первый опыт в подкастах

https://vkvideo.ru/video-227129566_456239066

Спасибо Сергею Сыпачеву за приглашение и атмосферу!)

1️⃣🔤 Очень странное поведение после обновления платформы

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

Что за процедура?
Для Windows:
▫️Устанавливаем новую версию на сервер, снимая галку "установить как службу"
▫️Правим реестр ОС с указанием нового каталога исполняемых файлов службы Агент сервера 1с
▫️В технологическое окно:
- удаляем все сеансы
- останавливаем службу
- дожидаемся остановки всех процессов rphost, rmngr, ragent
- запускаем службу

Для Linux всё тоже самое, только вместо реестра заменяем симлинк файла службы на новый

Заходим в 1С и всё работает, по крайней мере так было последние несколько лет стабильно.

Но при обновлении именно на 27 версию начались чудеса: странные ошибки как на картинке, исчезновение кнопок у платформенных форм, ругань на отсутсвие каких-то очень странных файлов по странным путям и т.д.
При этом в ТехЖурнале тишь да благодать...

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

В итоге система стабилизировалась только после полной очистки каталога C:\Program Files\1cv8\srvinfo\reg_1541\snccntx

Да, в чек-листе от 1С в примере скрипта по остановке службы 1С всегда была строка: DEL /Q /F /S %CNTX_PATH%\snccntx*
НО:
Во-первых - ктож вообще читает инструкции? 😁
Во-вторых - давно уже обходилось обновление без этого действия, но вот опять 😄

❗️Если вы столкнулись с очень странными сообщениями платформы, то перезапустите службу 1С с очисткой сеансовых данных и не забудьте это сделать при обновлении версии платформы!

🔤🔤🔤 Временные таблицы в postgresql.

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

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

Все мы знаем, что временные таблицы сеанса postgres размещаются в оперативной памяти, пока не исчерпают обьем, указанный в параметре temp_buffers.
И конечно есть соблазн купить много оперативной памяти и выкрутить этот параметр в бОльшую сторону.
Например вместо рекомендуемых 128-256МБ поставить 2ГБ.
И конечно же ожидать от этого только плюсы и увеличение скорости работы с временными таблицами.

Оказалось что при достаточно больших значениях temp_buffers, 1ГБ и более (но как и при любом тесте многое зависит от железа и эта цифра может быть как больше так и меньше), удаление временной таблицы из памяти занимает достаточно продолжительное время.
Это происходит из-за того что при работе с памятью системе нужно последовательно пройти все страницы и освободить их, при размере временной таблицы в 1ГБ таких проходов около 0.5 млн.

В итоге пришли в неожиданному выводу, что эффективнее наоборот уменьшить temp_buffers, но при этом вынести табличное пространство для временных таблиц на диск в оперативной памяти (RAM-диск, tmpfs).
Так как удаление файла размером в 1ГБ это очень быстрая файловая операция, а не последовательный проход страниц.

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

За это отвечает параметр в postgresql.conf - temp_tablespaces

Итого, нам нужно смонтировать каталог в tmpfs, дать на него права пользователю и группе postgres и указать его абсолютный путь в параметре temp_tablespaces.

Только будьте внимательны!
Размер каталога должен соответствовать профилю вашей нагрузки.

Тут проще всего ориентироваться на статистику максимального размера занимаемого места временными таблицами.
К сожалению именно такого разреза статистики в postgresql нет, но зато это знает операционная система.
Просто выносим временные таблицы в отдельное табличное пространство на диске, где работаем сейчас.
И ставим размер свободного или занятого места на этом диске на мониторинг в вашей системе мониторинга.
Ждём релевантный для вашего профиля нагрузки период и смотрим там максимальный показатель занятого места.
Прибавляем к нему 20-30% и именно столько нам нужно будет выделить место в оперативной памяти для уверенности в том что его хватит.

Опять же, это справедливо для случая когда мы не меняем параметр temp_buffers. Если же мы его уменьшаем, то таблиц на диске будет еще больше и вам нужна новая статистика для определения необходимого объема.

Это особенно актуально в системах, где вы часто видите запрос drop temptable, который длится более 1 сек.

До встречи на Инфостарте!
Расскажу новое и интересное)