Установил Postgresql - с сайта Postgres pro под Windows- самая последняя 9.6 для 1с.
Выполнил рекомендации из ИТС и gilev.ru/postgres. Что на ИТС, что у Гилева встречаются настройки, которых нет в конфигурационном файле, например checkpont_segmens . Из рекомендаций Гилева мне не подошла настройка effective_io_concurrency - c подобной настройкой PG не стартует.
Сравниваю производительность баз данных под MS SQL и Postgresql , поэтому базы подняты с одного dt и выполняю одинаковые длительные обработки.
Вот что я заметил. Время выполнения на обоих СУБД почти одинаковое, MS SQL почти всегда быстрее , но не критично , примерно 10%, диски под MS SQL производительней, все файлы PG на одном диске, поэтому такая разница устраивает и понятна.
НО... при втором, третьем выполнении этой же обработки, время на MS SQL уменьшается очень сильно, а на PG - уменьшения - нет .Вообще.
Например , один тест - под MS SQL 10 мин- первый запуск, 7 минут - второй запуск. Под PG- все время 12 минут.(Времена округленные).
второй тест под MS SQL первый прогон- 37, второй- 31 минута. Под Postgresql . Самый первый прогон - 50 минут, после vacuum full verbose analyze и изменения конфигурационнойго файла- 35 минут и на этом все, следующие прогоны вокруг этой цифры, уменьшения нет.
Можно ли добиться использования кеша 1с настройками Postgresgl? Или это не кэш?
Конфигурационный файл приложен.
Выполнил рекомендации из ИТС и gilev.ru/postgres. Что на ИТС, что у Гилева встречаются настройки, которых нет в конфигурационном файле, например checkpont_segmens . Из рекомендаций Гилева мне не подошла настройка effective_io_concurrency - c подобной настройкой PG не стартует.
Сравниваю производительность баз данных под MS SQL и Postgresql , поэтому базы подняты с одного dt и выполняю одинаковые длительные обработки.
Вот что я заметил. Время выполнения на обоих СУБД почти одинаковое, MS SQL почти всегда быстрее , но не критично , примерно 10%, диски под MS SQL производительней, все файлы PG на одном диске, поэтому такая разница устраивает и понятна.
НО... при втором, третьем выполнении этой же обработки, время на MS SQL уменьшается очень сильно, а на PG - уменьшения - нет .Вообще.
Например , один тест - под MS SQL 10 мин- первый запуск, 7 минут - второй запуск. Под PG- все время 12 минут.(Времена округленные).
второй тест под MS SQL первый прогон- 37, второй- 31 минута. Под Postgresql . Самый первый прогон - 50 минут, после vacuum full verbose analyze и изменения конфигурационнойго файла- 35 минут и на этом все, следующие прогоны вокруг этой цифры, уменьшения нет.
Можно ли добиться использования кеша 1с настройками Postgresgl? Или это не кэш?
Конфигурационный файл приложен.
Прикрепленные файлы:
postgresql.conf
По теме из базы знаний
- Почему PostgreSQL не лучше MS SQL
- Наш опыт использования PostgreSQL cluster под управлением Patroni для 200 баз
- Мигрируем с MS SQL на PostgreSQL
- Инструкция по установке Postgres для OLTP приложений и 1С. Часть 1. Базовая конфигурация
- Применение 1С:Аналитики и Дата акселератора, или Как получить в 1С прозрачность и скорость обработки данных для прямого доступа и контроля руководителя
Ответы
Подписаться на ответы
Инфостарт бот
Сортировка:
Древо развёрнутое
Свернуть все
(1) Субъективно MSSQL всегда будет быстрее
конфа на управляемых блокировках? Режим совместимости какой?
из стандартных настроек выкрутить
default_statistics_target = 5000
join_collapse_limit=1
seq_page_cost = 0.1
random_page_cost = 0.4
cpu_operator_cost = 0.00025
Первая настройка как раз отвечает за количество записей, участвующих в сборе статистики, остальные для планировщика запросов
конфа на управляемых блокировках? Режим совместимости какой?
из стандартных настроек выкрутить
default_statistics_target = 5000
join_collapse_limit=1
seq_page_cost = 0.1
random_page_cost = 0.4
cpu_operator_cost = 0.00025
Первая настройка как раз отвечает за количество записей, участвующих в сборе статистики, остальные для планировщика запросов
Ссылки посмотрю, за них спасибо.
то, что Postgres не знает про 1с- я думаю как раз наоборот- специально написаны добавки к ядру Postgres для работы с 1с , они вроде тоже называются расширения
то, что Postgres не знает про 1с- я думаю как раз наоборот- специально написаны добавки к ядру Postgres для работы с 1с , они вроде тоже называются расширения
(7) Вчера посмотрел Ваше/твое выступление на конференции PG. Понравилось.
Я никаких регламентных операций на Postgresql не делаю. Я его развернул для теста и подготовки к эксперту по технологическим вопросам :(
Антон, можете написать, использует ли Postgresql кэш 1с?
Какие изменения произошли за год в паре Postgresql - 1с Postgresql после этого выступления? Можете написать кратко, ничего или стало лучше :)
Я никаких регламентных операций на Postgresql не делаю. Я его развернул для теста и подготовки к эксперту по технологическим вопросам :(
Антон, можете написать, использует ли Postgresql кэш 1с?
Какие изменения произошли за год в паре Postgresql - 1с Postgresql после этого выступления? Можете написать кратко, ничего или стало лучше :)
(9)
Виктор, кэш 1С и любой движок БД вообще никак не взаимосвязаны и соответсвенно экш 1С не используется ни одном движком БД.
По поводу того что изменилось за год: Изменения в лучшую сторону, особенно в платформе 1С, она стала более дружественной по отношению к PostgreSQL, а так же в БСП многие запросы переписаны для более корректной работы как в PostgreSQL так и MS SQL.
Сам PostgreSQL тоже поменялся, версия 9.6.6 стала ощутимо быстрее, скорость уже как минимум сравнима с MS SQL в реалиях 1С, особенно радует скорость работы под Windows на ReFS
Версию 10 от PostgreSQL пока ещё кручу, тестирую, пока сказать о каких-то результатах не могу.
произошли за год в паре Postgresql - 1с Postgresql
Виктор, кэш 1С и любой движок БД вообще никак не взаимосвязаны и соответсвенно экш 1С не используется ни одном движком БД.
По поводу того что изменилось за год: Изменения в лучшую сторону, особенно в платформе 1С, она стала более дружественной по отношению к PostgreSQL, а так же в БСП многие запросы переписаны для более корректной работы как в PostgreSQL так и MS SQL.
Сам PostgreSQL тоже поменялся, версия 9.6.6 стала ощутимо быстрее, скорость уже как минимум сравнима с MS SQL в реалиях 1С, особенно радует скорость работы под Windows на ReFS
Версию 10 от PostgreSQL пока ещё кручу, тестирую, пока сказать о каких-то результатах не могу.
(12)
А база (в клиент-серверном варианте) - это набор таблиц, создаваемых средствами движка СУБД. И этот движок понятия не имеет о том, где и какие файлы созданы без его участия, да и не интересуется ими.
Соответственно, использовать "кэш 1С" он никак не может, его использует только сама создавшая его 1С по обычному для любого кэширования принципу: когда требуемые данные есть в кэше, то обращение идет к кэшу, а не к базе.
А в PG такого кэширования нету, просто нету: каждый запрос выполняется как в первый раз.
Пусть это не кэш 1с.
Это точно не кэш 1С: кэш 1С - это всегда файлы, создаваемые самой 1С в папке пользователя.
А база (в клиент-серверном варианте) - это набор таблиц, создаваемых средствами движка СУБД. И этот движок понятия не имеет о том, где и какие файлы созданы без его участия, да и не интересуется ими.
Соответственно, использовать "кэш 1С" он никак не может, его использует только сама создавшая его 1С по обычному для любого кэширования принципу: когда требуемые данные есть в кэше, то обращение идет к кэшу, а не к базе.
Но, снижение времени выполнения операции на MS SQL есть, на Postgres нет.
Значит, в MS SQL есть собственное кэширование по принципу, описанному выше: результаты запроса запоминаются и при возможности используются повторно.
А в PG такого кэширования нету, просто нету: каждый запрос выполняется как в первый раз.
(14)(15) в MS SQL есть процедурный кэш, в котором хранятся планы выполнения запросов и при втором , третьем .. выполнении план берется оттуда, а не компилируется с нуля
вспомните команду DBCC freeproccashe и дебаты надо ли выполнять очистку после обновления статистики
я так понимаю подобного процедурного кэша в PostgreSQL нет?
вспомните команду DBCC freeproccashe и дебаты надо ли выполнять очистку после обновления статистики
я так понимаю подобного процедурного кэша в PostgreSQL нет?
(19) Посмотрел. Никаких PREPARE там не нашел(может, плохо искал...).
Зато нашел такое:
"Модуль aqo представляет собой расширение Postgres Pro Enterprise для оптимизации запросов по стоимости выполнения. Используя методы машинного обучения, а точнее модификацию алгоритма k-NN, aqo улучшает оценку количества строк, что может способствовать выбору лучшего плана и, как следствие, ускорению запросов.
Модуль aqo может собирать статистику по всем выполняемым запросам, за исключением запросов, обращающихся к системным отношениям. Если запросы различаются только константами, они считаются относящимися к одному типу. Для каждого типа модуль aqo сохраняет для машинного обучения качество оценки количества строк, время планирования, время и статистику выполнения. На основе этих данных aqo строит новый план выполнения и использует его для следующего запроса того же типа. В тестах aqo показал значительное увеличение производительности для сложных запросов."
Как говорится, "Покупайте наших слонов".
Зато нашел такое:
"Модуль aqo представляет собой расширение Postgres Pro Enterprise для оптимизации запросов по стоимости выполнения. Используя методы машинного обучения, а точнее модификацию алгоритма k-NN, aqo улучшает оценку количества строк, что может способствовать выбору лучшего плана и, как следствие, ускорению запросов.
Модуль aqo может собирать статистику по всем выполняемым запросам, за исключением запросов, обращающихся к системным отношениям. Если запросы различаются только константами, они считаются относящимися к одному типу. Для каждого типа модуль aqo сохраняет для машинного обучения качество оценки количества строк, время планирования, время и статистику выполнения. На основе этих данных aqo строит новый план выполнения и использует его для следующего запроса того же типа. В тестах aqo показал значительное увеличение производительности для сложных запросов."
Как говорится, "Покупайте наших слонов".
Сравните объем "съедаемой" памяти MS и Postgres - вероятно увидите, что MS берет в разы больше... это и есть внутренние кэширование, которое влияет на скорость.
Кеш - это область памяти, используемая для хранения часто используемых данных. Кеш может быть дисковый, процессорный, кеш может быть у приложения для каких-то часто используемых данных (например, 1С кеширует объект метаданных на 20 секунд примерно, поэтому второе обращение к объекту происходит мгновенно, тогда как первое заставляет движок ORM читать данные из СУБД, при том этот кеш никак не зависит от СУБД).
У СУБД тоже есть кеш - область памяти, используемая для хранения результатов выборки из таблиц. По-умолчанию MS SQL использует ВСЮ память, какая есть на компьютере (при установке параметр используемой памяти равен двум лярдам мегабайт, т.е. 2^30), а у постгри все буфера ограничены десятками мегабайт всего. Для того, чтобы заставить постгри кушать больше памяти, нужно прописать в конфиги соответствующие значения буферов, которые можно посмотреть, например, .
Т.к. разрабатываемые 1С типовые решения отработаны в большинстве случаев именно на клиент-серверных платформах, использующих в качестве СУБД MS SQL, то вряд ли можно было бы надеяться на то, что постгри будет быстрее, но если заняться оптимизацией запросов именно для постгреса, то, как говорили всякие там Лустины (и, возможно, Гилевы), постгри в итоге получается быстрее в большем количестве случаев, и MS SQL догнать постгри по производительности уже не может (если крутить настройки в разных базах и для первого, и для второго).
Вообще, есть простой пример, показывающий отличие постгри и MS SQL - так называемые "пакетные условия" (кстати, может это как-то иначе называется?) в запросах. Т.е. когда у нас есть "ВЫБРАТЬ Х, У ИЗ Таб ГДЕ (Х, У) В (ВЫРАТЬ Х, У ИЗ Таб2)", то MS SQL, который с такой конструкцией работать не умеет, преобразует это во что-то типа EXISTS(SEL ECT X, Y FR OM Tab2 WHERE X=X' AND Y=Y'), в постгри же это нативный синтаксис, т.е. он просто так как в 1С и напишет (хотя, конечно, не совсем ясно, как 1С это преобразует - надо будет посмотреть).
Ну и, конечно, на производительность постгри будет влиять и ось тоже. На Linux производительность была выше, чем на MustDie.
У СУБД тоже есть кеш - область памяти, используемая для хранения результатов выборки из таблиц. По-умолчанию MS SQL использует ВСЮ память, какая есть на компьютере (при установке параметр используемой памяти равен двум лярдам мегабайт, т.е. 2^30), а у постгри все буфера ограничены десятками мегабайт всего. Для того, чтобы заставить постгри кушать больше памяти, нужно прописать в конфиги соответствующие значения буферов, которые можно посмотреть, например, .
Т.к. разрабатываемые 1С типовые решения отработаны в большинстве случаев именно на клиент-серверных платформах, использующих в качестве СУБД MS SQL, то вряд ли можно было бы надеяться на то, что постгри будет быстрее, но если заняться оптимизацией запросов именно для постгреса, то, как говорили всякие там Лустины (и, возможно, Гилевы), постгри в итоге получается быстрее в большем количестве случаев, и MS SQL догнать постгри по производительности уже не может (если крутить настройки в разных базах и для первого, и для второго).
Вообще, есть простой пример, показывающий отличие постгри и MS SQL - так называемые "пакетные условия" (кстати, может это как-то иначе называется?) в запросах. Т.е. когда у нас есть "ВЫБРАТЬ Х, У ИЗ Таб ГДЕ (Х, У) В (ВЫРАТЬ Х, У ИЗ Таб2)", то MS SQL, который с такой конструкцией работать не умеет, преобразует это во что-то типа EXISTS(SEL ECT X, Y FR OM Tab2 WHERE X=X' AND Y=Y'), в постгри же это нативный синтаксис, т.е. он просто так как в 1С и напишет (хотя, конечно, не совсем ясно, как 1С это преобразует - надо будет посмотреть).
Ну и, конечно, на производительность постгри будет влиять и ось тоже. На Linux производительность была выше, чем на MustDie.
Оказывается. все уже есть :)
Глава 6. Администрирование PostgreSQL при работе с «1С:Предприятием» ◦Основы
◦Расширения
◦Логирование
◦ Настройки PostgreSQL для работы с «1С:Предприятием» ◦Основные параметры postgresql.conf
◦Общие положения
◦Настройки сервера для PostgreSQL
◦Обозначения
◦Параметры производительности
◦Параметры для платформы «1С:Предприятие»
◦Online_analyse
◦Расследование проблем
◦Резервное копирование и восстановление ◦Дамп SQL
◦Физические бэкапы
◦Непрерывная архивация
◦Дополнительные источники информации
Глава 6. Администрирование PostgreSQL при работе с «1С:Предприятием» ◦Основы
◦Расширения
◦Логирование
◦ Настройки PostgreSQL для работы с «1С:Предприятием» ◦Основные параметры postgresql.conf
◦Общие положения
◦Настройки сервера для PostgreSQL
◦Обозначения
◦Параметры производительности
◦Параметры для платформы «1С:Предприятие»
◦Online_analyse
◦Расследование проблем
◦Резервное копирование и восстановление ◦Дамп SQL
◦Физические бэкапы
◦Непрерывная архивация
◦Дополнительные источники информации
Внимание! Тема сдана в архив
Для получения уведомлений об ответах подключите телеграм бот:
Инфостарт бот