ServerAdmin.ru
28.9K subscribers
304 photos
35 videos
13 files
2.63K links
Авторская информация о системном администрировании.

Информация о рекламе: @srv_admin_reklama_bot
Автор: @zeroxzed

Второй канал: @srv_admin_live
Сайт: serveradmin.ru
Download Telegram
Решил добить тему с публикацией баз в . К прошлой статье в комментах мне сказали, что опубликовать базу можно даже без графического окружения на Linux. Достаточно только веб сервера и некоторых компонентов сервера для Linux. Мне идея понравилась, решил проверить.

И реально, опубликовать базу и настроить доступ через web можно с использованием обычной консоли и веб сервера apache. Проверил все и реализовал на Centos 8.

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

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

https://serveradmin.ru/publikacziya-baz-1s-v-centos/

#1с #статья
​​На днях писал заметку про мониторинг SSD дисков в связи с повышенным расходом ресурса записи. Решил повнимательнее посмотреть на сервер, чтобы понять, кто там так много пишет. Оказалось, что это PostgreSQL и конкретно временные данные статистки, живущие в директории pg_stat_tmp.

Выдержка из документации по поводу этого параметра:

Задаёт каталог, в котором будут храниться временные данные статистики. Этот путь может быть абсолютным или задаваться относительно каталога данных. Значение по умолчанию — pg_stat_tmp. Если разместить целевой каталог в файловой системе в ОЗУ, это снизит нагрузку на физическое дисковое хранилище и может увеличить быстродействие. Задать этот параметр можно только в postgresql.conf или в командной строке при запуске сервера.

В документации указано, что эту директорию можно вынести в ram диск, что я и сделал в итоге. По дефолту она занимает всего 25 мегабайт, так что я решил с запасом сделать диск размером 1G.
mkdir /var/lib/pgsql_stats_tmp
chown postgres:postgres /var/lib/pgsql_stats_tmp

Теперь добавляем в fstab (не забудьте в конце переход на новую строку поставить):
tmpfs /var/lib/pgsql_stats_tmp tmpfs size=1G,uid=postgres,gid=postgres 0 0

Монтируем диск в систему:
mount /var/lib/pgsql_stats_tmp

Меняем параметр в postgresql.conf:
stats_temp_directory = '/var/lib/pgsql_stats_tmp'

Перезапускаем postgresql:
systemctl restart postgrespro-1c-13

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

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

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

#postgresql #1С
Я полностью обновил и переработал свою старую статью по установке и настройке Сервера вместе с базой PostgreSQL на Debian. Постарался собрать в одном месте весь свой опыт по этой теме.

В статье показано:
1️⃣ Установка и настройка сервера и PosgtreSQL.
2️⃣ Привожу пример создания баз данных на этом сервере и подключение к ним.
3️⃣ Бэкап и обслуживание postgresql баз утилитами сервера бд. Рассказываю про свой подход к этому процессу и привожу скрипты автоматизации.
4️⃣ Рассказываю, как тестирую восстановление из дампов и делаю контрольную проверку в виде выгрузки баз в .dt файлы с помощью клиента Linux. Причём последний запускается в консоли без графического окружения. Всё это автоматизируется скриптами.
5️⃣ Рассказываю про свои подходы к мониторингу этих бэкапов и выгрузок, чтобы всегда быть уверенным в том, что у тебя есть гарантированно рабочие бэкапы.

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

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

https://serveradmin.ru/ustanovka-i-nastrojka-1s-na-debian-s-postgresql/

#статья #1с #postgresql
​​На прошлой неделе прочитал достаточно интересную статью - Почему PostgreSQL не лучше MS SQL, где автор сравнил PostgreSQL и MSSQL для использования с . Она мне показалась интересной, поэтому решил сделать для вас выжимку основной информации оттуда, как я её понял!

MSSQL - 20 лет сотрудничества с . К ней все привыкли, у неё лучшие интерфейсы для управления БД с низким порогом входа как для разработчиков, так и поддержки.
 PostgreSQL - настройки в текстовом файле, командная строка Linux, скрипты для обслуживания и бэкапов. Всё это надо изучать, разбираться.
