PostgreSQL в 16 раз медленнее MS SQL!!!

Форум Администрирование Настройка СУБД (DB)

1. Mihasya 48 17.10.24 02:12 Сейчас в теме

Добрый день.
Может кто хоть что-то подскажет...

Конфигурация номер раз:
Сервер MS SQL, установлен на 12 серваке винды, 72Гб оперативы, 12 ядер
и сервер 1С, установлен тоже на 12 винде, 64Гб оперативы и так же 12 ядер

Конфигурация номер два:
Сервер PostgreSQL 16 от 1С, установлен на Ubuntu 22.04, оперативы 256Гб, 14 ядер
и сервер 1С, установлен на Astra Linux Smolensk 1.74, оперативы 128Гб, 14 ядер

Обе конфигурации на витруалках.

Так вот какая беда, скорость перезаписи документов БольничныйЛист с ОбменДанными.Загрузка = Истина в конфигурации ЗУП 3.1 в PostgreSQL в 16-20 раз медленнее, чем в MS SQL!!!

Замеряем тупо, фиксируем время начала, обработкой перезаписываем например 200 документов, фиксируем время окончания и высчитываем скорость, N документов в секунду...
Так вот эта скорость в PSQL = 1,3-1,7 док/сек, а в MSSQL = ~26 док/сек

Причем ни какие настройки не помогают... что только не меняли, и рекомендованные конфиги от 1С из инета, игрались и с вакуумами и в wal-ами, все бесполезно, скорость записи БЛ неизменна, 1,3-1,7 док/сек (((
Даже ставили PostgreSQL (виндовый) на тот же сервер где и MSSQL установлен, скорость такая же...

PostgreSQL реально такой медленный или все-таки можно его разогнать? )))

Кстати, если кому не сложно, сделайте замеры у себя, какая у вас скорость записи БЛ (тестим скорость именно на БЛ, другие документы с другой скоростью пишутся, там PSQL тоже проигрывает, хоть и в меньшем соотношении) При записи БЛ никаких реквизитов не меняем, тупо:
ПолучитьОбъект();
ОбменДанными.Загрузка = Истина;
Записать(РежимЗаписиДокумента.Запись);

По теме из базы знаний

Ответы

Подписаться на ответы Инфостарт бот

Свернуть все

2. t278 58 17.10.24 03:12 Сейчас в теме

запросы в PSQL медленней, если "плохо" написаны. MSSQL лучше оптимизирует запросы.

3. Mihasya 48 17.10.24 03:52 Сейчас в теме

