В общем, планируется перевести пользователей на клиент-серверную версию (доступ по РДП, филиалы из разных городов) 1С. Выбираем между Postgre и MS SQL. Появились вопросы, которые никак не могу нагуглить уверенно.
Во первых - порядок лицензирования сервера. То есть в прайсе 1С есть такая вещь как "1С:Предприятие 8.3 ПРОФ. Лицензия на сервер", надо объяснить клиенту, зачем оно нужно.
Ну и порядок лицензирования MS SQL, если его выберем (postgre как я понял бесплатен, просто нуждается в грамотном админе).
Есть статья на хабре или еще что-нибудь?

(51) Это же победили.

(52) УТ (аналог вашей 11.3 или 11.4) и БК 3.0 (аналог вашей БП 3.0)
Смысл зарождения сервера именно в появлении филиалов в других городах. Пользователей то не очень много, просто раз решили делать сервак, то лучше сразу потратиться на нормальный, чтобы потом не перенастраивать. Условно - 10-15 сейчас, ожидается до 30 пользователей. Возможно часть будет работать через web, часть через РДП.

(55) понятно.

Мой совет такой. Если жестких, каких-то сумасбродных и радикальных допилов никто не успел на базы навернуть, то с точки зрения работы платформы разницы, скорей всего, не заметите. Хоть один, хоть другой вариант на этом режиме нагрузки не доберутся до критичных состояний. Однако...!

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

(54)Еще не все об этом знают.

(27) + 100!

Там вроде не так много параметров. Можно отправную точку настроек postgresql.conf взять отсюда: https://pgtune.leopard.in.ua

(59) В сборках от постгреспро https://1c.postgres.ru/ при установке конфиг подгоняется под железо.

(60) Хорошо, если так. Интересно, настройки они так же из pgtune берут, или какой-то свой алгоритм реализовали?

(61) Ну поставь да сравни конфиги.

(62) угу, как будет нечем заняться, сразу сделаю

Ни разу не видел ПГ у которого попугаев больше 28 по тесту Гилева

Вот на компе для разработки 16 Gb, 4 ядра, SSD

autovacuum_max_workers = 6
autovacuum_naptime = 20s
autovacuum_vacuum_cost_limit = 400
bgwriter_delay = 20ms
bgwriter_lru_maxpages = 400
bgwriter_lru_multiplier = 4.0
checkpoint_completion_target = 0.9
datestyle = 'iso, dmy'
default_text_search_config = 'pg_catalog.russian'
dynamic_shared_memory_type = windows
effective_cache_size = 8GB
escape_string_warning = off
lc_messages = 'Russian_Russia.1251'
lc_messages = 'en_EN.utf-8'
lc_monetary = 'Russian_Russia.1251'
lc_numeric = 'Russian_Russia.1251'
lc_time = 'Russian_Russia.1251'
listen_addresses = '*'
log_destination = 'stderr'
log_file_mode = 0640
logging_collector = on
maintenance_work_mem = 128MB
max_connections = 500
max_locks_per_transaction = 256
max_wal_size = 1GB
min_wal_size = 80MB
online_analyze.enable = on
online_analyze.local_tracking = 'on'
online_analyze.table_type = 'temporary'
online_analyze.verbose = 'off'
plantuner.fix_empty_table = 'on'  
port = 5432
random_page_cost = 1.5
shared_buffers = 768MB
shared_preload_libraries = 'online_analyze, plantuner'
standard_conforming_strings = off
synchronous_commit = off
temp_buffers = 32MB
work_mem = 128MB


(64) за бесплатно? 28? еще и не глючит на ровном месте? дайте две!

(64) Делали стенды

(0) Переход с Микрософта на Линукс, ценник будет интереснее, работы под ключ

(64) а кому они нужны эти попугаи?
Тест гилева - это тест однопоточной записи большого количества маленьких объектов. Все.

