Приветствую!

Коллеги, есть у моего заказчика проблема, которую подрядчики, занимающиеся 1С, пытаются решить "в лоб". Но, возможно, есть какие-то ещё варианты?

Дано:
Терминальный сервер на винде с толстыми клиентами
Linux c сервером 1С 8.3.13.1644 и postgresql 10.7.1 от postgres pro
Конфигурация КА2 2.4.8.84

В целом всё работает нормально, но у бухгалтера какие-то безумные проблемы. Проведение одного регламентного документа может занимать несколько минут (от 3 до 8!!!). Я не 1сник, я занимаюсь основной инфраструктурой, но так как спецы ничего сказать не могут, приходится пытаться решить проблему самостоятельно. Все возможные оптимизации уже сделаны, конфиг постгреса я изнасиловал уже всеми знакомыми и незнакомыми способами. Памяти навалом - раз в 5 больше, чем размер базы. В момент зависаний видно, что одно ядро полностью загружено процессом postgres, pg_top тоже показывает, что висит на UPDATE'ах и INSERT'ах (в основном на UPDATE).

Я грешил на скорость работы дисковой подсистемы, но на машине с точно такими же характеристиками (даже слабее - меньше памяти) на MS SQL всё работает вполне себе нормально. То, что характеристики одинаковы - 100%, это виртуальные машины, одна останавливается, другая запускается, хранилище образов дисков одно. Но MS SQL - это куча денег, которые клиент платить не хочет, а я не готов участвовать в использовании нелегального ПО. Да и вообще, что это за решение проблемы - потратьте кучу денег?

С заказчиком расставаться не хочется. Поэтому хочется решить проблему адекватным способом. Я знаю, что 1С:Fresh использует postgres, что Кнопка использует postgres, давно и успешно.

В какую стороную мне копать, подскажите, пожалуйста?

от 3 до 8 что много?

(1) На 1 (один) документ - очень.

(2) А позвольте узнать,что за документ?

(3) Расчет себестоимости)

(3) Бухгалтер говорит, что при любых регламентных: отражение Дт/Кт, операции вручную и т.д.

Вот пример, когда прислали скрин - прошло 4 минуты после нажатия даже не на Провести, а на Сохранить: https://habrastorage.org/webt/z1/d1/yk/z1d1ykrwmz4ljtychpgm0zpjejy.jpeg

да любой регламентный при закрытии месяца, вероятно

(5) А когда проблема возникла?

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

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

8.3.13.1644    28.11.18 - как бы не самый свежий релиз платформы, а потому интересна причина выбора именно этого релиза.

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

Сдается мне что криво настроен Постгресс

(8) а как могут влиять кривые руки буха на то, что постгрес чем-то там занят своим это время? я же отслеживал это в реальном времени, смотрел и общую загрузку, и pg_top.

Или ввод остатков или рлс или конф.файлы кривые.

(13) Замер производительности нужен,я так начинаю смотреть,не знаю как другие делают

(11) просто элементарное получение проводок и расчет себестоимости ( как в (4) вспомнили ) должны были раньше спровоцировать.

(13) А вот интересно, кроме КА 2 на этом сервере другой базы для этой платформы больше нет?
Может там ЗУП есть и в нем тормозит не так заметно, например.

(12) конфиг постгреса тут: https://pastebin.com/YaZ6msEd
на машину выделено 26 ядер сейчас, 32GB памяти, если не ошибаюсь. База сама - 4.5GB.

но это уже после экспериментов, поэтому именно сейчас что-то может быть неоптимальным. и основное внизу.

(17) до этого была КА1.1, там таких проблем не было.

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

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

И да, на старых платформах проблемы не возникали, а только на более-менее новых типовых.

* на старых релизах конфигураций типовых. - Под них подходила любая платформа - а вот под более-менее новые типовые : приходилось подменять платформу.

Черт,а может итоги

(15) а чем именно вы пользуетесь, подскажите, пожалуйста? Гилёв или что-то другое?

(10) Это мне неведомо, честно говоря. Выбор людей, которые занимаются 1С. Но, если память не изменяет, это всё апгрейдилось где-то в начале года, так что на тот момент она могла быть свежей.

(19) Спасибо, интересная мысль, попробую.

Попробуйте enable_nestloop=off - радикальное средство. Дикие тормоза исчезнут, но не факт что при этом что-то другое не замедлится слегка.

(22) 1.https://otr-soft.ru/faq-common/voprosy-po-platforme-i-konfiguratsii/zamer-proizvoditelnosti/

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

(23) если мне память не изменяет, я пробовал. Не помогло, увы.

(26) но тексту из ссылки в (18) видно, что настройка enable_nestloop сейчас стоит дефолтная и включенная скорей всего

(18) аха! виртуалка! щас прибежит H A D G E H O G s и расскажет, какие вы хипсторы

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


Ну и классический вопрос - VACUUM; ANALYZE; по крону делается?

(27) да, сейчас nested loops включены. я ещё раз попробую выключить и посмотреть, что там. проблема в том, что все пока переехали на тестовый ms sql, и сервер тоже перенесли туда, соответственно, лицензии на linux'овом сервере протухли.

(28) да, делаются, еженочно. насчёт виртуалок: у заказчика нет своего железа совсем, вычислительные мощности арендуются в облаке.

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

Наверное, исходя из твоих данных, можно попробовать так

shared_buffers = 16GB
effective_cache_size = 16GB

temp_buffers = 256MB
work_mem = 128MB
maintenance_work_mem = 256MB
max_wal_size = 1GB

fsync = off # опасно, но быстро
synchronous_commit = off # опасно, но быстро

stats_temp_directory размести в оперативной памяти (на tempfs).

И я бы еще выключил оналайн анализис в принципе.

(0) postgresql 10.7.1 от postgres pro проблемма скорее всего в этом, нужен или Postgres Pro Standard или Postgres Pro Enterprise, они за деньги, или дистибутив от 1с, или старые дистибутивы от Postgres Pro, например 9.6 или 9.4.

(31) fsync я выключать совсем не хочу, как-то опасненько. sync*_commit выключал - не меняется ничего. Временные файлы статистики уже в память положил, да. Остальные параметры поменять попробую, спасибо; хотя shared buffers не велики? Их, вроде, не больше четверти доступной памяти рекомендуют? Там просто на этой же машине и сервер 1С крутится, так что я расчитывал исходя из 20-25ГБ памяти для postgres.

(32) что за лажа? причем тут платно-бесплатно?

Сервер не правильно приготовлен.

Ну и в самой КА2/ЕРП2 есть проблемы по оптимизации отражения регламентных операций.
Тормозить и MSSQL, когда база начнет эксплуатироваться группой людей.

(34) Потому что патчей в бесплатной сборке от Postgres Pro нет в новых релизах

(33) Временные файлы проверь, что они точно в оперативке.
Шаредбуфферс увеличивай.
ЭффективКешСайз увеличивай.

(35) Это ты мне эти сказки рассказываешь? Или всем остальным?

(37) Это факт, бесплатные сборки от Postgres Pro не поддерживают 1с, зайди на сайт глянь, раньше на странице "СУБД для работы платформы 1С:Предприятие" была в том числе бесплатная сборка, сейчас нет.

(33) Ну и еще, поставь логгирование длительных операций, секунд на 30 для начала.
log_min_duration_statement = 30000

После этого можно будет отловить проблемные операнды. И начать думать, что делать.

Еще поставь
log_checkpoints = on

Может у тебя долго чекпойнты идут, тогда надо их растянуть или с валом поиграться.

(37) загляни в список совместимых http://v8.1c.ru/requirements/

там именно релиза 10.7 нет. Но есть 10.8
и есть вот такое на странице скачивания релиза в 1С
---
PostgreSQL, версия 10.8-13.1C

Внимание! Текущая версия PostgreSQL предназначена для использования с версией технологической платформы 1С:Предприятие 8 не ниже 8.3.14.1565.

Свежие бесплатные сборки от Postgres Pro вообще не пропатчены под 1с, смысл там возиться, ставить либо старую либо сборку от 1с.

(40) Да, такое написано в требованиях.
И чего?

Надо взять постгрес 10 для 1С. У меня сейчас 10.6 для 1С эксплуатируются.

Платформы 8.3 можно любые на пг10 эксплуатировать. Проблем не будет.