Я не отчет делаю с какой-то выборкой... Я делаю просто Записать()
причем ОбменДанными.Загрузка = Истина
по идее СУБД должна тупо писать данные в таблицы... так вот, я где-то читал что МС СКЛ чтоб сделать запись в таблицу, ее сначала ищет в этой таблице и после перезаписывает, а вот ПостгреСКЛ просто добавляет новую строчку в конец таблицы с новым номером транзакции и по логике ПостгреСКЛ должен отрабатывать быстрее, а по факту наоборот, еще в разы (((

7. user1880116 17.10.24 08:06 Сейчас в теме

(3)

ПостгреСКЛ просто добавляет новую строчку в конец таблицы с новым номером транзакции и по логике ПостгреСКЛ должен

А на индексы он просто забивает, ага.

10. user2107184 17.10.24 09:18 Сейчас в теме

(3) ...

11. user2107184 17.10.24 09:21 Сейчас в теме

(3)

причем ОбменДанными.Загрузка = Истина

Да ему фиолетово на твои "ОбменДанными.Загрузка"

Прикрепленные файлы:

4. user2107184 17.10.24 07:11 Сейчас в теме

А на сколько дешевле - не производили замеры?

5. MACTEP1C 17.10.24 07:54 Сейчас в теме

Корректно ли вообще сравнивать изначально коммерческие продукты, над которыми трудились большие команды разработчиков с конкретной целью сделать их продаваемыми, и системы с открытым кодом, созданные энтузиастами ради интереса?

6. user1880116 17.10.24 08:03 Сейчас в теме

(5)

созданные энтузиастами ради интереса?

Толсто. Иди готовься дальше.

8. Mihasya 48 17.10.24 08:09 Сейчас в теме

сейчас прописали в конфиг вот это:

shared_preload_libraries = 'auto_explain'
auto_explain.log_min_duration = '3s'
auto_explain.log_analyze = true
auto_explain.log_buffers = true

в итоге получился лог файл с планами запросов, при просмотре этого файла мы поняли, что при конструкции ПолучитьОбъект() формируется запрос к таблице документа (для получения реквизитов) + еще столько запросов, сколько у документа ТЧ, в итоге для получения данных одного документа БЛ формируется 26 запросов... на текущий момент в базе около 19 000 документов БЛ, причем к ТЧ таким как Начисления или СреднийЗаработокФСС время запроса составляет более 0.5 секунды... (количество записей таблицы Начисления около 40 000, а СреднийЗаработокФСС около 320 000)

вот например запрос к ТЧ Начисления

2024-10-17 03:06:35.873 UTC [221896] LOG: duration: 710.402 ms plan:
Query Text: SEL ECT
T2._LineNo1046,
T2._Fld1047RRef,
T2._Fld1048,
T2._Fld1049,
T2._Fld1050RRef,
T2._Fld1051,
T2._Fld1052,
T2._Fld1053RRef,
T2._Fld1054,
T2._Fld1055,
T2._Fld1056RRef,
T2._Fld1057,
T2._Fld1058RRef,
T2._Fld1059,
T2._Fld1060,
T2._Fld1061_TYPE,
T2._Fld1061_RTRef,
T2._Fld1061_RRRef,
T2._Fld1062RRef,
T2._Fld1063,
T2._Fld1064,
T2._Fld1065,
T2._Fld1066,
T2._Fld1067,
T2._Fld27615,
T2._Fld1068_TYPE,
T2._Fld1068_RTRef,
T2._Fld1068_RRRef,
T2._Fld1069,
T2._Fld1070RRef,
T2._Fld1071,
T2._Fld1072,
T2._Fld1073,
T2._Fld1074,
T2._Fld1075_TYPE,
T2._Fld1075_RTRef,
T2._Fld1075_RRRef,
T2._Fld1076,
T2._Fld1077RRef,
T2._Fld1078,
T2._Fld32601,
T2._Fld33380_TYPE,
T2._Fld33380_RTRef,
T2._Fld33380_RRRef,
T2._Fld34299,
T2._Fld34300,
T2._Fld34301,
T2._Fld36319_TYPE,
T2._Fld36319_RTRef,
T2._Fld36319_RRRef,
T2._Fld38111,
T2._Fld39074,
T2._Fld39075,
T2._Fld39076RRef,
T2._Fld39077RRef,
0 AS SDBL_IDENTITY
FR OM _Document304_VT1045 T2
INNER JOIN _Document304 T3
ON T3._Fld815 = T2._Fld815 AND T3._IDRRef = T2._Document304_IDRRef
WHERE (T2._Document304_IDRRef = '\\207!\\000PV\\235P\\330\\021\\356\\254"\\230\\244p\\311'::bytea) AND T2._Fld815 = CAST(0 AS NUMERIC)
ORDER BY 56 ASC, T2._LineNo1046
Sort (cost=6620.48..6620.49 rows=2 width=404) (actual time=710.372..710.374 rows=1 loops=1)
Sort Key: t2._lineno1046
Sort Method: quicksort Memory: 25kB
Buffers: shared hit=3560 read=2383
-> Nested Loop (cost=0.00..6620.48 rows=2 width=404) (actual time=88.213..710.347 rows=1 loops=1)
Buffers: shared hit=3557 read=2383
-> Seq Scan on _document304 t3 (cost=0.00..3782.86 rows=1 width=20) (actual time=4.774..25.275 rows=1 loops=1)
Filter: ((_fld815 = '0'::numeric) AND (_idrref = '\\x87210050569d50d811eeac2298a470c9'::bytea))
Rows Removed by Filter: 18821
Buffers: shared hit=3557
-> Seq Scan on _document304_vt1045 t2 (cost=0.00..2837.60 rows=2 width=420) (actual time=83.432..685.061 rows=1 loops=1)
Filter: ((_fld815 = '0'::numeric) AND (_document304_idrref = '\\x87210050569d50d811eeac2298a470c9'::bytea))
Rows Removed by Filter: 37882
Buffers: shared read=2383

9. paulwist 17.10.24 09:10 Сейчас в теме

(8)

вот например запрос к ТЧ Начисления

Хех, что вы хотите, у табличек отсутствуют индексы/статистики.

1. В табличке _document304_vt1045 сканируется 37882 записей за 685 млсек, выбирается только одна.
2. В табличке _Document304 сканируется 18821 записей за 25 млсек, выбирается только одна
3. Затем происходит NL 2-х записей, бесплатно :)
4. В итоге получаете 0.71 сек на запрос.

Нужно создать индексы, через конфигуратор.

Не видя данных, пальцем в небо

CRE ATE   INDEX CONCURRENTLY "~_document304_vt1045-3b9265a5"
  ON _document304_vt1045(
    _fld815
  , _document304_idrref
  );

CRE ATE   INDEX CONCURRENTLY "~_document304-4427d119"
  ON _document304(
    _fld815
  , _idrref
  );

12. user1880116 17.10.24 09:25 Сейчас в теме

(9)

Нужно создать индексы, через конфигуратор.

Это трассировка выполнения ПолучитьОбъект. Какие ты там индексы из конфигуратора создашь? Видно же что он ищет по разделителю и ссылке.

22. paulwist 18.10.24 14:59 Сейчас в теме

(12)

Это трассировка выполнения ПолучитьОбъект. Какие ты там индексы из конфигуратора создашь? Видно же что он ищет по разделителю и ссылке.

Нууу, отсутствующие индексы :)

starik-2005 дал ответ как создать такие индексы через ТиИ :)

