🔤🔤🔤 Журнал транзакций в 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С!

🔤🔤🔤 OOMKiller - страшный сон Администратора баз данных.

Попробуем выяснить основные причины, неочевидные особенности работы Лучшей в мире платформы 1С и возможно ли с этим что-то сделать…
OOMKiller –система защиты Linux от перерасхода памяти.
Срабатывает, убивая самый «толстый» по памяти процесс в Операционной системе при приближении расхода памяти к 95%

Итак, в чём же вообще проблема?

В том, что неожиданно падает сервер PostgreSQL и по системным логам мы понимаем что он пал жертвой убийства со стороны OOMKiller.
Основной причиной такого поведения PostgreSQL является ошибка планировщика в том, где делать сортировку результата запроса.
Ошибка планировщика чаще всего возникает из-за отсутствия актуальной статистики по базе – это корневая причина

В итоге, при планировании запроса, планировщик уверен что сортировку можно произвести в памяти, так как по его прикидкам она влезет в параметр work_mem (например 256MB), так как получит на вход небольшое количество строк для сортировки и их размер тоже будет небольшим (например 100 строк, размером по 30КБ каждая). Эти данные планировщик получает из статистики.

Начав выполнение запроса СУБД уже не может ослушаться этой декларации планировщика и выполняет сортировку в памяти.
НО вместо предполагаемых 100 строк по 30КБ, что спокойно вмещается в 256МБ нам для сортировки прилетело 1,5млн строк по 30КБ, что уже занимает 42ГБ!
В итоге в процессе сортировки такого объёма в памяти, эта самая память или совсем закончится или её расход приблизится к уровню сработки OOMKiller-а.

Ситуацию усугубляется следующим:
❗️Убивать процессы нельзя! Это приведет к перезапуску всего PostgreSQL!
▫️work_mem устанавливается на каждое соединение. Т.е. у нас может сложится ситуация когда сразу несколько пользователей 1С сделают запрос к СУБД на такого рода сортировку…
▫️ Каждое соединение в PostgreSQL работает в отдельном процессе и при этом процесс не умеет худеть по памяти, он просто убивается как становится никому не нужным.
▫️ Платформа 1С удерживает idle соединения при необходимости (например в нём создавалась временная таблица и её можно будет переиспользовать) . Т.е. у нас может сложится ситуация, когда запрос выполнился, заняв 20ГБ RAM, при этом соединение удерживается и используется для других запросов, которым столько RAM не нужно.

Методы борьбы с этими негативными моментами:
❗️Убивать процессы нельзя! Это приведет к перезапуску всего PostgreSQL! А значит увидев что процесс работает (не idle) наш единственный шанс корректно завершить этот запрос, это отменить его выполнение на сервере 1С вычислив его по номеру соединения с СУБД.
▫️Необходимо содержать статистику в максимально актуальном состоянии. Настраивая агрессивный autovacuum, устанавливая нестандартные значения сработки autovacuum на больших таблицах, проводить vacuum analyze как регламентную операцию и т.д.
▫️Уменьшить work_mem, отслеживая как это повлияет и на план и на работу дисков
▫️Настроить OOMKiller. Чтобы он не убивал, а замораживал процесс OOMPolicy=continue, но это опасно, так как в итоге вся память может быть поглощена и работы вообще остановится.
▫️Отдельный пункт для борьбы с толстыми idle.
Мы можем вычислить ТОП-3 процессов, потребляющих память

ps -eo pmem,vsize,pid,cmd | sort -k 1 -nr | head -3

и увидеть такую картину:

6.6 12095572 2380533 postgres: postgres erp 10.27.24.1(64722) idle
6.6 12015844 2380844 postgres: postgres erp 10.27.24.1(64837) idle
6.4 12091534 2380682 postgres: postgres erp 10.27.24.1(64735) SELECT

Видим что в топе процессы с idle и только 1 с select.
В PostgreSQL есть параметр idle_session_timeout, по умолчанию 0.
Но мы можем выставить его в 3 сек, подождать 7 сек и обратно убрать в 0.

ALTER SYSTEM SET idle_session_timeout = 3000;
'select pg_reload_conf();
'ALTER SYSTEM RESET idle_session_timeout;