(38) http://repo.postgrespro.ru/1c-archive/

Думаю, 1с в названии должно говорить само за себя.

(43) Я имел ввиду это: http://repo.postgrespro.ru/pgpro-10/ бесплатные сборки от Postgres Pro

Попробуй отсюда сборку http://repo.postgrespro.ru/pgpro-9.6/

(24) спасибо, сделал предложенное. более 99% времени (407 секунд) - это строка Результат = Форма.Записать(ПараметрыЗаписи); Беда в том, что мне это ни о чём не говорит.

(39) в логах пусто при 20 секундах (20000 мс). Включил логгирование вообще всех запросов. Вижу множество запросов UPDATE с длительностью 5 - 5.5 секунд. Все они обновляют _AccRgAT261025. Ни один запрос к этой таблице меньше 5 секунд не выполнялся, все 5060-5400 ms. Как раз и получается 80 запросов по ~5 секунд - ~400 секунд, который насчитал счётчик производительности.

И вот теперь самое главное, что я подозревал, но никак объяснить не могу. Я перенёс базу на ram-диск целиком. Не поменялось вообще ничего. Любой update по-прежнему 5 секунд и выше.

(0) проведение документа операция из 3 проводок - ЖЕСТЬ!!!
Но, вы хотели вопросов - их есть у меня!
У вас там зеркало не настроено в постгри случаем?
"Вакуум анализе" делаете регулярно?
Показали-бы целиком конф-файл постгри, а?
Кроме 1С в базах постгри кто сидит?
Если антивиры/брэндмауэры отрубить ничего не изменится?
Если срубить все сеансы всех 1С, рестартануть сервер 1С и залезть в базу единственным сеансом - скорость не изменится?
Точно никакой веб-публикации нет?

Для начала хватит

(46) Это таблица итогов по 2-му субконто бухгалтерских счетов.

Там несколько регламентных операций.
Какую конкретно регламентную операцию проводит бухгалтер?

Пересчитай итоги.
Администрирование => Обслуживание => Регламентные операции -> Управление итогами и агрегатами

Скорее всего тебе нужно "Установить период рассчитанных итогов".

(48) да ну нафиг!!! Граница-же во всех типовых регламентно сдвигается! Неужели у кого-то "хватило мозгов" отключить!!!

(49) Я думаю, что там распределение РБП за длительный период.
Но проверить итоги стоит.

(50) так РБП отдельным-же документом а не на подписки повешено! Хотя я и не такой изврат видел

вообще ЖР + ТЖ наше всё!

(46) Отладка на сервере работает?
Обычно после Форма.Записать идут истинные виновники

(53) Но нужен ТЖ, без него никак

(51) Так вот он и пишет в своем топике: "Проведение одного регламентного документа может занимать несколько минут (от 3 до 8!!!)"

Т.е. бухгалтер проводит документ Распределение РБП. А там, небось, за 20 лет РБП.

(47) Отвечаю:
Зеркало не настроено.
Вакуум аналайз делается еженедельно.
Целиком конфиг я выше в (18) публиковал, ссылка на pastebin.
СУБД обслуживает только две базы 1С (КА1.1 и КА2), тормоза исключительно в КА2.
Сервер на Linux, никаких антивирей и файрволов нет.
При единственном сеансе скорость не меняется.
Более того, скорость не меняется даже если базу положить целиком на RAM-диск.

(48) Эм. Я понятия не имею, как конкретно называется эта операция, скажу честно. Подозреваю, что в документе, с которым я сейчас провожу эксперименты, перемещение товаров между складами разных подразделений. Вот пример документа: https://habrastorage.org/webt/o4/cq/8k/o4cq8kxczxnkqxokxej1wjsbtcc.png . Его проведение занимает 400-420 секунд. В логах postgres при этом появляется 80 UPDATE-запросов, каждый из которых выполняется от ~5060 до ~5400 милисекунд. Причём вне зависимости от того, где находится база - на диске хранилища или на ram-диске.

(55) В документе, с которым всегда проблемы - всего 5-6 позиций.

Сейчас попробую включить ТЖ и посмотреть, что полезного я там увижу.

На всякий пожарный напомню, что я не спец по 1С.

А, и к предыдущему. Любой из запросов, которые в логах длятся по 5+ секунд при выполнии его с explain analyze вручную в psql выполняются 1.5 мс максимум, план выполнения тоже вполне себе быстрый строится.

(54) что-то не получается включить журнал. Вернее, логгирование я включил, файлы логов появились, но они пустые. Конфиг выглядит следующим образом:

<config xmlns="http://v8.1c.ru/v8/tech-log">;
    <log location="/home/usr1cv8/.1cv8/1C/1cv8/logs" history="168">
        <event>
            <ne prorerty="Name" value=""/>
        </event>
        <property name="all">
        </property>
    </log>
</config>

Насколько я понимаю, вообще всё должно в логи литься с таким конфигом?

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

Мое мнение, я выше озвучивал уже, что это торомозит платформа, т.е. агент-сервера.

(59) попробовал подцепить через виндовый сервер 1С к линуксовому постргесу - никаких изменений. Время выполнения каждого запроса точно такое же. Попробую сейчас найти новую версию платформы и обновить.

(60) в настройках кластера можно еще параметры настроить. Недавно обсуждалось, но не о проблемах постгри как такового, а настройку кластера серверов. Там есть параметры и есть описание к оптимальным настройкам.

(61) смена платформы на 8.3.15.1565 ничего не изменила. Блин.

А у вас не осталось, случайно, ссылочки на обсуждение?

(62) разверни постгрес 9.6

(63) как раз развернул, сейчас базу импортирую

вот было в августе
---
  Arh01
68 - 02.08.19 - 14:23
Попробую здесь спросить.
У нас КА2, платформа 8.3.13, PostgreSQL 9.6.
Включен RLS.
У кого полные права - с производительностью все ОК.
У кого права ограничены - заметны подтормаживания.
Что стоит проапгрейдить для повышения скорости работы - PostgreSQL и(или) платформу?
И на какие версии?

(63) не помогло вообще. всё те же 5+ секунд на 1 UPDATE, что в сумме даёт те же 400+ секунд на всю операцию.

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

8.3.13.1644 и PosgreSQL: ошибка "variable not found in subplan target lists"

Какую версию PostgreSQL ставить?

(40) >>PostgreSQL, версия 10.8-13.1C
Не надо ее ставить. На ней, в зарплате(для ГУ), при вводе/пересчете больничного могла возникать ошибка СУБД. Это быстро поправили в тестовой 10.8-17.1C. Наверное, скоро сделают актуальной. Может быть и еще что-нибудь исправили в своих патчах.

В общем, родной конфиг не помог. Отключение RLS (если я правильно отключил) тоже ничего не изменило.

Становиться интересно!)
Сюда есть доступ: https://its.1c.ru/db/metod8dev#content:4692:hdoc ?

(71) увы, нет.

Решение проблемы с зависанием PostgreSQL
При выполнения некоторых регламентных операций (Закрытие месяца, Расчет себестоимости и т.п), где используются сложные запросы с большим количеством соединений больших таблиц, возможно существенное увеличение времени выполнения операции. В основном, эти проблемы связаны с работой оптимизатора PostgreSQL и отсутствием актуальной статистики по таблицам, учавствующим в запросе.

Варианты решения проблемы:

Увеличить количество записей, просматриваемых при сборе статистики по таблицам. Большие значения могут повысить время выполения команды ANALYZE, но улучшат построение плана запроса:
Файл postgresql.conf - default_statistics_target = 1000 -10000.
Отключение оптимизатору возможности использования NESTED LOOP при выборе плана выполнения запроса в конфигурации PostgreSQL:
Файл postgresql.conf - enable_nestloop=off.
Отрицательным эффектом этого способа является возможное замедление некоторых запросов, поскольку при их выполении будут использоваться другие, более затратные, методы соединения (HASH JOIN).
Отключение оптимизатору возможности изменения порядка соединений таблиц в запросе:
Файл postgresql.conf - join_collapse_limit=1.
Следует использовать этот метод, если вы уверены в правильности порядка соединений таблиц в проблемном запросе.
Изменение параметров настройки оптимизатора:
Файл postgresql.conf:
seq_page_cost = 0.1
random_page_cost = 0.4
cpu_operator_cost = 0.00025