(65) Ну настройки явно не одинаковые, pgtune такие предлагает:
linux:
max_connections = 500
shared_buffers = 4GB
effective_cache_size = 12GB
maintenance_work_mem = 2GB
checkpoint_completion_target = 0.9
wal_buffers = 16MB
default_statistics_target = 500
random_page_cost = 1.1
effective_io_concurrency = 200
work_mem = 2097kB
min_wal_size = 4GB
max_wal_size = 16GB
max_worker_processes = 4
max_parallel_workers_per_gather = 2
max_parallel_workers = 4
max_parallel_maintenance_workers = 2


win:
max_connections = 500
shared_buffers = 512MB
effective_cache_size = 12GB
maintenance_work_mem = 1GB
checkpoint_completion_target = 0.9
wal_buffers = 16MB
default_statistics_target = 100
random_page_cost = 1.1
work_mem = 2708kB
min_wal_size = 1GB
max_wal_size = 4GB
max_worker_processes = 4
max_parallel_workers_per_gather = 2
max_parallel_workers = 4
max_parallel_maintenance_workers = 2

(51) В теме postgesql долго выполняет запрос срез последних описал как решить проблему "запрос срез последних"

(70) См. (32) Проблема не решается в принципе. Только если ставить enable_nestloop=off с потерей общей производительности.

(71) А ничего, что в актуальных релизах типовых _все_ выборки данных по _любым_ отдельно взятым регистрам и их производным спрятаны в виртуальные таблицы ?

(72) И? Любая виртуальная таблица 1с - это подзапрос в sql. Со всеми вытекающими из этого.

А что не так с PostgreSQL? Ставил в одной фирме 1с, еще на Centos 6.2, лет 9 назад. С тех пор только поднимаю релизы и протираю пыль с сервака. Полет нормальный (УНФ + БП + ЗУП, около 20 пользователей). Еще в одной фирме уже на Centos 7 PostgreSQL на хосте + виндовый терминальный сервер в виртуалке KVM - лет 6 уже работает, никто не жалуется (БП + ЗУП, баз 25-30 крутится, пользователей раньше было около 20, сейчас 3 осталось - фирма подыхает.). Ну и еще кучка примеров... Postgres нужно один раз хорошо настроить и все ...

Типовые давно пишутся исходя из того, что будут крутиться га постгри. Насчёт дорогого админа - фигня полная. По настройкам - в 90% случаев достаточно рекомендаций от 1С. На линуксе постгри конечно эффективнее чем на окнах, делали тесты разные челы получалось что разница примерно в 1,3-1,4 раза. Постгри - версионник, мс-скл - страничник и всё этим сказано, страничник меньше накладывает блокировок, но требует несколько больше ресурсов проца, с другой стороны не такой требовательный к памяти. Ставил и немного тюнил настройки постгри для Док.корп, пиковая нагрузка порядка 1100 сеансов.... на окнах, т.к. ставить на сервер линукс админы отказались... всё норм работает.
Насчёт выбора - ставь то, с чем готов работать.

(71) Решается только на PostgreSQL 12 версии от PostgrePro, так как они пофиксили баг когда после vaccum слетал план выбора правильного индекса
а проблема в том что у регистров сведений есть 2 индекса которые весят одинаково а порядок колонок разный из за этого выбирается не оптимальный индекс

проблему обсуждали еще в прошлом году тут https://t.me/PostgreSQL_1C_Linux/38861

(75) "Типовые давно пишутся исходя из того, что будут крутиться га постгри. "
Адаптация к постгре - отказ от подзапросов к виртуальным таблицам. И было бы неплохо, чтобы проблема была решена платформой 1с раз и навсегда. Чтобы генератор sql-запросов из запросов 1с перестраивал подзапросы на временные таблицы, если используется постгрес.

(76) Это не та проблема. Речь не о выборе плохого индекса при соединении, а в выборе метода соединения. Постгрес не может правильно оценить количество выдаваемых подзапросом строк во время компиляции запроса в целом. И применяет nested loop, который хорош только на мелких присоединяемых таблицах.