Таким образом мы корректно прервём соединения с 1С и СУБд сама корректно завершит наши объевшиеся процессы.
Негативный побочный эффект – временные таблицы платформе 1С придётся создать заново, но по сравнению с перезапуском СУБД это допустимо

1️⃣🔤 Почему может не формироваться Технологический журнал 1С?

ТехЖурнал лучшей в мире платформы 1С (ТЖ) - это реальное отражение работы 1С с объективными цифрами и данными.

Он давно стал одним из основных инструментов в работе Экспертов, а уж при работе с КОРП клиентами по линии РКЛ это вообще незаменимая вещь!

При этом достаточно часто встречаемся с ситуацией, когда ТЖ "не хочет" формироваться и начинаются танцы с бубнами...

Ниже опишу основные причины этих танцев:

▫️Права на каталог сбора ТЖ.
Проблема проявляется когда есть процессы 1С, работающие из под разных пользователей операционной системы.
Например:
- Служба агента кластера (ragent, rmngr, rphost) 1С работает из под v81cuser, а служба Удаленного сервера администрирования (ras) работает под другим пользователем ras1c.
- Процессы кластера 1С (ragent, rmngr, rphost) работают под разными пользователями, каждый под своим
- Вместе с кластером 1С установлен также web-сервер с модулем публикации 1С, который тоже работает под своим пользователем

В итоге после настройки сбора ТЖ каталог будет создан с правами того пользователя чей процесс первым увидит и «осознает» новую или изменившуюся настройку, а остальным туда доступ на изменение будет закрыт. И мы получим, например, что у нас пишется ТЖ только процесса ras.

Рецепт: Необходимо заранее создать все каталоги размещения файлов ТЖ ( например log location="C:\TJ\RKL") и выдать им права на изменение всем пользователям всех процессов системы, которые могут писать ТЖ.

Ну и если уж совсем ничего не помогает, то создайте заранее каталог (C:\TJ), дайте на него все права всем и потом настройте сбор ТЖ в этот каталог.

▫️В файле conf.cfg текущей версии платформы прописали ConfLocation

Тогда система будет искать файл настройки ТЖ (logcfg.xml) именно в этом каталоге, а не каталогах по умолчанию %PROGRAMFILES%\1cv8\conf, /opt/1cv8/conf

Рецепт: либо расположить файл logcfg.xml в каталоге указанном в ConfLocation либо убрать эту строку из файла conf.cfg

▫️И наверное самое неочевидное – в файле logcfg.xml есть более одного тега log location и в одном из них указан несуществующий диск в системе Windows либо примонтированный каталог Linux

Тогда рандомно будет то записываться ТЖ, то нет, то от одних процессов, то от других.

Рецепт: во всех тегах log location файла logcfg.xml должны быть указаны существующие в операционной системе диски Windows либо примонтированный каталог Linux

▫️В каталоге сбора ТЖ находятся посторонние файлы

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

🔤🔤🔤 8.5.1.1150 Толстый клиент

Новая мини-рубрика - срочно в канал!)))
В ней буду освещать критичные на мой взгляд ошибки, которые ещё не зарегистрированы.

Вот и пришло время обновиться на 8.5...

И поймали ошибку на скриншоте

Условие ошибки:
В конфигурации должен быть добавлен хотя бы один Элемент стиля
Подключаемся к ней на платформе 8.5.1.1150 в клиент-серверном режиме (в файловом всё работает)
Запускаем Толстый клиент
Авторизация 1С

❗️При этом конфигуратор запускается

Рецепты:
1. Не обновляться на 8.5, если используете Толстые клиенты
2. Перейти на прозрачную авторизацию AD, если давно собирались, но никак не находили для этого время
3. Указать логин и пароль в параметрах запуска, если это позволяет ваш сценарий

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

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

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

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

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

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

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

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

Всем привет!

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Что делать?

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

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

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

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

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

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

ALTER SYSTEM RESET autovacuum;
select pg_reload_conf();

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

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

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

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

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

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

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

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

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

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

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

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

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

1️⃣🔤 Мифы о DT

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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