(73) эти настройки тоже не влияют на результат &#55358;&#56631;‍♂️

(74)  Даже если так seq_page_cost = random_page_cost = 0.1?

(75) и даже так, да. какая-то фантастика.

(76) Есть еще след. статья: https://kb.1c.ru/articleView.jsp?id=91

Общие положения

В статье описывается настройка PostgreSQL версий 9.6 и выше на максимальную производительность для работы с Платформой 1С:Предприятие. Предполагается, что сервер СУБД PostgreSQL является достаточно производительным и имеет не менее:

8 - 512  Gb RAM
4 - 256 CPU cores
RAID 0-1 или SSD
​
Рекомендуемые значения индивидуальны и зависят от системы и нагрузки на нее.

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

Настройки сервера для PostgreSQL

Рекомендуется отключать HyperThreading
Рекомендуется отключить Energy Saving,  в противном случае могут непредсказуемо вырастать задержки ответов БД
Необходимо запретить своппинг разделяемой памяти SYSV/posix (FreeBSD: kern.ipc.shm_use_phys=1)


Обозначения

RAM – объем доступной оперативной памяти сервера. Если сервер используется не только для PostgreSQL, то надо уменьшить общий размер оперативной памяти на объем занятой памяти, выделенной другим приложениям.
max_connections - максимальное число соединений (или сессий) с PostgreSQL. Задается в конфигурационном файле.
WAL - Write Ahead Log, опережающий лог действий с таблицами и индексами. Основная задача - целостность и отказоустойчивость  базы данных при одновременном росте производительности.
checkpoint - точка восстановления база данных. Все данные WAL, записанные до checkpoint, становятся не нужны.
X …(Y) - диапазон значений от X до Y включительно

Параметры работы сервера PostgreSQL

Значения параметров работы сервера устанавливаются в кофигурационном файле postgresql.conf, расположенном обычно в директории данных кластера. Получить значения текущих, примененных настроек можно при помощи запроса к системному пердставлению pg_settings.


pg_stat_temp = ''  

Рекомендуется изменять значение по умолчанию пути к директории pg_stat_temp так, чтобы она находилась отдельно от директории кластера.  Причина в интенсивном изменении файлов в этой директории, что создает значительную нагрузку на дисковую подсистему. Директорию рекомендуется размещать в RAM-диске (для Windows) или tmpfs (для linux).

Параметры клиентских сеансов


temp_tablespaces = 'NAME_OF_TABLESPACE'

Задает директорию  расположения для временных таблиц и индексов. Помещение временных таблиц на отдельные (быстрые) диски может увеличить производительность. Предварительно необходимо создать пространство командой CREATE TABLESPACE. Если характеристики дисков отличаются от основных дисков, то следует в команде CREATE TABLESPACE указать соответствующий random_page_cost. См. https://www.postgresql.org/docs/10/sql-createtablespace.html.

row_security = off               >= 9.5

Отключение контроля на уровне записей.

Параметры подключений

ssl = off

Выключение шифрования, которое может приводить к увеличению загрузки CPU.

Потребление оперативной памяти

shared_buffers = RAM/4

Количество памяти, выделенной PostgreSQL для совместного кеша страниц. Эта память разделяется между всеми процессами PostgreSQL.

temp_buffers = 256MB

Максимальное количество страниц для временных таблиц -  верхний лимит размера временных таблиц в каждой сессии.

work_mem = RAM/32..64 или 32MB..128MB

Лимит памяти для обработки одного запроса. Эта память индивидуальна для каждой сессии. Теоретически максимально потребная память вычисляется как max_connections *work_mem, на практике она достигает такой величины крайне редко.  Это рекомендательное значение используется оптимизатором: он оценивает размер памяти для выполнения запроса, и, если это значение больше work_mem, запрос будет выполняться с использованием временных таблиц (для промежуточных результатов, сортировки, группировки…).  Work_mem не является в полном смысле лимитом: оптимизатор может  сделать неправильную оценку, и запрос займёт больше памяти, чем изначально было выделено. Это значение можно уменьшать, следя за количеством создаваемых в системе временных файлов:

select sum(temp_files) as temp_files, pg_size_pretty(sum(temp_bytes)) as temp_size from pg_stat_database;

maintenance_work_mem = RAM/16..32 или work_mem * 4 или 256MB..4GB

Лимит памяти для обслуживающих задач, например вакуум, автовакуума или создания индексов.

В случае выявления существенной фрагментации памяти процессов PostgreSQL в Linux, имеет смысл воспользоваться переменной окружения (её нужно установить в файле /etc/systemd/system/postgresql-10.service):

Environment=MALLOC_MMAP_THRESHOLD_=8192

Настройки WAL

fsync = on

Сброс буферов на диск (выполнение PostgerSQL системных вызовов fsync()). Выключение параметра приводит к росту производительности, но появляется значительный риск потери всех данных при внезапном выключении питания.

Внимание: если RAID имеет кэш и находиться в режиме write-back, проверьте наличие и функциональность батарейки кэша RAID контроллера! Иначе данные, записанные в кэш RAID, могут быть потеряны при выключении питания, и, как следствие, PostgreSQL не гарантирует целостность данных.

synchronous_commit = off

Выключение синхронной записи в WAL момент коммита транзакции. Создает риск потери последних нескольких транзакций (в течении 0.5-1 секунды), но гарантирует целостность базы данных.  Может значительно увеличить производительность.

checkpoint_segments = 32..256   < 9.5

Максимальное количество сегментов WAL между точками восстановления -  checkpoint. Слишком частые checkpoint  приводят к значительной нагрузке на дисковую подсистему. Каждый сегмент имеет размер 16MB.

checkpoint_completion_target = 0.5..0.9

Степень "размазывания" checkpoint'a. Скорость записи во время checkpoint'а регулируется так, что бы время checkpoint'а было равно времени, прошедшему с прошлого, умноженному на checkpoint_completion_target.

min_wal_size = 512MB .. 4G         > =9.5
max_wal_size = 2 * min_wal_size    > =9.5

Минимальное и максимальный объем WAL файлов. Аналогично checkpoint_segments.

commit_delay = 1000

commit_siblings = 5

Групповой коммит нескольких транзакций. Имеет смысл включать, если интенсивность транзакций превосходит 1000 TPS.

Фоновая запись на диск

bgwriter_delay = 20ms

Время сна между циклами записи на диск фонового процесса записи. Данный процесс ответственен за синхронизацию страниц, расположенных в shared_buffers, с диском. Слишком большое значение этого параметра приведет к возрастанию нагрузки на  checkpoint процесс и процессы, обслуживающие сессии (backend’ы). Малое значение приведет к полной загрузке одного из ядер.

bgwriter_lru_multiplier = 4.0

bgwriter_lru_maxpages = 400

Параметры, управляющие интенсивностью записи фонового процесса записи. За один цикл bgwriter записывает не больше, чем было записано в прошлый цикл, умноженное на bgwriter_lru_multiplier, но не больше чем bgwriter_lru_maxpages.

Настройки выполнения очистки (автовакуума)

autovacuum = on

Включение автовакуума.

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

autovacuum_max_workers = CPU cores/4..2 но не меньше 4

Количество процессов автовакуума. Общее правило - чем больше запросов на запись выполняется в системе (такие системы называются OLTP), тем больше процессов.

autovacuum_naptime = 20s

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

Использование ресурсов ядра

max_files_per_process = 8000

Значение по умолчанию – 8000, его не нужно уменьшать. Оно может быть увеличено в зависимости от характера нагрузки (максимальное значение зависит от операционной системы).  Один файл - это как минимум либо индекс либо таблица, но таблица/может состоять из нескольких файлов. Если PostgreSQL «упирается» в этот лимит, он начинает открывать/закрывать файлы, что может сказываться на производительности.  Диагностировать проблему под Linux можно с помощью команды lsof.

Настройки планировщика запросов

effective_cache_size = RAM - shared_buffers

Оценка планировщика запроса о размере дискового кеша, доступного для одного запроса. Это представление влияет на оценку стоимости использования индекса. Чем выше это значение, тем больше вероятность, что оптимизатором будет выбираться сканирование по индексу (Index Scan), чем ниже, тем более вероятно, что будет выбрано последовательное сканирование (Seq Scan).