(78) Ну и как этот метод влияет на базы в 30-50 пользователей?

(79) речь про время выполнения запросов (больше зависит от размера таблиц, загруженности сервера СУБД, чем от кол-ва пользователей)

(80) А загруженность сервера от чего зависит? или размеры таблиц?

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

Что то не адекватного выбора ни одного. Буду первым.

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

Для типовых наиболее массовый режим совместимости с платформой 8.3.14 , а конфигах ДО и ДО-КОРП и даже еще выше, но я давненько в них не заглядывал. Не хватает времени просто еще и на них.

(79) И конечно так, всё правильно пишешь - на внедрениях в пределах средних 30-50 (причем, именно в одной базе) эта вся проблема никоим образом не может и не способна себя проявить.

(84) Гарантируете, что проблема решена платформой? Или всё-таки костылями, в виде адаптации всех запросов, включая запросы СКД и RLS, под использование явных временных таблиц?
(79) Даже при 1 пользователе тормозит. С нестедлупами расчет зарплаты жарит процессор сервера почём зря несколько минут, без него - пара секунд.

(86) т.е. я это воспринимаю как просто наброс со словами "жарит процессор" - и что? надо всем тут возбудиться и побежать проверять - жарит или не жарит - когда вся эта пое...нь годами уже на практике внедрений работает и никого никак не жарит и никуда не жарит, а только лишь в представлениях некоего анонимуса на мисте в каком-то месте его же одного и жарит.

А вообще, годный наброс. Холиваристый.

Еще и с голосовалкой теперь... Но я думаю, что тема стухнет. Это вам не УА и не РБ

(88) конечно сдохнет ибо не первый десяток раз всплывает

(88) Для кого-то наброс, для кого-то реальная ситуация) У меня опыта такого еще не было, так что читаю все мнения)

У постгре есть огромный минус: если бесперебойника нет и свет часто мигает, все базы падают несколько раз в год. Интересно, а у МС есть такие проблемы?
Это не стёб, а удивление от личного опыта. Я не знал, что базы СУБД так легко валятся. Мне казалось, что у них там многократное наслоение надёжности.

(91) У кого есть деньги на МС - на бесперебойник найдут ))

(91) Вот просто нет у нас в наличии ни одной базы на МС СКЛ и что-то ни разу не могу припомнить именно такой проблемы.
Бесперебойники имеются в обязательном порядке и даже не из-за того, что капризничает конкретно 1С - там и без 1С хватает критичного к падениям ПО.

(91) у МС тоже проблемы с этим случаются

(94) И да, насчет проблем, просто в качестве примера ссылка в этой ветке была. На соседнюю и обсуждаемую прямо в эти дни :-)

(91) Бесперебойник - маст хэв же. И проверка работоспособности раз в квартал

Контроллер RAID с батарейкой и обычными SAS 15К дисками, а также SSD с защитой данных от потери питания, просто подключенныe к SATA на матплате, сохранили все данные до последнего байта, в этом году пришлось столкнуться.
PostgreSQL просто сказал "Подождите, я сейчас сделаю рекавери".
Да - за батарейкой надо следить, а серверный SSD стоит в несколько раз дороже домашнего..

Тоже адекватный выбор )

(87) Да нет, это факт известный, зря вы его отрицаете. Я пробовал с постгресом лет 5 назад поднять ЗУП. Было что-то с чем-то. Какие-то действия могли выполняться долго, с 100% загрузкой процессора процессом постгреса. Недаром даже сама 1с рекомендовала отключать нестлуп в настройках.
https://its.1c.ru/db/metod8dev/content/4692/hdoc

(91) Кластер нужно создавать с переменной --data-checksums, сборки от 1С это не делают

(99) За 5 лет много изменилось в PostgreSQL, хорошие улучшения пошли с 11 версии

(99) Главное все-таки по больше верить и все получится. Вот пример с другой ветки.
---
Ботаник Гарден Меран RU/Москва
27 - 18.11.20 - 10:38
« х     
Сейчас во всех конфигурациях универсализация и обфускация алгоритмов.
БП, например.
При смене договора в документе дошел до строк:

Если ВладельцыБезСообщений[ИндексВладельца] = Неопределено Тогда
    // Получаем сообщения от владельца
    ВходящееСообщение = ВсеСообщения[ИндексВладельца];

Чувствуется, пора (на пенсию - увы рано еще) в тестировщики или в питон куда-нибудь.    28
29
ø    bolder RU/Москва
28 - 18.11.20 - 10:46
« х     
(27) там НЕ забыли)
ø    Lama12 RU/Москва
29 - 18.11.20 - 10:51
« х     
(27) Это универсализация. Да, другое мышление, но зато так здорово! :-)    30
ø    Ботаник Гарден Меран RU/Москва
30 - 18.11.20 - 10:56
« х     
(29)
Я вот тоже думал, ну чему там в БП тормозить.
Вот оно во всей красе: сначала собираются все настройки, под них все данные, и где-то на седьмом-восьмом уровне вложенности процедур по фильтрам получается значение нужной настройки.

В сервисе ошибок при поиске по слову "postgresql" находится немало "существенного замедления работы", как в конфигурациях, так и в платформе.
Из-за этого тормозила зарплата - https://bugboard.v8.1c.ru/error/000002673 приходилось держать ее на 8.2, до того как исправили. Сейчас на подобное реагируют гораздо быстрее, в том числе и на ошибки с СУБД.

(103) Это, мне кажется, из-за 1cfresh. Тут 1С для себя суетится.

Конфигурации под управляемые приложения работают в PostgrSQL достаточно шустро. Проблемы только в разработчиках 1с, которые набили себе руку на кривых отчетах и перепиливать за ними нет никакого желания. Но проблема из-за этого остается даже на высоко-производительных серверах с MSSQL на борту. Попытка уменьшения стоимости запроса в MSSQL приводит к ступору 1с, MSSQL кричит, что ему не хватает показателя 100500 в регуляторе запросов. И особенно этим грешат базы в которых нужно посчитать каждую алкогольную марку. Ощущение такое, что скоро на каждую булку будут требовать акцизную марку, чтобы жизнь медом не казалась.

В общем качественно пилить нужно все конфы, чтобы работа не встала колом.

(104) Да, тем более, что у них есть и федеральный проект на том же фреш https://www.cnews.ru/news/top/2018-12-06_informsistema_kaznachejstva_i_minfina_sekonomit

(100) >> Кластер нужно создавать с переменной --data-checksums, сборки от 1С это не делают
Там даже такое есть?

Я ПГ для дома поставил, поэтому и с бесперебойником перебои. Наверное надо переставлять боевую часть на N-ку и колдовать с обратной связью от ИБП. J-ка 61 минуту держалась на батарейке 7х12, больше не пробовал. Но вдруг свет отрубят на много часов, а я не дома.

"--data-checksums
Применять контрольные суммы на страницах данных для выявления сбоев при вводе/выводе, которые иначе останутся незамеченными. Расчёт контрольных сумм может повлечь заметное снижение производительности. Когда контрольные суммы включены, они рассчитываются для всех объектов и во всех базах данных" - из документации.
Надо будет попробовать.

(108) Определил сервер, что страница с данными битая, а что дальше? Отвал базы в suspect (или как там оно у постгреса)? Это же не избыточное отказоустойчивое кодирование, а всего лишь контрольная сумма..

А как избыточность сделать?

(82) Мне лень развивать, но смысл диалога сведется к конечному,

среднему пользователю в вакууме и количество сервисов интегрированных на среднего пользователя в вакууме, и далее мы увидим, что в 80% оценка по среднему пользователю в вакууме будет верна, и понятна, за исключением 20% когда требуется уточнить есть ли наличие спец задач