В среднем на MSSQL работает быстрее. Большинство запросов выполняются примерно одинаково. Но бывает так, что на Postgres запросы выполняются значительно медленнее, но обратные ситуации не наблюдаются. То есть Postgres в лучшем случае будет работать так же, разработка под эту БД более требовательна к качеству кода запросов. Ошибок не прощает.
PostgreSQL более экономично относится к памяти, умеет отдавать неиспользованную память обратно системе. MSSQL пожирает всю память, что есть и хочет еще больше.
Бесплатные версии MSSQL и PostgreSQL не сравнимы по функционалу. Последняя уделывает Express версию MSSQL по всем параметрам. Так что по деньгами PostgreSQL будет значительно дешевле, либо вообще бесплатно.
Стоимости MSSQL Enterprise и Postgres Pro Enterprise на одном и том же числе пользователей и железе будут отличаться примерно в 3 раза в пользу Postgres.
У Postgres на Windows много недостатков. Лучше ставить Linux.
У Postgres Pro хорошая русскоязычная поддержка. Реально решают проблемы. Помогают разобрать тормоза конкретных запросов.

Автор статьи - Антон Дорошкевич, руководитель ИТ в компании «Инфософт», в Новосибирске. Является сертифицированным экспертом по эксплуатации PostgreSQL. Уровень сертификата «Эксперт». В течение последних 15-ти лет является эксплуататором больших многокластерных систем на тысячи пользователей и сотни баз – что на MS SQL, что на PostgreSQL.

#1с #postgresql #mssql
​​Мониторинг сервера на Windows в Zabbix

Мне понадобилось замониторить некоторые параметры сервера , установленного на Windows. Не часто приходится подобным заниматься, так что готового решения под рукой не было. Стал разбираться. Расскажу, какой способ в итоге использовал лично я. Как это обычно бывает с Zabbix, вариантов настройки мониторинга может быть много.

У в комплекте есть служба ras, которая выдаёт инфу о кластере. И есть клиент к этой службе rac, который с помощью различных ключей получает от службы нужную информацию.

Регистрируем ras как службу Windows (у меня порты кластера нестандартные, 1640 и 1645 вместо 1540 и 1545):

sc create "1C RAS" binpath= "C:\Program Files (x86)\1cv8\8.3.18.1208\bin\ras.exe cluster --port=1645 localhost:1640 --service" displayname= "1C RAS" start=auto

Запускаем службу и делаем к ней запрос на получение uuid кластера, который нам потом нужен будет во всех запросах:

"C:\Program Files (x86)\1cv8\8.3.18.1208\bin\rac.exe" localhost:1645 cluster list

Запишите полученный uuid кластера. Ниже пример запроса, который покажет все активные сессии:
"C:\Program Files (x86)\1cv8\8.3.18.1208\bin\rac.exe" localhost:1645 session --cluster=62734fb4-f267-4708-9ccf-e929b480b9f4 list

Можно посчитать их количество и на выходе получить просто число:

"C:\Program Files (x86)\1cv8\8.3.18.1208\bin\rac.exe" localhost:1645 session --cluster=62734fb4-f267-4708-9ccf-e929b480b9f4 list | find /c "1CV8C"

Это число мы и передаём в Zabbix с помощью UserParameter. Дальше как обычно - шаблон, айтемы, графики, триггеры. По аналогии вытаскиваются любые другие метрики, которые умеет получать rac. Мне помимо подключений нужна была инфа по BackgroundJob и licenses:

rac session --cluster=uuid list --infobase=uuid | find /c "BackgroundJob"

rac session --licenses --cluster=uuid list

Забирайте в закладки. Zabbix постоянно меняется, но принципы и подходы остаются те же. Когда надо будет, на основе этой инфы под любую версию Zabbix можно быстро сделать мониторинг.