random_page_cost = 1.5-2.0 для RAID, 1.1-1.3 для SSD

Стоимость чтения рандомной страницы, на которую будет опираться оптимизатор (по-умолчанию 4). Практическое значение параметра должно зависеть от «seek time» дисковой системы: чем он меньше, тем меньше должно быть значение random_page_cost (но  не менее 1.0) . Излишне большое значение параметра увеличивает склонность PostgreSQL к выбору планов с сканированием всей таблицы (PostgreSQL считает, что дешевле последовательно читать всю таблицу, чем рандомно индекс).  Оценка стоимости последовательного чтения делается, в свою очередь, с учетом параметра seq_page_cost, который равен по умолчанию 1.

from_collapse_limit = 20

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

join_collapse_limit = 20

Задаёт максимальное количество элементов в списке FROM, до достижения которого планировщик будет сносить в него явные конструкции JOIN (за исключением FULL JOIN). При меньших значениях сокращается время планирования, но план запроса может стать менее эффективным.

geqo  = on

GEQO - генетический оптимизатор запросов PоstgreSQL, который осуществляет планирование запросов, применяя эвристический поиск вместо полного перебора отношений. Он позволяет сократить время планирования для сложных запросов с большим числом соединений, потому не рекомендуется его отключать. Однако надо учитывать, что полученный им план может оказаться менее эффективным и, как следствие, увеличится время выполнения запроса. Управлять его включением более тонко помогает следующий параметр:

geqo_threshold = 12

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

Асинхронное поведение

effective_io_concurrency = 2

Оценочное значение одновременных запросов к дисковой системе, которые она может обслужить единовременно. Для одиночного диска = 1, для RAID - 2 или больше.

Параметры для платформы 1С:Предприятия

standard_conforming_strings = off

Разрешить использовать символ \ для экранирования.

escape_string_warning = off

Не выдавать предупреждение о использовании символа \ для экранирования

max_locks_per_transaction = 150…256

Максимальное число блокировок индексов/таблиц в одной транзакции.

max_connections = 500..1000

Количество одновременных соединений.


Параметры дополнительных модулей

online_analyze

online_analyze.enable = off

В общем случае мы не рекомендуем использовать синхронное автообновление статистики, однако его можно включить, если есть основания полагать, что фоновое обновление не дает нужного результата / оптимизатор часто ошибается в оценке количества строк.

Все остальные параметры имеют смысл, только если online_analyze.enable = on.

online_analyze.table_type = 'temporary'

Включает синхронное автообновление статистики на временных таблицах.

online_analyze.verbose = 'off'

Выполнение инструкции ANALYZE без опции VERBOSE.

online_analyze.threshold = 50

Минимальное количество записей, предшествующее обновлению статистики.

online_analyze.scale_factor = 0.1

«Доля» в величине таблицы, начиная с которой будет происходить  автообновление.

online_analyze.local_tracking = on

Отслеживание изменений в рамках соединения (для локальных временных таблиц).

online_analyze.min_interval = 10000

Минимальный интервал обновления для одной таблицы.

О модели процессора еще никто не спрашивал? И о режиме высокой производительности на железном сервере?

(78) Сколько много непонятной хрени. Используйте СУБД здорового человека.

(80) Я считаю просто: если ты в 2019 году не используешь СПО значит ты совсем замшелый.

(81) СПО, linux, Postgree - вот это все для гиков и занятных экспериментов.
Когда вы мне покажите 1С от 1000 активных пользователях в одной базе, работающих под Postgree/Linux под вашу ответственность - вернемся к этому разговору.

Конечно о замшелости Комплексной автоматизации можно писать тома. Наверняка еще больше можно про ЕРП написать. У меня в КА2 такая же беда с длительным проведением обычных документов (не регламентных) тоже была. Сначала перешел с файловой на Постгрес. Немного помогло, но не очень. Особенно тормоза были при любых операциях в общих журналах. Дату отбора в журнале поменял, жду 3 минуты, фильтрую документы жду три минуты, сортировка - 3 минуты, проведение 3 минуты. Каково же мое удивление было когда я убрал из формы журналов реквизиты с вызовом через точку от ссылки. Все стало после этого работать намного быстрее !!!!! Видать не любит 1с тянуть в журналы запросы с соединением. Смешно что при этом тормозил не только журнал но и любые операции с документов из этого журнала !!!!

(83) ты текст исполняемого запроса видел?
Что то мне говорит что благодаря тем самым через точку там спагетти из leftjoin

(84) Ну я и говорю что 1с, либо постгрес не любит joinы

(85) да там боюсь и мсскл сказал бы кря

(84) что-то мне подсказывает что тами порноRLS.
(0) под пользователем со всеми установленными галочками прав (вообще все существующие роли) скорость тоже не торт?

(85) 3 проводки - 5 секунд? Там не джоины крайние полюбому.

(79) Xeon E5-2665. Ядер там хоть одним местом жуй. Режим производительности включён.

(78) Именно к этой статье доступа у меня нет, но я видел либо перепечатки, либо подобные, и все эти параметры уже оптимизированы, само собой. Да и с Postgres я не первый день знаком. У меня поэтому и недоумение в данной связке.
И меня очень смущает, что любой UPDATE выполняется именно 5-5.5 секунд, не больше, не меньше, вне зависимости от того, где находится база - на диске хранилища или на диске в памяти, вне зависимости от настроек планировщика.

(89)длина очереди диска сколько?

(87) RLS я в настройках выключил. По-крайней мере, я думаю, что выключил, галочку Ограничивать права на уровне записей убрал. Тест я провожу как раз от пользователя с максимальными правами. Я сейчас экспериментирую в отдельной базе на отдельном сервере.

Вот пример запроса, который выполняется 5 секунд:

2019-08-16 07:27:52.722 MSK [20366] LOG:  duration: 5124.489 ms  statement: UPDATE _AccRgAT261025 SET _Fld60987 = COALESCE(CAST(_AccRgAT261025._Fld60987 AS NUMERIC(21, 2)),CAST(0 AS NUMERIC)) + -CAST(275.45 AS NUMERIC), _Fld60990 = COALESCE(CAST(_AccRgAT261025._Fld60990 AS NUMERIC(21, 2)),CAST(0 AS NUMERIC)) + -CAST(275.45 AS NUMERIC), _Fld60991 = COALESCE(CAST(_AccRgAT261025._Fld60991 AS NUMERIC(21, 2)),CAST(0 AS NUMERIC)) + CAST(0 AS NUMERIC), _Fld60992 = COALESCE(CAST(_AccRgAT261025._Fld60992 AS NUMERIC(21, 2)),CAST(0 AS NUMERIC)) + CAST(0 AS NUMERIC), _Fld60993 = COALESCE(CAST(_AccRgAT261025._Fld60993 AS NUMERIC(21, 2)),CAST(0 AS NUMERIC)) + CAST(0 AS NUMERIC), _Fld60994 = COALESCE(CAST(_AccRgAT261025._Fld60994 AS NUMERIC(21, 2)),CAST(0 AS NUMERIC)) + CAST(0 AS NUMERIC)
        WHERE (_AccRgAT261025._Period = '2019-05-01 00:00:00'::timestamp AND _AccRgAT261025._AccountRRef = '\\264\\362\\330P\\346\\3330\\246\\021\\351[m\\023\\271=\\012'::bytea AND _AccRgAT261025._Fld60983RRef = '\\270H\\361s\\301\\255hq\\021\\342D\\035\\335\\376\\202\\003'::bytea AND _AccRgAT261025._Fld60984RRef IS NULL AND _AccRgAT261025._Fld60985RRef = '\\264\\362\\330P\\346\\3330\\246\\021\\351o\\037\\211\\022\\036!'::bytea AND _AccRgAT261025._Fld60986RRef = '\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000'::bytea AND _AccRgAT261025._Fld2194 = CAST(0 AS NUMERIC) AND _AccRgAT261025._Value1_TYPE = '\\010'::bytea AND _AccRgAT261025._Value1_RTRef = '\\000\\000\\001%'::bytea AND _AccRgAT261025._Value1_RRRef = '\\210\\353PPTP00\\021\\3323\\003_\\012Re'::bytea AND _AccRgAT261025._Value2_TYPE IS NULL AND _AccRgAT261025._Value2_RTRef IS NULL AND _AccRgAT261025._Value2_RRRef IS NULL AND _AccRgAT261025._Splitter = CAST(0 AS NUMERIC)) AND (_AccRgAT261025._Fld2194 = CAST(0 AS NUMERIC))