13. starik-2005 3088 17.10.24 10:04 Сейчас в теме

(8)

Seq Scan

https://habr.com/ru/articles/276973/

Это самая простая операция из всех возможных – PostgreSQL открывает файл с таблицей, читает строки одну за другой и возвращает их пользователю или расположенному выше узлу дерева explain, например, LIMIT, как здесь:

О чем это говорит? О том, что у постгреса нет индекса по разделителю + ссылке. В итоге постгрес читает всю таблицу. Это явно косяк или 1С, или тех, кто разворачивал базу.

Отсюда очевидное решение вопроса - реструктуризация. Заходите в конфигуратор, нажимаете ТиИ, выбираете реструктуризация, идете спать. Утром все будет зебест.

14. user1880116 17.10.24 10:27 Сейчас в теме

(13)

у постгреса нет индекса по разделителю + ссылке

Он, кстати, ЕМНИП, кластерный вообще.

Так что к разворачивателям баз вопросы, да.

15. starik-2005 3088 17.10.24 10:39 Сейчас в теме

(14)

кластерный

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

https://postgrespro.ru/docs/postgresql/15/sql-cluster

В результате кластеризации таблицы её содержимое физически переупорядочивается в зависимости от индекса. Кластеризация является одноразовой операцией: последующие изменения в таблице нарушают порядок кластеризации. Другими словами, система не пытается автоматически сохранять порядок новых или изменённых строк в соответствии с индексом. (Если такое желание возникает, можно периодически повторять кластеризацию, выполняя команду снова. Кроме того, если для заданной таблицы установить параметр FILLFACTOR меньше 100%, это может помочь сохранить порядок кластеризации при изменениях, так как изменяемые строки будут помещаться в ту же страницу, если в ней достаточно места.)

ЗЫЗЫ: 1С создает отдельный индекс для "имитации" кластерного, но его почему-то нет. Реструктуризация помогает.

16. Mihasya 48 17.10.24 11:10 Сейчас в теме

(13) Вот спасибо, ща запущу реструктуризацию ))
Завтра отпишусь...

17. Mihasya 48 18.10.24 05:18 Сейчас в теме

starik-2005, и всем участвовавшим, ОГРОМНОЕ ВАМ СПАСИБО!!! )))
Результаты таковы, после реструктуризации скорость обработки возросла более чем в 25 раз!!!

Так было вчера:
17.10.2024 13:21:59
По филиалу ФРС всего обработано 177 документов БольничныйЛист (Скорость обработки 1,28 док./сек., время отбработки 137,986 сек.)

Так было сегодня, до реструктуризации:
18.10.2024 10:50:42
По филиалу ФРС всего обработано 177 документов БольничныйЛист (Скорость обработки 1,56 док./сек., время отбработки 113,539 сек.)

А это после реструктуризации:
18.10.2024 12:59:17
По филиалу ФРС всего обработано 177 документов БольничныйЛист (Скорость обработки 40,02 док./сек., время отбработки 4,423 сек.)

18.10.2024 13:12:29
По филиалу ФРС всего обработано 177 документов БольничныйЛист (Скорость обработки 36,71 док./сек., время отбработки 4,822 сек.)

18.10.2024 13:12:45
По филиалу ФРС всего обработано 158 документов БольничныйЛист (Скорость обработки 34,92 док./сек., время отбработки 4,524 сек.)

18.10.2024 13:13:11
По филиалу ФРС всего обработано 257 документов БольничныйЛист (Скорость обработки 37,79 док./сек., время отбработки 6,801 сек.)

Только если можно еще такой вопрос, нужно ли в последствии делать эту реструктуризацию?
Или сейчас сделал, она индексов насоздавала и потом их всегда поддерживает?

20. starik-2005 3088 18.10.24 13:29 Сейчас в теме

