Комментарии 24
Получается, имхо, что одна база - один инстанс.
Да, лучше использовать такой подход
Тогда было бы здорово, если бы Вы написали как расчитывать вышеуказанные настройки postgresql при наличии нескольких инстансов на одной машине.
А с воркерами вакуума? Они дисковую подсистему в состоянии гонки вообще не введут?
В open source проектах, где большие команды очень сложно сказать чей это проект. Разработчики из разных стран вносят свой вклад, входят в комитеты, участвуют в управлении. В этом случае можно полагать что проект ничей, он общий.
При этом я не знаю как дела обстоят с постгресом. Но по крайней мере, postgres pro входит в реестр российского ПО.
У open source проектов нет "прописки". По отношению к такому софту важно чтобы былы "отечественные" разработчики которые в состоянии эту разработку поддерживать. Вот разработчики готовые поддерживать PostgreSQL в России есть."Импортозамещение" ведь нужно не для того чтобы просто "не платить за буго", а главное чтобы быть независимыми от этого "забугра".
Ерунда всё это. Вы не упоминаете о таких запросах как расчёт себестоимости, закрытия месяца. В компаниях с большим количеством движений, номенклатуры на в усмерть затюнингованном погреce подобные операции могут выполняться сутками. На том же железе просто установленый MS SQL выполнит эти операции за 16 часов. Всё дело в параллелизме исполнения запросов. В MS SQL он работает по умолчанию, а в postgres SQL заставить выполняться на нескольких ядрах запрос из расчёта себестоимости мне так и не удалось. Представьте себе запрос выполняющий 40 с лишним часов на одном ядре сервера! В MS SQL этот запрос будет выполняться на всех доступных ядрах при настройках по умолчанию. Описание подобных ситуаций я неоднократно находил на разных ресурсах.
Программисты утверждают что стандартный код 1С по расчёту себестоимости они не меняли. Да и глупо лезть в столь сложную процедуру. Остаётся только купить MS SQL.
Представьте себе запрос выполняющий 40 с лишним часов на одном ядре сервера
max_worker_processes
max_parallel_workers
max_parallel_workers_per_gather
https://postgrespro.ru/docs/postgresql/14/runtime-config-resource#GUC-MAX-PARALLEL-WORKERS
ну и explain стоит смотреть (если это действительно один большой запрос)
max_worker_processes = 12
max_parallel_workers = 12
max_parallel_workers_per_gather = 6 (пробовал 0, без разницы)
Эксплейн смотрю сейчас.
рекомендую, кстати
https://explain.tensor.ru/
на хабре была серия статей от разработчика, если интересуетесь оптимизацией запросов, то может быть интересно.
правда, насколько это применимо это к 1с не скажу, пытаться оптимизировать генерируемые запросы — тот ещё квест, обычно проблема решается переписыванием кода.
Боюсь соврать, но, насколько я помню, Postgres Pro включает в себя патч который сильно ускоряет производительность временных таблиц, и фикса этого в "основном" Postgres нету.
Ах да. Всё же основной вопрос при миграции баз данных 1С на postgresql сегодня, как и 10 лет назад когда я впервые это делал, "почему всё так тормозит?"
Как видно из результатов, PostgreSQL проигрывает в работе с временными таблицами, однако показывает лучшую производительность при работе с объектами, что суммарно дает одинаковую производительность с 1С.
Нет, не видно. Видно невероятное различие во временных таблицах и по 10% в остальных пунктах. А при увеличении числа потоков различие во временных таблицах растет (!!!), а различие по остальным пунктам уменьшается. Как у вас одно уравновешивает другое?
Во время выгрузки база должна быть открыта в монопольном режиме.
…
НО! Эти ограничения можно обойти при помощи штатной консольной утилиты ibcmd
И лучше бы писать «нельзя», имхо. Можно нахватать грязного чтения и массу несогласованных данных (ведь сервер приложений управляет блокировками, если вы залезаете в СУБД в обход него — то читаете данные, не взирая на блокировки). Кто потом будет заниматься поиском такого среди миллионов объектов?
Убираем перевыделение памяти по умолчанию: в значении vm.overcommit_memory=0 происходит эвристический анализ для определения выделяемой процессу памяти. Это дополнительная трата ресурсов
нет, потребление ресурсов на этот эвристический анализ вы никак не заметите
а острая нехватка памяти и большая конкуренция запустит процесс OOM Killer, при этом вы получите сообщения: “Out of Memory: Killed process 12345 (postgres)”.
ровно то же самое будет и в предлагаемом вами варианте.
всё отличие overcommit_memory=0: вместо вас значением overcommit_ratio управляют разработчики ядра.
чудес не бывает, не хотите видеть падения приложений по недостатку памяти — выделяйте достаточно оперативной памяти/свопа и всё.
Стоит разносить WAL и файлы базы на отдельные дисковые группы, если они на SSD?
рекомендации о разнесении времён hdd; для ssd никакого смысла в таком разнесении нет.
Тут стараемся не полностью от OOM Killera избавится, а снизить вероятность, что он "убъёт" наш процесс PostgreSQL.
Чудес действительно не бывает: реалии таковы, что на одной машинке с постгресом ради экономии может крутиться много постороннего ПО - какой-нибудь pgadmin4, да и у 1C:предприятия есть своя версия для linux.
По SSD:
Во-первых: 2TB SSD в 3х экзеплярах для самого простого кластера patroni с потоковой репликацией - иногда выходит дороговато. HDD, увы, пока ещё производятся и дёшевы.
Во-вторых: это касается только крайне высоконагруженных систем или крайне неоптимизированных запросов. Но всё же, упереться в конкуренцию на запись или пропускные возможности контроллера - возможно.
Естественно, если база на пару гигабайт, к ней подключаются 5 с половиной пользователей и всё это при хорошем железе, то никакой тюниг особо не нужен.
Частые вопросы по миграции базы данных 1С с MS SQL на PostgreSQL