Я вообще не понимаю, что тут может выполняться так долго.

(90) Очередь пустая. Полностью. Я же говорю, я сейчас базу данных положил на RAM-диск. Вообще ничего не поменялось. Такое ощущение, что какие-то таймауты. Но какие?

(91) граница рассчитанных итогов показывает какое число?

(92) у вас типовая КА или перепиленная?

если в 1С становить галочку разделения итогов - ничего не поменяется?

(93) Подскажите, пожалуйста, где посмотреть, чтобы я нужное назвал?
Насколько я знаю, конфигурация типовая.

(91) Запрос у тебя в руках - что мешает запустить с анализом плана и посмотреть "что тут может выполняться так долго"?

(97) я выше писал: вручную этот же запрос выполняется 1.4 мс.

(98) параметры разные

(97) вот тут писал: (57)

(99) параметры какие или чего?

(96) в режиме 1С:Предприятия. «Администрирование — Поддержка и обслуживание —  Регламентные операции — Управление итогами и агрегатами» или «Все функции — Стандартные — Управление итогами», в обоих случаях можно установить период рассчитанных итогов;

(101) даты,аналитика и т.д

(56) > Вакуум аналайз делается еженедельно.
Аналайз нужно делать намного чаще. Например пару раз в день. Для баз с бухгалтерией еще чаще.
(92) Замер производительности на сервере сделали?
>более 99% времени (407 секунд) - это строка Результат = Форма.Записать(ПараметрыЗаписи);
Это замер только на клиенте.

(102) установить можно, но я хотел сначала проверить текущие, но не нашёл, где.

(92) у меня был такой случай - база (УТ11, небольшая, на postgree) сильно тормозила при проведении РТиУ, анализ показал, что один из регистров необычно распух, а распух он оттого, что кто-то ввёл документ датой 16.08.0015. Перенос документа и пересчёт регистра привёл к тому, что на том же оборудовании проведение РТиУ стало выполняться не минуту, а секунд 10. Ещё проверьте, нет ли документов в будущем (тоже влияет на скорость).

(105) Блин да скажи даты итогов у регистров

(107) нажал кнопку "Установить итоги...". 15 секунд, итоги на 31.07 и 31.08 (для бухгалтерии)

(108) Теперь попробуй провести,даже если будет тупить хотя бы это проверили

(108) Потом на тестовой базе по слоном в конфигураторе,пересчитать итоги

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

(109) лучше не стало, разве что ещё хуже на пару сотен милисекунд.

(111) Попробуй через конфигуратор пересчитать,в (106) по делу написали

(112) да, сейчас попробую, жду, пока перепроведение завершится. Это ж 7 минут.

(111) Нужно включить отладку на сервере https://programmist1s.ru/vklyuchenie-otladki-na-servere-1s/

(114) понял. у меня не винда, но как сделать - понял, сейчас дождусь окончания Тестирования и исправления... и проверю, что скажет.

(115)Ну как

(115) Вы моё предположение проверили? Берёте любой пузомер и смотрите на размеры регистров - если есть заметно большой - делаете запрос к максимальной и минимальной дате к нему.

(117) т.е. предположение в том, что конкретная СУБД содержит данные, которые в нее "залили" каким-то образом за относительно большой период. И теперь расчет себестоимости происходит плохо на любой СУБД, но при этом на постгри это выглядит заметно хуже. Как так?

(116) прошу прощения за паузу, хочу перепроверить. После Тестирования и исправления время выполнения каждого UPDATE уменьшилось до 1.2 секунды. Это тоже много, как по мне, но всё-таки в пять раз ниже, чем было. Ради интереса нужно попробовать тот же документ перепровести на рабочей базе в ms sql с замером времени выполнения.

Сейчас я поставил 11 пострес, залил в него базу, убедился, что документ проводится 400+ секунд и запустил Тестирование и исправление. Как закончится - ещё раз проверю время выполнения проведения того же документа.

Кстати, судя по цифрам, 9.6 работает чуть медленнее, чем 10-11. Довольно незначительно, но тем не менее.

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

(117) подскажите, пожалуйста, что есть "любой пузомер". Пока я не смотрел размеры регистров, не знаю, чем это можно сделать. Размер таблицы _accrgat261025 - 54MB + 54MB index = 110MB всего. После пересчёта итогов из конфигуратора размер данных уменьшился до 14МБ.

(119) Теперь смотри минимальную и максимальную даты в регистрах (уже писали об этом).
debug - это для отладки на сервере. Теперь можешь запускать замер производительности еще раз и смотреть, какая строка дольше всего выполняется.

(120) Не знаю, как сделать это из 1С, но из командной строки так:

test_ka2=# select max(_period) from _accrgat261025;
         max
---------------------
3999-11-01 00:00:00
(1 строка)

test_ka2=# select min(_period) from _accrgat261025;
         min
---------------------
2018-12-01 00:00:00
(1 строка)

3999-11-01 00:00:00 - это пять. Как выяснить, откуда этот период, не подскажете?

Так там смещение же в 2000 лет идет,то есть вбили 1999 год что ли

По поводу серверной отладки: после включения дебага на сервере вывод принципиально не поменялся: https://habrastorage.org/webt/pd/dw/wa/pddwwad2blmqu9ilfbq0ahnzuze.png

Но это уже после перепроведения итогов, до было около 417 секунд на сохранение формы (первая строка).

(121) Смотри на эту запись/записи.
Лучше сделай запрос из 1с-ки,там понятней будет, откуда она.

(121) это нормально, слушай если я правильно тебя понимаю то один и тот же запрос, выполняемый 1с и выполняемый из командной строки отличается в 1000 раз? если так то логично подумать что проблема в плане запроса, план запроса 1с и план запроса из командной строки отличаются.

(123) А службу рестартовал после дебага?
Чета не видно ничего серверного в скрине.
(125) Точно нормально, что максимальная 3999-11-01 00:00:00, при минимальной 2018-12-01 00:00:00?
Если че, про смещение знаю, но тогда и минимальная должна была бы сместиться (или в минимальной и есть проблема?).

(126) конечно рестартовал. флаг у исполняемого файла присутствует.

Там такая запись не одна, кстати:

test_ka2=# select count(_period) from _accrgat261025 where _period = '3999-11-01 00:00:00';
count
-------
  7239
(1 строка)

А следующая запись уже нормальная:

test_ka2=# select _period from _accrgat261025 where _period <> '3999-11-01 00:00:00' order by _period desc limit 1;
       _period
---------------------
2019-07-01 00:00:00
(1 строка)

(124) я из 1ски не умею, к сожалению.

(128) открыть в режиме предприятия подозрительный регистр, отсортировать по дате (кликом по заголовку) и смотреть на максимальную/минимальную дату.

(126) 3999-11-01 00:00:00 это хранение текущих итогов, соответственно смещения дат нет.

(130) но это не должно влиять на производительность

(125) после перепроведения итогов - нет. Из командной строки дольше.

(119) Попробуй http://catalog.mista.ru/public/978816/
Работает с сервером приложений 1С и PostgreSQL на Linux. Клиент 1С должен быть на Windows.

Вот это, я понимаю, триллер! Извините за оффтоп. Сами планируем переход с упп на ка. Сейчас более-менее сносно (я бы сказал, чуть менее, чем терпимо) работает на постгре 300+ юзверей.

(129) я не знаю, что это за регистр, к сожалению. у меня есть только название таблицы. Я понимаю, что это какой-то аналитический счёт, но и только. Как понять, к чему и где его найти в 1С - не знаю, извините.

(135) Вам либо сюда - (133), либо в 1С в консоли запросов написать запрос с выбором даты, как в (121).

Автор как успехи?

(122) у него постгри и там никаких сдвигов нет! Сдается мне там с границей пипец!

+ (138) а, не, это-ж актуальные итоги!

(139) да, сама именно эта строчка с датой - это актуальные итоги так вводятся

(127) Дай вывод строки
select _period, count(*) from _accrgat261025 group by _period

Автор вот кстати интересная статья: http://catalog.mista.ru/public/177171/ и не менее интересные комментарии 58 и 128

Коллеги, прошу прощения, вчера пришлось срочно переключиться на другие задачи.

(141)
test_ka2=# select _period, count(*) from _accrgat261025 group by _period;
       _period       | count
---------------------+-------
2019-07-01 00:00:00 |  7766
2019-04-01 00:00:00 |  7782
3999-11-01 00:00:00 |  7239
2018-12-01 00:00:00 |  5629
2019-03-01 00:00:00 |  7488
2019-05-01 00:00:00 |  7875
2019-06-01 00:00:00 |  7936
2019-02-01 00:00:00 |  7316
2019-01-01 00:00:00 |  7124
(9 строк)

Меня сильно смущает, что операция по обновлению записи в таблице с 66 тысячами строк выполняется больше секунды. И таких операций масса.

Мне пришлось сделать ещё одну копию базы, потому что я экспериментировал с документом в уже закрытом периоде, поэтому сейчас восстановлю её и замерю производительность в MS SQL и в PostgreSQL на то же базе на одном документе.

На новой базе сразу после восстановления и vacuum full analyze и reindex документ проводится 9,5 секунды. На той же самой базе в MS SQL - 0,956 секунды. Разница в 10 раз.
Сейчас доеду до другого места - продолжу.

(145) Это сейчас сами сервера 1С одинаковые? Эти две СУБД подцеплены к одному и тому же серверу или это разные сервера 1С в разных ОС ?

(145) Как я вижу ситуацию:
1.В таблице accrgat261025 накопились записи с нулевыми значениями, чем это черевато можно прочитать в этой статье: http://catalog.mista.ru/public/177171/ что делать озвучено в комментарии 128 к этой статье.
2.Посе того как записи с нулевыми значениями были удалены (Тестирование и исправление - Пересчет итогов) и обновления статистики vacuum full analyze стало лучше но
3.Запросы из 1с postgres выполняет по неоптимальному плану, при наличии записей с нулевыми значениями разница запроса из 1с и запроса из консоли доходила до 1000 раз(миллисекунды и секунды)
4.Возможные решения: переписать код запроса, обновить конфигурацию(возможно в обновлении код запроса исправлен)
или играться с параметрами postgresa отвечающие за план запроса

Поправьте меня если я не прав.

как бы есть мысль, что было бы неплохо проверить еще влияние параметра "Количество ИБ на процесс"
У меня такое подозрение складывается, что производительность именно в постгри очень сильно от него зависит.
В этой ветке эту особенность настройки еще не проверяли

(146) до этого были разные сервера 1С. Сейчас подцепил пострес на linux к тому же серверу 1С, через который подключен ms sql - абсолютно такой же результат, как и с линукса, 9.5 секунд.

Сейчас запущу перепроведение итогов на вновь загруженной базе. Посмотрю результат после этого.

Щас почитал про Postgree.
В нем нет профайлера в понимании SQL
Ты должен, как последний раб на галерах, собрать лог файл, найти в нем запрос и запустить его через EXPLAIN.
Выкиньте эту херню.

(148) количество информационных баз на процесс по-умолчанию - 8. Соединений - 128. Но я сейчас вообще один на этом сервере 1с.

(151) это ты один, а базы крутятся в регламентных заданиях и их там у тебя уже не одна.
Переключи ради интереса. Это же не долго. Даже перезагрузка не потребуется, чтоб увидеть будет ли эффект.

(152) переключить на сколько? одна база - один процесс?

База сейчас на сервере одна, по сути, одна. Вернее, в постгресе одна, на сервере больше.

Меня сильно смущает то, что такая производительность при работе с базой, которая находится на диске в памяти. В новой базе в указанном справочнике 270 тысяч строк. Посмотрим, сколько останется после пересчёта итогов.

(147) Да, сейчас пересчитаю итоги и попробую разобраться с нулевыми значениями. Но неужели настолько неэффективнее postgres получается? Ведь на той же самой базе, прямо один в один, скорость в ms sql выше в десять раз на конкретной операции проведения одного и того же документа. При этом в ms sql база на хранилище, а не в памяти.

(153) тебя принципиально ломает установить хотя бы для тестирования 1 база на процесс?

(155) сам постгресс эффективен в той же степени, как и сиквел.

// Я знаю, что 1С:Fresh использует postgres, что Кнопка использует postgres, давно и успешно.
Это же твои слова :-)

В данном конкретном случае у тебя в базу вкачали переносами или чем-то подобным всякую бяку. Ну и запросы вероятно попадаются кривоватые, т.к. 1С-конфигурация в базе программистами изменена.

Кстати, если сейчас сработает эффект от Количества ИБ на процесс, то этот баг будет уже не в СУБД (у нас же в этом примере сейчас всего одна ИБ в наличии), а в платформе по сути.

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

(157) Так одинаковые данные в ms sql и в постгрес.

Занимательная статистика: до пересчёта в таблице была 227451 строка, стало 65785 строк. Сейчас закончится вакуум и реиндексация после пересчёта (для чистоты эксперимента) - запущу ещё раз оценку производительности.

Перепроведение итогов уменьшило время проведения документа до 4.38 секунды, вдвое.

Сейчас буду разбираться с нулевыми значениями.

Автор, попробуй еще это:

plantuner
plantuner.fix_empty_table = 'on'
Исправляет чрезмерную пессимистичность оптимизатора посгтреса на пустых, недавно созданных таблицах.

online_analyze
online_analyze.table_type = 'temporary'
Автоматически анализировать временные таблицы при их изменении. Фоновый analyze может заметно отставать, и, как результат, планер ошибается.
online_analyze.verbose = 'off'
Отключение излишней болтливости автоматического analyze.

(161) Отсюда https://github.com/postgrespro

(161) это всё сделано, разве что стоит online_analyze.table_type = 'all', а не только на временные.

(161) любопытно. переключение онлайн-анализатора _только_ на временные таблицы уменьшило время проведения документа до 1 - 1.4 секунд (несколько раз проверил, даже не завершая сессию менял значение и перезапускал постргес). Причём вариант анализировать все таблицы я не сам придумал, а где-то вычитал, типа, у Гилёва, если мне память не изменяет.

Вот как бы теперь сделать, чтобы время было 1 секунда, а не 1.4 - и будет практически ms sql. Правда, неизвестно, что там будет со скоростью, если и на нём итоги пересчитать. И неизвестно, как через какое-то время после пересчёта итогов будет развиваться ситуация.

(164) Скинь конфиг я посмотрю.

(164) вообще это спорный рецепт к использованию онлайн-анализа на абсолютно все таблицы, как минимум
Например :

- делаем один запрос (а ведь до него были уже изменения в данных - стартует анализ - а ведь это ест время и подвешивает старт основного запроса)

- по итогам обработки результатов запроса вносим измененные данные

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

В стратегии работы с СУБД получается, что в online_analyze.table_type = 'all' может натолкнуться на спорное прикладное решение, которое использует итерации или циклы или рекурсивные обращения данным с их перезаписью.

Было бы забавно выяснить, откуда ноги растут у этого тестового примера, кто писал процедуру проведения документа.

(165) в (18) есть ьтло что он называет конфигом... я хз, там за 600 строк и многие параметры встречаются многократно с разными значениями, например max_connections=50 и max_connections=100

(167) но с тех пор многое поменялось

(164) Отключи online-analyze совсем, заодно и fsync и full_page_writes. Посмотри, что изменится. Возгласы о том, что "целостность базы данных в опасности!" к твоему(тестовому) случаю не имеют отношения. Ничего там не сломается.
Также(об этом уже здесь писали) обновиться до всего самого последнего, может, оптимизировали  или сам запрос или его трансляцию. Вчера еще одно обновление вышло PostgreSQl, версия 10.8-18.1С, там все свои патчи правят.

В очередной раз убеждаюсь, что выбор постгреса как субд для 1с был неудачным, ввиду плохой детерминированности поведения при разборе сложных запросов с подзапросами и временными таблицами, которые так характерны для 1с. Лучше бы они поддержку ib/fb сделали.

(170) А что, иб/фб лучше?

(170) // Лучше бы они поддержку ib/fb сделали.

Чтоб нырнули с головой?