(110) для постгри избыточность это онлайн-бэкап

(109) Один из основных разработчиков СУБД считает, что " I think this feature is: being able to very quickly and
easily know that a problem originated outside of the PostgreSQL code" - https://postgrespro.ru/list/thread-id/2486488
Ну, а дальше остановить СУБД, заменить диск(и) и восстановить кластер из непрерывного архива WAL, наверное. Так сказать, PITR, на любую секунду до возникновения ошибок. Они там все убеждены, что эта штука должна быть обязательно включена.
Насколько, при этом, будет замедляться, надо смотреть.

(113) замедления минимальны. Я тоже убежден, что PITR должн быть включен и настроен на всех инсталяциях Postgres. Не потому что постргес может упасть, а потому что это мега-крутая фишка. И нашу контору пару раз она спасала от огромных проблем.

Я на SQL тестировал
None
TornPage
Checksum
так и не увидел разницы.

Но я тестировал из 1С, все упиралось, как всегда в ядро сервера 1С, надо бы попробовать из чистого SQL, хотя, зачем, если узкое горло в 1С :-)

(114) Согласен, что фича нужная, и следовало бы её по умолчанию включать.

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

(117) ну так в соседней же ветке буквально свежий пример новосстановимого архива из мс-скл :-)

(117) Я, раз в квартал, тестирую возможность восстановления БД. И из pg_dump и из pg_basebackup-a + накатка транзакций. Есть админы которые неделают бекапы, есть админы которые делают, а есть те которые их регулярно тестируют)

(118) а что за ветка?

(120) Восстановление работоспособности ИБ после поломки

(99) "Я пробовал с постгресом лет 5 назад поднять ЗУП" - а более свежего опыта нет? А то за 5 лет многое могло измениться как в ядре 1С-ины, так и в СУБД.
В частности 16.02.2019 пресс-релиз: "Оптимизирована работа виртуальных таблиц оборотов регистров накопления и бухгалтерии в случае использования группировок по дню, месяцу или году, а также при использовании функции языка запросов НачалоПериода(). Оптимизация используется для любых версий поддерживаемых СУБД, кроме Microsoft SQL Server, где оптимизация действует, начиная с версии 2012."

(121) Там админ/адинэсник не делает бекапы перед обновлением. Да и вины SQL сервера нет, что-нибудь в этом духе словили бы и на постгресе. Так что неканает.

(123) очень даже канает.

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

(124) Бекап там восстановимый, просто вчерашний. Падения самого SQL-сервера не было. Для SQL все штатно, как настроили так и работает. Вот если бы там после ребута все базы легли бы, тогда канало бы.

(125) Да даже если было, бекап на то и бекап, что с него нужно уметь восстанавливаться, а не делать круглые глаза- не получилось

(126) Лет пять назад, помнится, нужно было плясать с бубном, чтобы поднять бэкап базы 1с в постгресе. Там на какие-то определяемые типы mvarchar ругалось, если загружать бэкап в пустую базу. Приходилось заново создавать базу из управления сервером 1с, и только потом можно было загрузиться. Костыльно. Сейчас иначе?

А сейчас с точностью до наоборот: Приходится сначала из консоли postgres создать пустую db (create database) и в нее уже загружать. При этом оно точно также ругается.

Костыль? Да! Работает? Да.

Если бекапить pg_basebackup и архивировать журнал транзакций - все работает штатно, как в доке написано. Но для всех баз в кластере.

(127) У каждого восстановления есть необходимость проверить работоспособность, по поводу специфики, спрошу конечно, но судя по тому, что мы уже восстанавливались и это проблем никаких не заняло, просто уведомили о простое в пару часов, то думаю что, или решено, или как написал Стопа, нюансы, но никак не проблемы