(17)

Или сейчас сделал, она индексов насоздавала и потом их всегда поддерживает?

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

Наймите себе приличного ДБА - и будет счастье. Если у него не будет сертификата от постгреса, то отправьте его получить такой сертификат. 99% возможных проблем это закроет.

18. Mihasya 48 18.10.24 05:28 Сейчас в теме

(8) Поправочка (может кому пригодится)

вот тут:
auto_explain.log_min_duration = '3s'

при анализе не 3s ставили, а 0, иначе планы не показало бы, т.к. показывает те что выполняются длительнее

19. Mihasya 48 18.10.24 05:57 Сейчас в теме

И вот лог плана запроса к той же ТЧ Начисления

2024-10-18 02:37:37.284 UTC [6166] СООБЩЕНИЕ: duration: 0.105 ms plan:
Query Text: SEL ECT
T2._LineNo1046,
T2._Fld1047RRef,
T2._Fld1048,
T2._Fld1049,
T2._Fld1050RRef,
T2._Fld1051,
T2._Fld1052,
T2._Fld1053RRef,
T2._Fld1054,
T2._Fld1055,
T2._Fld1056RRef,
T2._Fld1057,
T2._Fld1058RRef,
T2._Fld1059,
T2._Fld1060,
T2._Fld1061_TYPE,
T2._Fld1061_RTRef,
T2._Fld1061_RRRef,
T2._Fld1062RRef,
T2._Fld1063,
T2._Fld1064,
T2._Fld1065,
T2._Fld1066,
T2._Fld1067,
T2._Fld27615,
T2._Fld1068_TYPE,
T2._Fld1068_RTRef,
T2._Fld1068_RRRef,
T2._Fld1069,
T2._Fld1070RRef,
T2._Fld1071,
T2._Fld1072,
T2._Fld1073,
T2._Fld1074,
T2._Fld1075_TYPE,
T2._Fld1075_RTRef,
T2._Fld1075_RRRef,
T2._Fld1076,
T2._Fld1077RRef,
T2._Fld1078,
T2._Fld32601,
T2._Fld33380_TYPE,
T2._Fld33380_RTRef,
T2._Fld33380_RRRef,
T2._Fld34299,
T2._Fld34300,
T2._Fld34301,
T2._Fld36319_TYPE,
T2._Fld36319_RTRef,
T2._Fld36319_RRRef,
T2._Fld38111,
T2._Fld39074,
T2._Fld39075,
T2._Fld39076RRef,
T2._Fld39077RRef,
0 AS SDBL_IDENTITY
FR OM _Document304_VT1045 T2
INNER JOIN _Document304 T3
ON T3._Fld815 = T2._Fld815 AND T3._IDRRef = T2._Document304_IDRRef
WHERE (T2._Document304_IDRRef = '\\207!\\000PV\\235P\\330\\021\\356\\254\\0348\\261\\265V'::bytea) AND T2._Fld815 = CAST(0 AS NUMERIC)
ORDER BY 56 ASC, T2._LineNo1046
Sort (cost=5.24..5.24 rows=2 width=404) (actual time=0.095..0.096 rows=1 loops=1)
Sort Key: t2._lineno1046
Sort Method: quicksort Memory: 25kB
Buffers: shared hit=6 read=5
-> Nested Loop (cost=0.28..5.23 rows=2 width=404) (actual time=0.080..0.081 rows=1 loops=1)
Buffers: shared hit=3 read=5
-> Index Only Scan using _document304_s_hpk on _document304 t3 (cost=0.12..2.33 rows=1 width=20) (actual time=0.036..0.037 rows=1 loops=1)
Index Cond: ((_fld815 = '0'::numeric) AND (_idrref = '\\x87210050569d50d811eeac1c38b1b556'::bytea))
Heap Fetches: 1
Buffers: shared hit=3 read=1
-> Index Scan using _document304_vt1045_sk on _document304_vt1045 t2 (cost=0.17..2.88 rows=2 width=420) (actual time=0.040..0.041 rows=1 loops=1)
Index Cond: ((_fld815 = '0'::numeric) AND (_document304_idrref = '\\x87210050569d50d811eeac1c38b1b556'::bytea))
Buffers: shared read=4

21. starik-2005 3088 18.10.24 13:44 Сейчас в теме

(19)

duration: 0.105 ms plan

В 7 000 раз быстрее. Так и должно быть.

23. Mihasya 48 19.10.24 08:29 Сейчас в теме

Еще раз, ОГРОМНОЕ СПАСИБО!!! Я даже начинаю любить постгрес )))

Оставьте свое сообщение

E-mail: