Вход | Регистрация
    1  2  3   
1С:Предприятие :: 1С:Предприятие 8 общая

КА2, Postgresql и дикие тормоза при проведении регламентных документов

КА2, Postgresql и дикие тормоза при проведении регламентных документов
Я
   vheathen
 
15.08.19 - 12:25
Приветствую!

Коллеги, есть у моего заказчика проблема, которую подрядчики, занимающиеся 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, давно и успешно.

В какую стороную мне копать, подскажите, пожалуйста?
 
 
   piter3
 
1 - 15.08.19 - 12:30
от 3 до 8 что много?
   vheathen
 
2 - 15.08.19 - 12:40
(1) На 1 (один) документ - очень.
   piter3
 
3 - 15.08.19 - 12:42
(2) А позвольте узнать,что за документ?
   НадюшаЯ
 
4 - 15.08.19 - 12:47
(3) Расчет себестоимости)
   vheathen
 
5 - 15.08.19 - 12:47
(3) Бухгалтер говорит, что при любых регламентных: отражение Дт/Кт, операции вручную и т.д.

Вот пример, когда прислали скрин - прошло 4 минуты после нажатия даже не на Провести, а на Сохранить: https://habrastorage.org/webt/z1/d1/yk/z1d1ykrwmz4ljtychpgm0zpjejy.jpeg
   Фрэнки
 
6 - 15.08.19 - 12:48
да любой регламентный при закрытии месяца, вероятно
   Фрэнки
 
7 - 15.08.19 - 12:48
(5) А когда проблема возникла?
   piter3
 
8 - 15.08.19 - 12:49
(5) А подрядчики не додумались сделать замер производительности?Хотелось бы взглянуть,хотя операция намекает на кривые руки буха,как версия
   Фрэнки
 
9 - 15.08.19 - 12:52
(8) скорей всего, что не будут думать на буха - у них же есть копия в мс скл и там таких тормозов не наблюдается - тут что-то другое
   Фрэнки
 
10 - 15.08.19 - 12:53
8.3.13.1644    28.11.18 - как бы не самый свежий релиз платформы, а потому интересна причина выбора именно этого релиза.
   vheathen
 
11 - 15.08.19 - 12:53
(7) проблема возникла в конце июня неожиданно. Но похоже, неожиданно из-за того, что с начала года перешли на новую конфигурацию (как раз на КА2), но регламентными документами не пользовались в ней, сначала занимались управленческим учётом. А вот добрались до бухгалтерии - и начались сложности.
   HeKrendel
 
12 - 15.08.19 - 12:54
Сдается мне что криво настроен Постгресс
   vheathen
 
13 - 15.08.19 - 12:54
(8) а как могут влиять кривые руки буха на то, что постгрес чем-то там занят своим это время? я же отслеживал это в реальном времени, смотрел и общую загрузку, и pg_top.
   piter3
 
14 - 15.08.19 - 12:54
Или ввод остатков или рлс или конф.файлы кривые.
   piter3
 
15 - 15.08.19 - 12:55
(13) Замер производительности нужен,я так начинаю смотреть,не знаю как другие делают
   Фрэнки
 
16 - 15.08.19 - 12:57
(11) просто элементарное получение проводок и расчет себестоимости ( как в (4) вспомнили ) должны были раньше спровоцировать.
   Фрэнки
 
17 - 15.08.19 - 12:59
(13) А вот интересно, кроме КА 2 на этом сервере другой базы для этой платформы больше нет?
Может там ЗУП есть и в нем тормозит не так заметно, например.
   vheathen
 
18 - 15.08.19 - 13:04
(12) конфиг постгреса тут: https://pastebin.com/YaZ6msEd
на машину выделено 26 ядер сейчас, 32GB памяти, если не ошибаюсь. База сама - 4.5GB.

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

(17) до этого была КА1.1, там таких проблем не было.
   Фрэнки
 
19 - 15.08.19 - 13:06
Я бы для проверки предположений, раз уже упомянули о наличии виртуальных машин, попробовал бы на виндусовой виртуалке установить постгри и посмотреть, как там оно будет работать.

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

И да, на старых платформах проблемы не возникали, а только на более-менее новых типовых.
   Фрэнки
 
20 - 15.08.19 - 13:08
* на старых релизах конфигураций типовых. - Под них подходила любая платформа - а вот под более-менее новые типовые : приходилось подменять платформу.
   piter3
 
21 - 15.08.19 - 13:10
Черт,а может итоги
   vheathen
 
22 - 15.08.19 - 13:11
(15) а чем именно вы пользуетесь, подскажите, пожалуйста? Гилёв или что-то другое?

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

(19) Спасибо, интересная мысль, попробую.
   Провинциальный 1сник
 
23 - 15.08.19 - 13:12
Попробуйте enable_nestloop=off - радикальное средство. Дикие тормоза исчезнут, но не факт что при этом что-то другое не замедлится слегка.
   piter3
 
24 - 15.08.19 - 13:12
   Фрэнки
 
25 - 15.08.19 - 13:12
(21) угу. что-нибудь похожее, но не просто так, а в запущенном сеансе для фонового задания с получением болкировочек... что-то из тех проблем.
   vheathen
 
26 - 15.08.19 - 13:15
(23) если мне память не изменяет, я пробовал. Не помогло, увы.
   Фрэнки
 
27 - 15.08.19 - 13:17
(26) но тексту из ссылки в (18) видно, что настройка enable_nestloop сейчас стоит дефолтная и включенная скорей всего
   bolero
 
28 - 15.08.19 - 13:18
(18) аха! виртуалка! щас прибежит H A D G E H O G s и расскажет, какие вы хипсторы

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


Ну и классический вопрос - VACUUM; ANALYZE; по крону делается?
   vheathen
 
29 - 15.08.19 - 13:36
(27) да, сейчас nested loops включены. я ещё раз попробую выключить и посмотреть, что там. проблема в том, что все пока переехали на тестовый ms sql, и сервер тоже перенесли туда, соответственно, лицензии на linux'овом сервере протухли.

(28) да, делаются, еженочно. насчёт виртуалок: у заказчика нет своего железа совсем, вычислительные мощности арендуются в облаке.
   Йохохо
 
30 - 15.08.19 - 13:53
возьмите налички на админа и бухгалтера, и на марине вам теперь надо жениться, конечно если вы не архипов, кто ее такую возьмет
 
 Рекламное место пустует
   vvp91
 
31 - 15.08.19 - 14:43
Наверное, исходя из твоих данных, можно попробовать так

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).

И я бы еще выключил оналайн анализис в принципе.
   edwin
 
32 - 15.08.19 - 14:46
(0) postgresql 10.7.1 от postgres pro проблемма скорее всего в этом, нужен или Postgres Pro Standard или Postgres Pro Enterprise, они за деньги, или дистибутив от 1с, или старые дистибутивы от Postgres Pro, например 9.6 или 9.4.
   vheathen
 
33 - 15.08.19 - 14:49
(31) fsync я выключать совсем не хочу, как-то опасненько. sync*_commit выключал - не меняется ничего. Временные файлы статистики уже в память положил, да. Остальные параметры поменять попробую, спасибо; хотя shared buffers не велики? Их, вроде, не больше четверти доступной памяти рекомендуют? Там просто на этой же машине и сервер 1С крутится, так что я расчитывал исходя из 20-25ГБ памяти для postgres.
   vvp91
 
34 - 15.08.19 - 14:50
(32) что за лажа? причем тут платно-бесплатно?

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

Ну и в самой КА2/ЕРП2 есть проблемы по оптимизации отражения регламентных операций.
Тормозить и MSSQL, когда база начнет эксплуатироваться группой людей.
   edwin
 
35 - 15.08.19 - 14:51
(34) Потому что патчей в бесплатной сборке от Postgres Pro нет в новых релизах
   vvp91
 
36 - 15.08.19 - 14:52
(33) Временные файлы проверь, что они точно в оперативке.
Шаредбуфферс увеличивай.
ЭффективКешСайз увеличивай.
   vvp91
 
37 - 15.08.19 - 14:54
(35) Это ты мне эти сказки рассказываешь? Или всем остальным?
   edwin
 
38 - 15.08.19 - 14:57
(37) Это факт, бесплатные сборки от Postgres Pro не поддерживают 1с, зайди на сайт глянь, раньше на странице "СУБД для работы платформы 1С:Предприятие" была в том числе бесплатная сборка, сейчас нет.
   vvp91
 
39 - 15.08.19 - 14:58
(33) Ну и еще, поставь логгирование длительных операций, секунд на 30 для начала.
log_min_duration_statement = 30000

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

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

Может у тебя долго чекпойнты идут, тогда надо их растянуть или с валом поиграться.
   Фрэнки
 
40 - 15.08.19 - 14:58
(37) загляни в список совместимых http://v8.1c.ru/requirements/

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

Внимание! Текущая версия PostgreSQL предназначена для использования с версией технологической платформы 1С:Предприятие 8 не ниже 8.3.14.1565.
   edwin
 
41 - 15.08.19 - 15:01
Свежие бесплатные сборки от Postgres Pro вообще не пропатчены под 1с, смысл там возиться, ставить либо старую либо сборку от 1с.
   vvp91
 
42 - 15.08.19 - 15:02
(40) Да, такое написано в требованиях.
И чего?

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

Платформы 8.3 можно любые на пг10 эксплуатировать. Проблем не будет.
   vheathen
 
43 - 15.08.19 - 15:56
(38) http://repo.postgrespro.ru/1c-archive/

Думаю, 1с в названии должно говорить само за себя.
   edwin
 
44 - 15.08.19 - 16:28
(43) Я имел ввиду это: http://repo.postgrespro.ru/pgpro-10/ бесплатные сборки от Postgres Pro
   edwin
 
45 - 15.08.19 - 16:33
Попробуй отсюда сборку http://repo.postgrespro.ru/pgpro-9.6/
   vheathen
 
46 - 15.08.19 - 18:38
(24) спасибо, сделал предложенное. более 99% времени (407 секунд) - это строка Результат = Форма.Записать(ПараметрыЗаписи); Беда в том, что мне это ни о чём не говорит.

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

И вот теперь самое главное, что я подозревал, но никак объяснить не могу. Я перенёс базу на ram-диск целиком. Не поменялось вообще ничего. Любой update по-прежнему 5 секунд и выше.
   rphosts
 
47 - 15.08.19 - 18:50
(0) проведение документа операция из 3 проводок - ЖЕСТЬ!!!
Но, вы хотели вопросов - их есть у меня!
У вас там зеркало не настроено в постгри случаем?
"Вакуум анализе" делаете регулярно?
Показали-бы целиком конф-файл постгри, а?
Кроме 1С в базах постгри кто сидит?
Если антивиры/брэндмауэры отрубить ничего не изменится?
Если срубить все сеансы всех 1С, рестартануть сервер 1С и залезть в базу единственным сеансом - скорость не изменится?
Точно никакой веб-публикации нет?

Для начала хватит
   vvp91
 
48 - 15.08.19 - 19:00
(46) Это таблица итогов по 2-му субконто бухгалтерских счетов.

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

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

Скорее всего тебе нужно "Установить период рассчитанных итогов".
   rphosts
 
49 - 15.08.19 - 19:05
(48) да ну нафиг!!! Граница-же во всех типовых регламентно сдвигается! Неужели у кого-то "хватило мозгов" отключить!!!
   vvp91
 
50 - 15.08.19 - 19:09
(49) Я думаю, что там распределение РБП за длительный период.
Но проверить итоги стоит.
   rphosts
 
51 - 15.08.19 - 19:11
(50) так РБП отдельным-же документом а не на подписки повешено! Хотя я и не такой изврат видел
   rphosts
 
52 - 15.08.19 - 19:15
вообще ЖР + ТЖ наше всё!
   palsergeich
 
53 - 15.08.19 - 19:21
(46) Отладка на сервере работает?
Обычно после Форма.Записать идут истинные виновники
   palsergeich
 
54 - 15.08.19 - 19:21
(53) Но нужен ТЖ, без него никак
   vvp91
 
55 - 15.08.19 - 19:28
(51) Так вот он и пишет в своем топике: "Проведение одного регламентного документа может занимать несколько минут (от 3 до 8!!!)"

Т.е. бухгалтер проводит документ Распределение РБП. А там, небось, за 20 лет РБП.
   vheathen
 