Ты хоть на концептуальные отличия в этих СУБД обращал внимание?
Подсказываю: почему ни одна из известных СУБД не может охватить весь рынок целиком?

з.ы. Я вижу, что постепенно подходят к полному обособлению или поднятию уровня собственного решения до полноценной СУБД в виде сейчас пока еще "файловой версии".

(170) зацени вот эту хрень
Один нумератр для документов и справочников

Что с этим будет делать СУБД, с какой скорость обрабатывать?

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

(174) Да, так. Но в плане оптимизации трансляции кое-что делается - https://dl03.1c.ru/content/Platform/8_3_15_1565/1cv8upd_8_3_15_1565.htm#83bf2cb5-14ce-11e9-a3f7-0050569f678a
Так и пишут(например):
"Оптимизировано исполнение запроса, содержащего константные значения в списке выборки. Константные значения, находящиеся в теле запроса, реализуются параметрами запроса. Это приводит к уменьшению количества перекомпиляций планов в СУБД, и как следствие, увеличению производительности таких же запросов, если они отличались только значением константы."
Или "Оптимизировано использование регистра бухгалтерии при работе с использованием СУБД PostgreSQL"
Хотя, для теста(Гилева) в режиме совместимости пока все наоборот, "оптимизация" приводит к видимому уменьшению результата, процентов на 15. Может в самом тесте уже что-то надо подправить, а то он с момента выхода 8.3 и не менялся совсем. Так сказать, реалий времени уже не учитывает.
А использования в 1С кэша запросов PostgreSQL, конечно, не хватает.

(175) В режиме осутствия совместимости с более ранними версиями.

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

(165) спасибо, сейчас приведу к более читаемому виду и выложу.

(165) Полный конфиг: https://pastebin.com/YaZ6msEd
Только раскоментированные\изменённые значения: https://pastebin.com/Y4DUcBZ5

(169) Базу я размещал и на диске в памяти, и на хранилище, разницы в скорости нет ни малейшей. Т.е. это явно не ввод\вывод оказывает влияние. А софт я уже обновил: 1c 8.3.15.1565 и PG PRO 1C 11.5

(175) делается... вот у постгрипро - делается! Слышал есть там модулёк, который помогает хорошо так оптимизировать план... настолько что это даёт выигрыш в скорости на единицы и десятки % (скорее всего сверх того и ресурсов расхищает куда как меньше).

(178) >1c 8.3.15.1565 и PG PRO 1C 11.5
жёстко! Хорошо хоть не эксперементальные версии.

Для оценки конфига необходимо так-же знать что за диски (хдд/ссд, вот только не надо рамы!!!), сколько памяти всего и сколько их них доступно всегда под постгри.
Надеюсь никаких выкрутасов по безопасности ведь нет? В смысле pg_ident - пустой, pg_hba из 2 строк (остальные закомментированы):
host    all             all             0.0.0.0/0            md5
host    all             all             ::1/128                 md5

(179) Ты это имеешь ввиду Adaptive query optimization for PostgreSQL: https://github.com/postgrespro/aqo ?

(181) ага, именно про эго.

или эко или эйко  - запутали меня эти сакасы

(180) Памяти всего на машине 32ГБ этой останется, но там ещё сервер 1С живёт. По хранилищу лучше расчитывать на производительность в 2000-3000 iops'ов. Т.е. это не локальный SSD, конечно, но прилично быстрее HDD.
По безопасности выкрутасов нет.

(180) тс выше пояснял, что у него виртуальные машины.

(179) Он(модуль) еще и продается, в составе Postgres Pro Enterprise, за приличные деньги. Портировать в бесплатную версию, скорее всего, никто не собирается.
А так, там столько всего, что глаза разбегаются https://postgrespro.ru/docs/enterprise/11/intro-pgpro-vs-pg
А профайлера нет... Такого, чтобы помимо плана запроса, предлагал бы еще пути его оптимизации, а лучше, чтобы оптимизация давалась сразу в терминах 1С. Далеко еще до такого, наверное.

(186) >Такого, чтобы помимо плана запроса, предлагал бы еще пути его оптимизации, а лучше, чтобы оптимизация давалась сразу в терминах 1С.

Было расширение hypoindex или что-то типа того, Лустин про него несколько лет назад упоминал. Вполне себе норм идея строить индексы на основании статистики запросов и тех индексов что не хватает при выполнении их. Но что-то проект вроде помер.

(185) вот дерьмо-то! Ненавижу виртуалки под сервера СУБД и 1С, ну кроме сервера лицензирования!

(0) >>> что это за решение проблемы - потратьте кучу денег?

Если вы методом тыка пришли к выводу, что SQL работает быстрее, то думайте сами, стоят ли оно этих денег... :)

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

Но, вообще, любопытно попробовать из интереса.

(189) в результате-то не работает _настолько_ быстрее. Просто нужно было потратить время на то, чтобы разобраться. Люди, которые за это деньги получают, разбираться не стали (похоже, просто не умеют), а предложили потратить ещё больше денег на лицензии или их просто украсть. По мне - крайне неэффективный подход. В результате пришлось заниматься проблемой мне, хотя я именно к 1С имею весьма далёкое отношение. Но в результате всех этих телодвижений время проведения конкретного типа документов (даже конкретного документа) сократилось в 6-8 раз.

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

(191) Ты будешь улыбаться, но 1С-ники тоже к Посгрессу не имеют отношения :)

+ Это как если бы Админа попросили установить Линух и настроить... А до этого он только Форточками занимался. :)

Я тут этой веткой вдохновился и полез на ютуб. Однако, нашел кое-что - весьма красиво подводящее резюме под эту ветку.
очень-очень рекомендую

https://www.youtube.com/watch?v=lbpRjUwHSn8


INFOSTART.RU
Опубликовано: 17 дек. 2018 г.

PostgreSQL не так давно появился на российском рынке, поэтому у многих специалистов появляются сомнения, насколько удобно с ним работать, учитывая специфику 1С. Антон Дорошкевич, руководитель IT-отдела и направления оптимизации 1С компании «ИнфоСофт» (г. Новосибирск), рассказал о своем опыте применения этой СУБД. Тема его доклада звучала провокационно: «1С-батл между MS SQL 2016 и PostgreSQL версии 9 и версии 10».

Обсуждение и текстовый вариант доклада: http://catalog.mista.ru/public/962876/

Если конкретно по тому параметру, который сильнее всего себя проявил - это после 20-ой минуты примерно

Конкретно вот по этому моменту

(164)
// любопытно. переключение онлайн-анализатора _только_ на временные таблицы уменьшило время проведения документа до 1 - 1.4 секунд

вот копипаста из статьи по ссылке в (194)
---
Ради интереса отключили OnlineAnalyze. Получили результат тестирования в 17 раз хуже. Мы прождали несколько дней, она у нас все-таки посчитала, результаты упали в 17 раз.

К сожалению, в своей практике сталкиваюсь очень часто и даже на очень крупных предприятиях, на которых есть Postgres и которые уже поискали ответы в интернете на запрос «1С + Postgres тормозит», что люди следуют этим 2 вредным рекомендациям. А тем временем в самом конце конфигурационного файла есть строчка OnlineAnalyze.enable = off. Но если поправим настройку на on, все взлетает.

Я вас призываю, если у вас уже стоит Postgres, посмотрите свои конфигурационные файлы. И включите патч, включите! Это очень крутая вещь.

И еще один момент. В последней сборке Postgres, опубликованной на сайте 1С, к сожалению, этого патча нет. Его просто нет в строчке предкомпилированных библиотек, он в настройках есть и даже внизу включен, но его нет в строчках предкомпилируемых библиотек. Надо добавить. Внимательно отнеситесь: патч должен быть, патч должен быть включен. И будет резкий рост производительности.
---

(196) Весело обстоят дела)

(192) так проблема не в настройках Postgres'а в вакууме, а в связке 1С - Postgres. Если бы дело было только в PG, всё бы давно уже решилось. Но тонкие места именно с точки зрения 1С могут знать только люди, с 1С работающие. Элементарно та же активная работа с временными таблицами - уже особенность.

(194) Отличное выступление, спасибо, очень любопытно.

(198) ну с PG работают 0 целых 0 десятых 1с-ников. Поэтому подавляющее большинство 1с-ников к посгресу отношения не имеют.