#zabbix #1с #windows
​​YaAdmin - бесплатный помощник администратора . Программа с говорящим названием 😁 Только слова в названии не хватает. Прога упрощает мониторинг и управление сервера . Как я понял, написана программистом для привлечения внимания к своим курсам и услугам по аналогии с известной и полезной программой Обновлятор . Код программы закрыт.

YaAdmin  умеет следующее:

Обзор всех процессов, связанных с через встроенный диспетчер задач. Удобно сразу оценить нагрузку, которую создаёт именно .
Мониторинг и управление сессиями на сервере терминалов и RDS. В одном месте видно пользователей терминала и их подключения к серверу , какие ресурсы потребляют их подключения. Можно сразу увидеть, чьем подключение съело всю оперативную память.
Удалённое управление компьютерами пользователей .

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

Нужно понимать, что программа очень простая на основе возможностей самой ОС. Часть функционала реализована через bat файлы (запуск, остановка сервера, сброс подключений и т.д.), которые запускаются через саму программу. Батники эти можно менять. Подобный софт подойдёт для небольших компаний и начинающих админов, которые приглядывают за единственным сервером , который по совместительству является еще и сервером терминалов. Могу порекомендовать такую связку софта для подобного управления: YaAdmin + RDP Defender + Обновлятор-.

Установка и функционал показаны в видео - https://youtu.be/12MI0f0U0_k
Сайт - https://yaadmin.kuharbogdan.com/

#1С #Windows
​​Когда писал предыдущий пост про Yaadmin, упомянул Обновлятор-, про который я вообще ни разу не писал и не вспоминал. А это отличная программа, которую я знаю уже много лет. С её помощью можно в автоматическом режиме обновлять базы данных . Программа пригодится даже тем, у кого только одна файловая база .

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

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

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

Демонстрация работы - https://youtu.be/U5qBBEL7wnY
Сайт - https://helpme1s.ru/obnovlyator-1s-gruppovoe-paketnoe-obnovlenie-vsex-baz-za-odin-raz

#1С
Технический пост, который уже давно нужно было сделать, но всё руки не доходили. На канале много содержательных заметок по различным темам. Иногда сам через поиск ищу то, о чём писал. Ниже набор наиболее популярных тэгов по которым можно найти что-то полезное (и не очень).

#remote - все, что касается удалённого управления компьютерами
#helpdesk - обзор helpdesk систем
#backup - софт для бэкапа и некоторые мои заметки по теме
#zabbix - всё, что касается системы мониторинга Zabbix
#мониторинг - в этот тэг иногда попадает Zabbix, но помимо него перечислено много различных систем мониторинга
#управление #ITSM - инструменты для управления инфраструктурой
#devops - в основном софт, который так или иначе связан с методологией devops
#kuber - небольшой цикл постов про работу с kubernetes
#chat - мои обзоры на популярные чат платформы, которые можно развернуть у себя
#бесплатно - в основном подборка всяких бесплатностей, немного бесплатных курсов
#сервис - сервисы, которые мне показались интересными и полезными
#security - заметки, так или иначе связанные с безопасностью
#webserver - всё, что касается веб серверов
#gateway - заметки на тему шлюзов
#mailserver - всё, что касается почтовых серверов
#elk - заметки по ELK Stack
#mikrotik - очень много заметок про Mikrotik
#proxmox - заметки о популярном гипервизоре Proxmox
#terminal - всё, что связано с работой в терминале
#bash - заметки с примерами полезных и не очень bash скриптов или каких-то команд. По просмотрам, комментариям, сохранениям самая популярная тематика канала.
#windows - всё, что касается системы Windows
#хостинг - немного информации и хостерах, в том числе о тех, кого использую сам
#vpn - заметки на тему VPN
#perfomance - анализ производительности сервера и профилирование нагрузки
#курсы - под этим тэгом заметки на тему курсов, которые я сам проходил, которые могу порекомендовать, а также некоторые бесплатные курсы
#игра - игры исключительно IT тематики, за редким исключением
#совет - мои советы на различные темы, в основном IT
#подборка - посты с компиляцией нескольких продуктов, объединённых одной тематикой
#отечественное - обзор софта из реестра отечественного ПО
#юмор - большое количество каких-то смешных вещей на тему IT, которые я скрупулезно выбирал, чтобы показать вам самое интересное. В самом начале есть шутки, которые придумывал сам, проводил конкурсы.
#мысли - мои рассуждения на различные темы, не только IT
#разное - этим тэгом маркирую то, что не подошло ни под какие другие, но при этом не хочется, чтобы материал терялся, так как я посчитал его полезным
#дети - информация на тему обучения и вовлечения в IT детей
#развитие_канала - серия постов на тему развития данного telegram канала

Остальные тэги публикую общим списком без комментариев, так как они про конкретный софт, понятный из названия тэга:
#docker #nginx #mysql #postgresql #gitlab #asterisk #openvpn #lxc #postfix #bitrix #икс #debian #hyperv #rsync #wordpress #zfs #grafana #iptables #prometheus #1с #waf #logs #netflow
​​Знакомлю вас с необычным продуктом, аналогов которого я не видел. Речь пойдёт о веб панели для управления кластером , причем не важно, где установленном, на Windows или Linux. У программы, на мой взгляд, не очень удачное название - Панель управления сервисами и компонентами (ПУСК). По нему совершенно не понятно, о чём идёт речь, плюс используется употребляемое в других значениях слово пуск.

Программа бесплатная, написана на Java. Внешний вид максимально приближённо копирует интерфейс штатной консоли для администрирования . Для управления кластером используются стандартные возможности Сервера администрирования кластера (ras), который входит в поставку технологической платформы :Предприятие 8.

С помощью ПУСК можно выполнять привычные действия:
управление кластерами (на различных серверах, с различными версиями платформы );
управление информационными базами ;
управление сеансами и блокировками;
управление рабочими процессами и серверами;
управление менеджерами кластера;
статистика использования лицензий.

Как я уже сказал, программа написана на Java, так что для запуска достаточно установить Java версии не ниже 17 и запустить jar файл. Ну и не забыть открыть на фаерволе 8080 порт. Дальше всё делается через браузер. Инструкция по установке есть в архиве с программой, в папке doc. Авторы программы русскоязычные, так что всё подробно описано.

❗️Программа пока находится в статусе беты. Идёт активная разработка. В ближайшем релизе ожидается доработка скриптов запуска, интерфейса, тёмная тема, возможно в этом, либо следующем релизе массовая обработка над информационными базами.

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

Сайт - https://it-expertise.ru/pusk/
Обсуждение - https://infostart.ru/public/1713088/

#1С
❗️Подобные новости не мой формат, но на всякий случай предупреждаю, так как походу завтра эпичная массовая проблема будет:

Критично: срочно, сегодня обновите платформу ":Предприятие 8"!
https://1c.ru/news/info.jsp?id=29958

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

Фирма "" доводит до сведения пользователей и партнеров, что в версиях платформы ":Предприятие" 8.3.22.1672, 8.3.22.1603, 8.3.21.1607, 8.3.21.1508, 8.3.21.1484, 8.3.20.2076, 8.3.20.2039, 8.3.19.1665, 8.3.19.1659, 8.3.18.1902, 8.3.18.1894, 8.3.17.2733, 8.3.17.2665 обнаружена критическая проблема, которая может привести к закрытию приложения в начале работы с программой.

Изменение внешних условий 15.11.2022 может существенно повысить вероятность проявления данной проблемы – предполагается, что многие пользователи перечисленных версий завтра не смогут работать.

Проблема не приводит к потере данных пользователей.

Положил платформу windows64full_8_3_22_1704.rar к себе на Яндекс.Диск для тех, кто тоже не сможет сам скачать:
https://disk.yandex.ru/d/f5rJTFMavNWwJQ

