​​У меня на днях будет задача по переносу баз 1С с MSSQL на PostgreSQL. Переезжаем полностью с Windows Server на Debian. По этому поводу у меня есть относительно свежая ссылка (2022 год):
⇨ Частые вопросы по миграции базы данных 1С с MS SQL на PostgreSQL
Пришло время с ней поработать. Делаю для вас краткую выжимку, чтобы можно было использовать как шпаргалку. А когда сделаю перенос, напишу, как всё организовал. У меня есть свой подход к организации сервера для 1С.

1️⃣ Тюним PostgreSQL под ресурсы системы. Особое внимание на параметры shared_buffers, work_mem, temp_buffers, huge_pages. Если будете использовать сборку от PostgreSQL Pro, то там все важные параметры настраиваются автоматически после установки пакета.

Отдельно обратите внимание на autovacuum_max_workers. Параметр вычисляют так: кол-во vCPU / 2. И так же по этой теме настраиваем autovacuum_vacuum_scale_factor, autovacuum_analyze_scale_factor, autovacuum_vacuum_cost_limit.

2️⃣ Тюним систему под максимальную производительность СУБД:
sysctl -w vm.swappines=2
sysctl -w vm.overcommit_memory=2

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

4️⃣ Выгружать и загружать dt файлы быстрее и удобнее через автономный сервер ibcmd. В этот момент базу лучше отключить от сервера приложений, либо просто остановить его на время, если есть возможность.

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

#1С

Свежая информация на тему настройки сервера 1С + PostgreSQL 15 на Debian. Я буквально на днях её выполнял. Моя статья по этой теме на текущий день полностью актуальна:

⇨ Установка и настройка 1С на Debian с PostgreSQL

Уточню только, что если будете настраивать выгрузку баз в dt, используйте сразу автономный сервер, если у вас нет желания и необходимости иметь полноценный клиент на сервере без установки графического окружения. Я этой теме много внимания уделил в статье, но необходимость в этом возникает редко и почти никому не нужно. А времени можно потратить много, так как настройка работы графических приложений через xvfb без установки полноценного рабочего стола нетривиальна и замороченна.

❗️ Важное дополнение, которое возможно сэкономит кому-то время. Сборка PostgreSQL 15 с патчами для 1С от Postgres Professional не поддерживает установку на Debian 12. Нету репозитория для этой системы. Мне хотелось всё развернуть на 12-й версии. Обманул установщик, подключил репы на Debian 12, но всё равно СУБД не установилась. Возникают проблемы с зависимостями.

Для получения этой версии PostgreSQL, необходимо сделать запрос на сайте https://1c.postgres.ru/ и вам придёт инструкция на почту. Кому не хочется этим заниматься, сразу даю ссылку на скрипт подключения репозиториев для всех поддерживаемых систем:

# wget https://repo.postgrespro.ru/1c-15/keys/pgpro-repo-add.sh
# sh pgpro-repo-add.sh

Или вот готовый репозиторий под Debian 11:

deb http://repo.postgrespro.ru/1c-15/debian bullseye main

Соответственно, если у вас 1С сервера на Debian 11, не торопитесь обновлять систему. А я уже кое-где собирался обновляться. Надо подождать, пока не появятся репозитории Postgres Professional под 12-ю версию.

#1С

У меня печальные новости для тех, кто использует сервер 1С под Linux. До недавнего времени он для запуска не требовал серверную лицензию, если использовалось не больше 12-ти клиентских соединений.

Я эту возможность всегда использовал для дублирования основного сервера. Копию использовал для тестирования обновлений, для восстановления бэкапов, для проверки восстановленных баз, для выгрузки dt, для тестирования баз и т.д. В общем, для служебных нужд. Пользователей туда не пускал.

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

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

Кто-то сталкивался уже с этим? Будет очень жаль, если работу Linux сервера без лицензии уберут совсем. Для тестовых целей это было очень удобно.

#1С

Попереживал тут на днях из-за своей неаккуратности. Настроил сервер 1С примерно так же, как описано у меня в статье:
⇨ Установка и настройка 1С на Debian с PostgreSQL

Сразу настроил бэкапы в виде обычных дампов sql, сделанных с помощью pg_dump. Положил их в два разных места. Сделал проверки. Всё, как описано в статье. Потом случилось то, что 1С убрали возможность запускать сервер на Linux без серверной лицензии. И вся моя схема проверки бэкапов сломалась, когда я восстанавливал дампы на копии сервера и там делал выгрузку в dt. И считал, что всё в порядке, если дамп восстановился, dt выгрузился и нигде не было ошибок. На основном сервере я не хочу делать такие проверочные восстановления.

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

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

В итоге всё прошло успешно. Восстановиться из бэкапов в виде дампов довольно просто. За это их люблю и если размер позволяет, то использую именно их. Последовательность такая:

1️⃣ Находим и распаковываем нужный дамп.

2️⃣ Создаём новую базу в PostgreSQL. Я всегда в новую восстанавливаю, а не в текущую. Если всё ОК и старая база не нужна, то просто удаляю её, а новую делаю основной.
# sudo -u postgres /usr/bin/createdb -U postgres -T template0 base1C-restored

3️⃣ Проверяю, создалась ли база:
# sudo -u postgres /usr/bin/psql -U postgres -l

4️⃣ Восстанавливаю базу из дампа в только что созданную. ❗️Не ошибитесь с именем базы.
# sudo -u postgres /usr/bin/psql -U postgres base1C-restored < /tmp/backup.sql

5️⃣ Иду в консоль 1С и добавляю восстановленную базу base1C-restored.

Если сначала создать базу через консоль 1С и восстановить в неё бэкап, будут какие-то проблемы. Не помню точно, какие, но у меня так не работало. Сначала создаём и восстанавливаем базу, потом подключаем её к 1С.

Мораль какая. Бэкапы надо восстанавливать и проверять, чтобы лишний раз не дёргаться. Я без этого немного переживаю. Поэтому люблю бэкапы в виде сырых файлов или дампов. По ним сразу видно, что всё в порядке, всё на месте. А если у тебя бинарные бэкапы, сделанные каким-то софтом, то проверяешь ты их тоже каким-то софтом и надеешься, что он нормально всё проверил. Либо делать полное восстановление, на что не всегда есть ресурсы и возможности, если речь идёт о больших виртуалках.

#1С #postgresql

Для тех, кто работает с 1С, могу порекомендовать сайт Кухара Богдана. Я давно его знаю, подписан на его ютуб канал, смотрю выпуски. Не могу сказать, что там прям что-то очень нужное и полезное. Обычная базовая информация для системного администратора. Много рекламы его курса, куда он выносит наиболее интересные моменты из своих материалов.

Привлекло моё внимание его небольшой bat скрипт для бэкапа файловых баз в Windows, который он недавно анонсировал. Я много раз настраивал различным заказчикам файловые базы где-то на выделенном сервере. Это хорошее и экономное решение для работы 2-3 человек с базой. Актуально для аутсорсеров, где каждый бухгалтер ведёт кучу баз клиентов, и при этом работает там в основной один или с помощником.

- Описание скрипта
- Видео обзор

Файловая база представляет из себя обычный файл на диске, но при этом внутри там полноценная база данных. Не всегда простым копированием можно получить рабочий бэкап. Если во время копирования с базой работали пользователи, база может оказаться битой. То же самое с выгрузкой в dt. Она не является полноценным бэкапом, так как нет 100% гарантии, что из неё получится развернуть базу.

Самым надёжным способом сделать бэкап файловой базы - выгнать всех пользователей, запретить им вход и базу и после этого скопировать файл 1Cv8.1CD. Именно это и делает указанный скрипт, и не только. Он умеет:

▪️ Выгонять всех пользователей из базы и завершать работу платформы.
▪️ Если платформа зависла и штатно не завершила работу, завершает её принудительно.
▪️ Если база опубликована через Apache 2.4 на этом же сервере, то завершает сеансы 1С в веб сервере.
▪️ Жать бэкап базы с помощью 7zip.
▪️ Вести лог файл своей работы.
▪️ Запускаться через планировщик Windows.
▪️ Автоматически удалять старые копии.

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

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

⇨ PostgreSQL 16 + Cервер 1С x64 и 1С 8.3.23 на Ubuntu 22.04

#1С

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

▶️ Из чего складывается производительность 1С и с чего начать расследование тормозов

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

◽Если на сервере СУБД настроены все необходимые регламентные операции (обновление статистики, перестройка индексов, автокавкуум хорошо отлажен) и параметры адекватны железу, то это самое последнее место, куда следует лезть за поиском тормозов. Чаще всего тормозит что-то другое.

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

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

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

◽Никакой разницы производительности сервера 1С в редакциях ПРОФ и КОРП нет. Там полностью одинаковые экзешники сервера.

◽RAGENT и RMNGR - это чёрные ящики. Полностью закрытый код, на работу которого вы никак влиять не можете. Весь код 1С выполняется в RPHOST. И тормозит именно ваш код.

◽Главный грех программиста - поиск по журналу регистраций на продуктовой базе. Это вешает RMNGR от большой нагрузки. Любую базу можно положить через поиск в журнале по неиндексированному полю.

🔥 Полнотекстовый поиск нужно обязательно отключать на базах более 2 Гб.

◽Очень часто на сервере 1С тормозит диск из-за каталога сеансовых данных. Он хранится на диске. Постоянно перезаписывается огромный объём данных. Его надо вынести куда-то на быстрый диск. То же самое для временных файлов пользователя, под которым работает 1С. Их тоже надо куда-то на быстрый диск поместить. Всё это делается средствами операционной системы. В самой 1С настроек на этот счёт нет.

◽В dt можно выгрузить базу любого объёма. Никаких ограничений нет. Если не получается выгрузить базу, скорее всего у вас не хватает места на диске на сервере 1С для этого.

◽Очень часто тормоза дают фоновые задания. Их надо аккуратно настраивать.

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

#1С

Пришлось не так давно переносить виртуальный сервер Windows с установленными программными клиентскими лицензиями 1C. Мне не так часто приходится с ними взаимодействовать, так что технических нюансов их работы я не знаю, как и не имею большой практики использования. Знаю только, что они жёстко привязаны к железу и очень чувствительны к изменениям. Расскажу, как у меня прошёл перенос.

На гипервизоре Proxmox стало не хватать ресурсов. Было принято решение взять в аренду идентичный сервер, чтобы разгрузить существующий и добавить ресурсов виртуалке. Как минимум процессор там был точно такой же. Изменилась версия гипервизора с 7-й на 8-ю. Воссоздал на новом сервере виртуалку с идентичными настройками и перенёс вручную диск виртуальной машины.

Пару дней сервер проработал нормально, а потом ругнулся на программную лицензию из-за изменения железа. Меня удивило, что случилось это не сразу. В информационном сообщении было указано, что изменилась цифра в версии биоса и mac адрес сетевого интерфейса. Его я забыл скопировать со старого сервера. Это был мой недосмотр. Хоть я наверняка и не знал, что есть привязка по маку, но надо было в любом случае таким же его оставить.

Интересное произошло дальше. Я изменил mac адрес сетевого интерфейса на старый и перезагрузил сервер. Он всё равно ругнулся на изменившийся mac адрес адаптера, показывая в качестве нового адреса тот, что я уже успел поменять на старый. Думаю, ладно, ничего не поделать. Пошёл добывать документы, пинкоды и т.д. Когда всё нашёл, решил перезагрузиться ещё раз. И, о чудо, всё заработало.

Несмотря на то, что версия bios всё же изменилась, лицензия не слетела. Изменив mac адрес обратно на старый, я вернул программным лицензиям жизнь без необходимости их обновления. Версия bios в моём случае выглядела примерно так:

SeaBIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org, 01.04.2014

Соответственно, на старом сервере цифры были немного другие. Вот для примера версия bios с другого гипервизора:

SeaBIOS rel-1.16.2-0-gea1b7a073390-prebuilt.qemu.org, 01.04.2014

❗️Решил написать эту заметку, потому что везде в интернете видел информацию о том, что лицензия привязывается к версии bios. При переезде с гипервизора на гипервизор, да и просто при обновлении на новый релиз, информация о биосе меняется. Но лично в моём случае необходимости в обновлении лицензии в связи с этим не возникло. Также я не знал, что если вернуть конфигурацию обратно, то лицензии восстанавливаются. Думал, что они слетает безвозвратно.

#1С