(198) Это называется dba

(199) И очень жаль что 0 целых 0 десятых, скилловый разработчик обязан разбираться в postgresе, и не важно на чем он пишет java, python или 1с.

Автор после всех манипуляций какие итоги? с 3 минут до полутора секунд, я правильно понимаю?

(199) Ты живешь в другой Вселенной.

(202) не совсем так. У меня нет возможности проверить на том же документе, что и раньше, поскольку он в закрытом периоде.

Но я выбрал другой документ, чтобы сравнить производительность с MS SQL. Изначально сразу после загрузки текущей базы проведение этого документа занимало 9.5 секунд. На MS SQL - 0,956 секунды. После перепроведения итогов время уменьшилось до 4.38 секунд. А после манипуляций с конфигом (насколько я понимаю, из-за переключения online_analyze с 'all' на 'tmp') стало 1 секунду (это я прямо сейчас перепроверил).

(0) не буду еще раз это все объяснять, ставь MS SQL + 64 server. или ...

проверено тестами хуестами и прочими сравнениями, линукс и постгре говнина ...

(204) Было бы интересно выяснить деградацию постгресса при росте нулевых записей в таблице итогов с параметром online_analyze 'tmp', нет возможности развернуть бэкап где еще не было перепроведения итогов и замерить время проведения?

(207) есть, сейчас сделаю.

(206) Ты понимаешь что с такими выражениями: "тестами хуестами, линукс и постгре говнина.." ты на рано или поздно никому не нужный на бирже труда окажешься?

(207) а вот сейчас я в большом недоумении.

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

После vacuum full analyze время _увеличилось_ до 1.28-1.3 секунд.

После перепроведения итогов время проведения документа - 0.92-0.95 секунд.

Я могу объяснить это только тем, что сменилась версия PG - в начале была 10.7, сейчас - 11.5.

Кстати, я вспомнил ещё одно изменение, которое сделал в конфиге - я уменьшил после видео выше default_statistics_target. Там говорили, что тормоза какие-то при больших значениях. Но возврат значения в 10000 скорость не изменил.

(210) Получается с online_analyze 'tmp' нет особой деградации при росте нулевых записей, интересно и непонятно!

(196) Для тех информационных систем, с которыми автор доклада имеет дело http://forum.infostart.ru/forum86/topic200178/message2053519/#message2053519
скорость устаревания статистики, видимо, очень большая. Поэтому, держать online analyze включенным(в том числе и для всех таблиц) в подобных случаях, скорее всего, полезно, при общем уменьшении скорости работы не позволит уйти полностью в ступор.
Впрочем, держать включенным для временных таблиц, уместно будет для любых баз и любой интенсивностью работы с ними, так как autovaccuum для временных таблиц статистику не обновляет.

(210) т.е. 4 мин + -> 1 сек?

(213) наверняка можно сказать, что время уменьшилось с 9.5 секунд до 0.92 секунды, это на текущей выгрузке из рабочей базы и на новом документе. Перепровести на новой базе тот документ, который проводился 417 секунд, я не могу, потому что он в закрытом периоде.

Восстановил старую базу данных из архива. Проведение документа, который раньше проводился 417 секунд, теперь и ДО, и ПОСЛЕ пересчёта итогов занимает 0.72-0.7 секунды. Я посмотрел по логам, запросы, которые выполнялись 5 с лишним секунд, сейчас выполняются 0.5-1 МИЛИсекунду. Я в замешательстве полном. Изменились версии 1С, PG. И обновилось ядро, но это не должно влиять.

(211) ну, вот получается, что нет. Уже несколько раз проверил - сейчас старую базу загрузил, до пересчёта итогов 218К строк, после - 66К. Время проведения абсолютно одинаковое, разница в пределах погрешности.

(214) > Я в замешательстве полном.
здесь может быть фактор "здравствуйте, я ваш виртуальный диск в облаке"

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

У меня такое было, что искал ведьм в настройках, а в итоге заменил один sata-кабель. Он хотел - работал нормально, хотел - отваливался, но не до конца. Но там были доказательства: в dmesg ругань на таймауты в железе.

(215) 417 секунд было на базе, которая лежала на ram-диске. Перенос базы с хранилища в память и обратно скорость не менял и не меняет вообще.

(216) на рам-диске виртуальной машины, ещё раз ВИРТУАЛЬНОЙ машины. На ней ни замеров сделать (замеры хоста - кусочек целого, а нужно целое) и понять куда что сейчас переносится/мигрирует (если конечно всё это удовольствие не заблокировано, ну или если машинка тривиальная но тогда совсем нет смысла в виртуальности).

(217) Контроль над облаком, где всё запущено, у меня полный. Я _знаю_, что там происходит. Под этот тест был выделен отдельный хост, на котором кроме данной задачи не выполнялось ничего. Т.е. я могу утверждать, что результаты были бы точно такими же, если бы всё запускалось в системе хоста, а не гостя. Вообще, это уже давно миф - о том, что _вычислительная_ часть работает как-то хуже, потому что давно не используется эмуляция, а полноценная аппаратная виртуализация. Да, какие-то накладные расходы есть, но это максимум проценты.

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

Более того, я пробовал ставить сервер PG прямо на железо и локальный SSD, результаты не менялись даже на пару сотен милисекунд.

(218) ладно, ладно, уговорил.

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

(219) Последние результаты - 1С 8.3.15.1565 и PG PRO 1C 11.5 (http://repo.postgrespro.ru/1c-archive/pg1c-11.5/) на Ubuntu 18.04.3 с ядром 5.0.0-25.

(220) > PG PRO 1C 11.5

я что то так и непонял с этим PG PRO 1C сейчас какая ситуация. Можно легально его использовать бесплатно?

(221)у постгрипро 4 варианта поставки, 2 из которых только за деньги.... оставшиеся 2 легально безплатно. Ну по крайней мере год назад было так

По итогу: бухгалтерия с...ся от радости, vheathenу премию, одинэсников на мороз. А если серьезно то у меня проекты намечаются на КА2, MS SQL в бюджетах ну совсем не заложен, так что спасибо автору и ветке за прояснение ситуации.

(221) Похоже, что всё-таки нельзя:

Лицензия Postgres Pro Standard
Portions Copyright (c) 2015-2019, Postgres Professional
Portions Copyright (c) 1996-2019, PostgreSQL Global Development Group
Portions Copyright (c) 1994 Regents of the University of California

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

===

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

Т.е. если не для тестирования, разработки и ознакомления с функциональностью и не в образовательном процессе, то нужна лицензия.

(216) я забыл одну важную детальку: если размер RAM-диска + объем, занятый процесами + текущий fs_cache  превышает размер оперативки, то все это дружно падает в своп в случайном порядке.

После запуска 1С объем fs_cache примерно равен объему базы на диске. Предположим, у тебя база 10G, тогда на диске занято 10G + fs_cache только под postgres еще 10G, а еще процессам где-то надо жить (в т.ч. тот же postgres).

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

Я первичную оценку текущей ситуации всегда делаю с помощью htop - в цветном виде лучше воспринимается, и видно на барах сколько fs_cache, а сколько настоящего.

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

(226) для виртуалок кстати здравое решение своп не выделять, поддерживаю
не хватает оперативки - нажми кнопку и увеличь

(222) раньше сборка для 1С бесплатна была доступна. Сейчас, выходит, что нет.

(220) на эту ссылку как вышел ?
http://repo.postgrespro.ru/1c-archive/pg1c-11.5/

(228) У них раньше этот репозиторий был доступен "бесплатно, без регистрации и смс" (с) прямо из Загрузок на сайте, из мастера выбора версии\ОС.

У меня был pg1c-10.5 прописан, я решил ради интереса посмотреть, что уровнем выше, нашёл более свежие сборки.

(224) годик назад их было 4, причём 2 бесплатных, один из которых вполне работал с 1С... видимо внутренняя конкуренция сборок убила его

(230) я не заглядывал раньше в лицензию, к сожалению, не знаю, что было сказано. Знаю об этих сборках давно, но что-то ленился посмотреть лицензию.

По сути, сейчас 5 вариантов: Pro Standard 1C (который собирается, но ссылки на него выпилены везде, похоже), Pro Standard, Enterprise и два последних варианта с сертификацией.