56 - 15.08.19 - 19:53
(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С.
   vheathen
 
57 - 15.08.19 - 20:00
А, и к предыдущему. Любой из запросов, которые в логах длятся по 5+ секунд при выполнии его с explain analyze вручную в psql выполняются 1.5 мс максимум, план выполнения тоже вполне себе быстрый строится.
   vheathen
 
58 - 15.08.19 - 20:03
(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>

Насколько я понимаю, вообще всё должно в логи литься с таким конфигом?
   Фрэнки
 
59 - 15.08.19 - 20:56
Вообще, я бы ее попробовал из готовой вируталки-вндовз с 1С подцепить виртуалку-линукс постгри - т.е. получится полная трехзвенка - но станет полностью понятно, хотя это и сейчас понятно, что тормоза не в исполнении запроса.

Мое мнение, я выше озвучивал уже, что это торомозит платформа, т.е. агент-сервера.
   vheathen
 
60 - 15.08.19 - 21:15
(59) попробовал подцепить через виндовый сервер 1С к линуксовому постргесу - никаких изменений. Время выполнения каждого запроса точно такое же. Попробую сейчас найти новую версию платформы и обновить.
   Фрэнки
 
61 - 15.08.19 - 21:40
(60) в настройках кластера можно еще параметры настроить. Недавно обсуждалось, но не о проблемах постгри как такового, а настройку кластера серверов. Там есть параметры и есть описание к оптимальным настройкам.
   vheathen
 
62 - 15.08.19 - 21:49
(61) смена платформы на 8.3.15.1565 ничего не изменила. Блин.

А у вас не осталось, случайно, ссылочки на обсуждение?
   edwin
 
63 - 15.08.19 - 22:03
(62) разверни постгрес 9.6
   vheathen
 
64 - 15.08.19 - 22:12
(63) как раз развернул, сейчас базу импортирую
   Фрэнки
 
65 - 15.08.19 - 22:22
вот было в августе
---
  Arh01
68 - 02.08.19 - 14:23
Попробую здесь спросить.
У нас КА2, платформа 8.3.13, PostgreSQL 9.6.
Включен RLS.
У кого полные права - с производительностью все ОК.
У кого права ограничены - заметны подтормаживания.
Что стоит проапгрейдить для повышения скорости работы - PostgreSQL и(или) платформу?
И на какие версии?
   vheathen
 
66 - 15.08.19 - 22:27
(63) не помогло вообще. всё те же 5+ секунд на 1 UPDATE, что в сумме даёт те же 400+ секунд на всю операцию.

Мне совершенно не нравится то, что время совершенно одинаковое на всех версиях платформы и БД. Т.е. косяк какой-то базовый. Но это я подсунул конфиг от предыдущего pg. сейчас попробую сделать на базе родного.
 
 Рекламное место пустует
   Фрэнки
 
67 - 15.08.19 - 22:31
   Фрэнки
 
68 - 15.08.19 - 22:34
   ansh15
 
69 - 15.08.19 - 22:48
(40) >>PostgreSQL, версия 10.8-13.1C
Не надо ее ставить. На ней, в зарплате(для ГУ), при вводе/пересчете больничного могла возникать ошибка СУБД. Это быстро поправили в тестовой 10.8-17.1C. Наверное, скоро сделают актуальной. Может быть и еще что-нибудь исправили в своих патчах.
   vheathen
 
70 - 15.08.19 - 23:10
В общем, родной конфиг не помог. Отключение RLS (если я правильно отключил) тоже ничего не изменило.
   edwin
 
71 - 15.08.19 - 23:15
Становиться интересно!)
Сюда есть доступ: https://its.1c.ru/db/metod8dev#content:4692:hdoc ?
   vheathen
 
72 - 15.08.19 - 23:16
(71) увы, нет.
   edwin
 
73 - 15.08.19 - 23:17
Решение проблемы с зависанием 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
   vheathen
 
74 - 15.08.19 - 23:26
(73) эти настройки тоже не влияют на результат &#55358;&#56631;‍♂️
   edwin
 
75 - 15.08.19 - 23:28
(74)  Даже если так seq_page_cost = random_page_cost = 0.1?
   vheathen
 
76 - 15.08.19 - 23:33
(75) и даже так, да. какая-то фантастика.
   edwin
 
77 - 16.08.19 - 00:00
(76) Есть еще след. статья: https://kb.1c.ru/articleView.jsp?id=91
   edwin
 
78 - 16.08.19 - 00:05
Общие положения

В статье описывается настройка 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 = 150256

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

 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

 Минимальный интервал обновления для одной таблицы.
   ansh15
 
79 - 16.08.19 - 00:38
О модели процессора еще никто не спрашивал? И о режиме высокой производительности на железном сервере?
   H A D G E H O G s
 
80 - 16.08.19 - 00:43
(78) Сколько много непонятной хрени. Используйте СУБД здорового человека.
   edwin
 
81 - 16.08.19 - 00:54
(80) Я считаю просто: если ты в 2019 году не используешь СПО значит ты совсем замшелый.
   H A D G E H O G s
 
82 - 16.08.19 - 01:25
(81) СПО, linux, Postgree - вот это все для гиков и занятных экспериментов.
Когда вы мне покажите 1С от 1000 активных пользователях в одной базе, работающих под Postgree/Linux под вашу ответственность - вернемся к этому разговору.
   Sysanin_1ц
 
83 - 16.08.19 - 01:37
Конечно о замшелости Комплексной автоматизации можно писать тома. Наверняка еще больше можно про ЕРП написать. У меня в КА2 такая же беда с длительным проведением обычных документов (не регламентных) тоже была. Сначала перешел с файловой на Постгрес. Немного помогло, но не очень. Особенно тормоза были при любых операциях в общих журналах. Дату отбора в журнале поменял, жду 3 минуты, фильтрую документы жду три минуты, сортировка - 3 минуты, проведение 3 минуты. Каково же мое удивление было когда я убрал из формы журналов реквизиты с вызовом через точку от ссылки. Все стало после этого работать намного быстрее !!!!! Видать не любит 1с тянуть в журналы запросы с соединением. Смешно что при этом тормозил не только журнал но и любые операции с документов из этого журнала !!!!
   palsergeich
 
84 - 16.08.19 - 01:44
(83) ты текст исполняемого запроса видел?
Что то мне говорит что благодаря тем самым через точку там спагетти из leftjoin
   Sysanin_1ц
 
85 - 16.08.19 - 01:46
(84) Ну я и говорю что 1с, либо постгрес не любит joinы
   palsergeich
 
86 - 16.08.19 - 01:57
(85) да там боюсь и мсскл сказал бы кря
   rphosts
 
87 - 16.08.19 - 03:09
(84) что-то мне подсказывает что тами порноRLS.
(0) под пользователем со всеми установленными галочками прав (вообще все существующие роли) скорость тоже не торт?
   rphosts
 
88 - 16.08.19 - 03:46
(85) 3 проводки - 5 секунд? Там не джоины крайние полюбому.
   vheathen
 
89 - 16.08.19 - 07:25
(79) Xeon E5-2665. Ядер там хоть одним местом жуй. Режим производительности включён.

(78) Именно к этой статье доступа у меня нет, но я видел либо перепечатки, либо подобные, и все эти параметры уже оптимизированы, само собой. Да и с Postgres я не первый день знаком. У меня поэтому и недоумение в данной связке.
И меня очень смущает, что любой UPDATE выполняется именно 5-5.5 секунд, не больше, не меньше, вне зависимости от того, где находится база - на диске хранилища или на диске в памяти, вне зависимости от настроек планировщика.
   rphosts
 
90 - 16.08.19 - 07:37
(89)длина очереди диска сколько?
   vheathen
 
91 - 16.08.19 - 07:38
(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))

Я вообще не понимаю, что тут может выполняться так долго.
   vheathen
 
92 - 16.08.19 - 07:41
(90) Очередь пустая. Полностью. Я же говорю, я сейчас базу данных положил на RAM-диск. Вообще ничего не поменялось. Такое ощущение, что какие-то таймауты. Но какие?
   rphosts
 
93 - 16.08.19 - 07:41
(91) граница рассчитанных итогов показывает какое число?
   rphosts
 
94 - 16.08.19 - 07:42
(92) у вас типовая КА или перепиленная?
   rphosts
 
95 - 16.08.19 - 07:52
если в 1С становить галочку разделения итогов - ничего не поменяется?
   vheathen
 
96 - 16.08.19 - 07:52
(93) Подскажите, пожалуйста, где посмотреть, чтобы я нужное назвал?
Насколько я знаю, конфигурация типовая.
   Провинциальный 1сник
 
97 - 16.08.19 - 07:57
(91) Запрос у тебя в руках - что мешает запустить с анализом плана и посмотреть "что тут может выполняться так долго"?
   vheathen
 
98 - 16.08.19 - 07:59
(97) я выше писал: вручную этот же запрос выполняется 1.4 мс.
   piter3
 
99 - 16.08.19 - 08:00
(98) параметры разные
   vheathen
 
100 - 16.08.19 - 08:00
(97) вот тут писал: (57)
  1  2  3   

Список тем форума
Рекламное место пустует  Рекламное место пустует
ВНИМАНИЕ! Если вы потеряли окно ввода сообщения, нажмите Ctrl-F5 или Ctrl-R или кнопку "Обновить" в браузере.