(128) ИМХО. Постгрес это не то, чтобы установить и спать спокойно. По крайней мере для 1с. По крайней мере для небольших контор.
По моему мнению, постгрес удачное решение для барыг-облачников, которые предоставляют 1с как сервис. Это здорово позволяет сэкономить, но лишь при наличии квалифицированных админов, которые на этом постгресе много собак съели. Это не та СУБД, которая "просто работает".

(130) Все то же самое, или сразу настроят бекапы и прочие восстановлялки, или будут париться при восстановлении

(131) Просто есть СУБД, которые более дружественны к админу. Та же mssql мощная СУБД, с кучей возможностей - но бэкап сделать и восстановить сможет любой школьник с базовыми навыками. А настройки по умолчанию работают быстро и не вызывают особых проблем.
Или вот например firebird - легкая, простая, админить как два файла переслать. К сожалению, 1с её не поддерживает.

(132) Ну при условии что мы берем за обслуживании связки Никсов+ ПГ от 10к в месяц, это не сильно повлияет на любой бюджет

я, наверное, что-то не понимаю в обсуждении создания / восстановления архивов на пг, но вот эта схема пока сбоев не давала:

Сохраняем:
pg_dump -Fc --clean somebase > /opt/backup/1cv82/somebase.out

Восстанавливаем
dropdb newbase
createdb newbase

pg_restore -d newbase /opt/backup/1cv82/somebase.out

Вполне дружественно, я считаю.

Или сейчас модно как-то по-другому делать архивацию на пг?

(117) ну если взять чужой скрипт и не проверять...
И да, есть такой момент: если ты делаешь рестракт и в это время делается бэкап с очень высокой вероятностью выкинь бэкап а dev/null

(122) именно по ЗУПу есть особенности желательные (более агрессивный автовакуум, например)...

(129) справедливости ради: если ты не админ, а одинэсник для тебя ньюанс может стать проблемой... пока не найдёшь решение

(134) или так под окна:
pg_dump.exe"  -i -b -v -E UTF-8 -f C:\PG_Backup\Dump\dump_erp.sql

createdb
psql.exe -f C:\copying\dump_erp.sql >restore.log

Короче, слоны не летают

(139) ещё как! Только не забываем обслуживать БД

(139) (140) Слоны - птицы гордые...
Не пнёшь - не полетят...

Короче, если забить болт на обслуживание базы, то она протухнет в любой версии

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

относится к любой версии баз и вообще к любому ПО

(143) Ну всё-таки постгрес это не "любое ПО", а весьма специфичное и в экосистеме 1с чужеродное. Даже сами разработчики постгреса скептически относятся к тому, что его выбрали для 1с. Где-то читал, что они заявляли, что характерные для 1с нагрузки и структура хранения данных плохо укладываются на постгрес..

(144) А что такого экстремального в 1с, что сервер базы данных (реляционной) не может её вытянуть?

(145) Там говорилось про количество таблиц в базе и характерные запросы с подзапросами.

(146) Хм... То есть разработчики признали, что они сделали какашку и потом упорно заворачивают её в красивую бумажку?

(147) Разработчики, кстати, упорно рекомендуют использовать постгрес на линуксе, а не на винде. Потому что линукс лучше работает с десятками тысяч файлов в одном каталоге.

(148) ну вот чисто из вредности и дурного настроения в это сегодняшнее утро, спрошу с ехидцей :
а что у тебя и пруф имеется на разработчиков именно платформы (а не самописных конфигураций) и такие их рекомендации действительно имеются относительно 1С+постгри ?

(148) А вот мсу не надо "лучше работает с десятками тысяч файлов в одном каталоге."...

(149) Извини, пруфов нет, это на инфостарте одна бабка сказала) ну и смотрел видео от постгреспро, где они всячески распинались почему не ну никак не получилось сделать чтобы 1с не тормозила без переписывания запросов.

(142) но мс-сиквел дохнет прилично дольше

(148) нет, потому-что в линуксе другая работа с памятью и постгри под ней заточен