#1С
последнее время стала часто менять установщик сервера под Linux. Сначала с переходом на единый дистрибутив поменялся процесс обновления и установки сервера. А теперь по мере изменения версий в рамках единого установщика тоже происходят заметные изменения. То gnome на сервер автоматом ставит, а не так давно вместо скрипта запуска для init.d, появился unit для systemd.

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

1️⃣ Останавливаем сервер . В зависимости от установленной версии, команда будет выглядеть по-разному. До 8.3.21 вот так:
# systemctl stop srv1cv83
После 8.3.21 примерно так:
# systemctl stop srv1cv8-8.3.21.1484@default

2️⃣ Я рекомендую сохранить настройки кластера из домашней директории /home/usr1cv8/.1cv8/1C/1cv8. Только текстовые файлы с настройками, больше ничего. У меня разок была ситуация, когда обновлял тестовый сервер, где .1cv8 была символьной ссылкой на другой том. По какой-то причине она была заменена на новую пустую директорию. Когда запустил сервер, очень удивился, что в списке баз пусто. А их там было штук 30. Сервер хоть и тестовый, я всегда сначала на нём проверял обновления, но всё равно перспектива добавления заново всех баз не радовала. Решил детальнее разобраться, что случилось и заметил, что символьная ссылка пропала. Вернул её на место и все базы восстановились.

Тем не менее, у меня были ситуации, когда я терял настройки сервера. Хоть и некритично, но всё равно неприятно. Лишняя работа. Рекомендую параметры сохранять перед обновлением.

3️⃣ Качаем дистрибутив единого установщика и копируем на сервер. Имя файла имеет примерно такой формат: server64_8_3_22_1709.tar.gz. Распаковываем:
# tar xzvf server64_8_3_22_1709.tar.gz
Можно сразу запустить установщик ./setup-full-8.3.22.1709-x86_64.run и интерактивно выбрать все настройки, либо запустить в пакетном режиме, указав необходимые настройки. Например:
# ./setup-full-8.3.22.1709-x86_64.run --mode unattended \
--enable-components server,ws,client_full
Установили компоненты: Сервер , модуль расширения веб сервера, толстый клиент.

4️⃣ Если раньше был скрипт запуска в /etc/init.d/srv1cv83, удаляем его. Вместо него устанавливаем юнит systemd:
# systemctl link /opt/1cv8/x86_64/8.3.22.1709/srv1cv8-8.3.22.1709@.service
Добавляем в автозагрузку и запускаем:
# systemctl enable srv1cv8-8.3.22.1709@.service
# systemctl start srv1cv8-8.3.22.1709@.default
Обращаю внимание, что команда на запуск изменилась. Нужно добавлять имя экземпляра сервера. По умолчанию - default. Так сделано для того, чтобы было удобно запускать несколько разных экземпляров сервера с разными настройками на одном хосте, повесив их на разные порты.

5️⃣ Напомню, что управлять кластером можно с помощью бесплатной панели управления ПУСК. Если у вас оснастки администрирования установлены на Windows машине, не забудьте там обновить платформу и зарегистрировать утилиту администрирования новой версии, иначе не получится подключиться к обновлённому серверу. Я частенько забываю это сделать.

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

#1с
​​Хочу поделиться информацией по поводу публикации баз по HTTP. Регулярно получаю вопросы по этой теме, очень актуальная. Да и статьи писал не раз по этому поводу. У меня есть довольно большой практический опыт настройки и поддержки работы таких баз.

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

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

Ограничения это ладно, с ними можно разобраться, так как они известны. Но, к сожалению, через браузер иногда возникают проблемы с работой основного функционала. Это бывает не часто, но бывает. Я сталкивался не раз и не два. Например, обновляется Chrome и какой-то запрос при работе с базой начинает зацикливаться и блокироваться браузером. При этом в том же Firefox продолжает нормально работать. В следующем обновлении платформы или конфигурации это может быть исправлено, а может и нет. Также сталкивался с тем, что какие-то то ли формы, то ли отчёты или другой функционал не открывался через браузер. Ошибка появлялась тоже после очередного обновления. Решения тупо нет, надо сидеть и ждать, либо откатываться назад. Ситуация очень неприятная.

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

💡 При всех этих минусах, публикация в веб решает другую важную задачу - доступ к базе без настройки доступа к самой инфраструктуре. Не нужны ни VPN, ни терминальный доступ, ни пробросы портов. Достаточно опубликовать базу в веб, закрыть её дополнительным паролем на уровне веб сервера и безопасно предоставить доступ внешним клиентам. Кого-то может и устроит работа в браузере, если он выполняет очень простые операции. Всем остальным можно поставить платформу и нормально работать, не забывая её обновлять вместе с сервером.

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

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

#1С
Я обновил и актуализировал популярную на сайте статью по настройке сервера :

Установка и настройка на Debian с PostgreSQL
https://serveradmin.ru/ustanovka-i-nastrojka-1s-na-debian-s-postgresql/

Статья подробная. Позволяет простым копированием и ставкой настроить указанную связку. В ней показаны:

Установка и настройка свежей версии сервера и PosgtreSQL 15 на Debian 11.
Пример создания баз данных на этом сервере и подключение к ним.
Бэкап и обслуживание postgresql баз утилитами сервера бд. Рассказываю про свой подход к этому процессу и привожу скрипты автоматизации. 
Как я тестирую восстановление из sql дампов и делаю контрольную проверку в виде выгрузки баз в .dt файлы в консоли Linux. Всё это автоматизируется скриптами. 
Рассказываю про свои подходы к мониторингу этих бэкапов и выгрузок, чтобы всегда быть уверенным в том, что у тебя есть гарантированно рабочие бэкапы.

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

#1с #postgresql
Недавно планово обновлял один из серверов в связке с PostgreSQL, работающий на Debian. Сервер настроен примерно так же, как описано в моей статье:
⇨ Установка и настройка на Debian с PostgreSQL
А обновление делал по этой статье:
⇨ Обновление Сервера под Linux

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

Выражалось это в том, что раза в 2-3 возросла нагрузка по CPU. В целом, всё работало, но очень медленно. Через панель администрирования было видно большое количество фоновых задач. При этом они не висели, но выполнялись явно медленно, поэтому их было в списке аномально много. Больше обычного в несколько раз.

Какое-то время разбирался в проблеме, пытаясь понять, с чем это связано. Полный дублёр этого сервера не имел таких проблем. В итоге заглянул в лог postgresql и заметил, что там куча сообщений об исчерпании лимита доступных подключений, хотя в обычное время их достаточно. Судя по всему по какой-то причине на боевом сервере зависли соединения.

Остановил сервер , перезапустил postgresql и запустил заново сервер. Работа нормализовалась. Контроль соединений к базе данных — один из ключевых параметров, которые надо мониторить. Здесь это не было сделано. Пришло время настроить.

На что ещё обратить внимание при обновлении:
1️⃣ Периодически установщик ставит дополнительные пакеты. Например, в этот раз заметил, что он установил Apache. Мне он был не нужен, удалил.
2️⃣ Проверьте, что вы точно удалили из автозапуска службу со старой версией . Я в одном месте ошибся и удалил неправильно. Там немного отличаются команды. Например, остановка сервиса выполняется командой:
# systemctl stop srv1cv8-8.3.22.1709@.default
А удаление из автозапуска:
# systemctl disable srv1cv8-8.3.22.1709@.service
Окончания в названиях службы разные. Я в одном месте ошибся и после перезагрузки получил две запущенные службы сервера. Старая запустилась в качестве сервера, а новая версия валилась в ошибки постоянно. Самое удивительное, что заметили это только через 3 дня, так как платформа у клиентов автоматически использовала старую версию и никто не обратил на это внимание.

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

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

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

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

❗️ Важное дополнение, которое возможно сэкономит кому-то время. Сборка PostgreSQL 15 с патчами для от 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

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

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

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

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

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

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

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

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

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

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

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

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️⃣ Иду в консоль и добавляю восстановленную базу base1C-restored.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

#1С