Имя: Пароль:
1C
1С v8
8.3 и Postgres
0 mobi
 
27.12.14
08:36
Когда-то давным давно, при переводе 8.1 на постгрес существовала проблема блокировок при проведении, надо было переписывать процедуру проведения и переключать режим блокировок для большого количества работающих пользователей. Теперь собсно говоря вопрос, как с этим обстоят дела в 8.2 и 8.3 в гугле полно статей на эту тему, но они или старые, или переписанный копипаст старых статей. Мне интересно, эта проблема осталась, или 1с-неги по привычке кричат, что постгрес не тру? Хотелось бы выслушать мнение людей, которые действительно работали с подобной связкой, а не имхо предвзятых виндоузятников, для которых постгрес бяка по умолчанию, патамушта Линукс.
1 Escander
 
27.12.14
08:45
>Когда-то давным давно, при переводе 8.1 на постгрес существовала проблема блокировок при проведении, надо было переписывать процедуру проведения и переключать режим блокировок для большого количества работающих пользователей.

В 1С следует курить управляемые блокировки - это даже не обсуждается. И дело уж точно не в постгри.
2 ilpar
 
27.12.14
09:04
Кто-то недавно написал, что некорректно nested loops обрабатывает и тупит. А в старых конфигурациях вложенных запросов еще порядком.
3 ilpar
 
27.12.14
09:23
управляемые блокировки в свежей УПП навскидку присутствуют, но кажется это не решит проблему.
4 Фрэнки
 
27.12.14
10:13
У нас серверами и выбором серверного софта занимаются админы. Много лет на сервере установлена линуксовая версия в связке с постгри.
Не совсем в курсе нюансов, а где-то есть хорошее и внятно описание проблем с эксплуатацией 1С на постгри ?
5 mobi
 
27.12.14
11:14
(4) По сети гуляют старые описания для 8.1 или копипаст из старых. Имхану конечно, но эти статьи сформировали негативное отношение к такой связке у 1с-негов, когда начинаешь спрашивать все трындят про блокировки, хотя если копать первоисточники подобного мнения, упираешься опять же в эти старые статьи. Интересует, как обстоят дела сейчас.
6 ilpar
 
27.12.14
12:34
Как то юзали постгрес на автоматических блокировках с небольшой модификацией по источникам из инета - тормоза при перепроведении задним числом (30 сек.-2 мин вместо 5-10 сек. MS SQL) убили всякое желание экспериментировать
7 mobi
 
27.12.14
14:44
(6) Какая платформа? Чей постгрес ставили?
8 bolero
 
27.12.14
15:17
** подпишусь

хочу намутить на выходных схему с tablespace под 1с на ram-диске, с синхронизацией ко второму инстансу pgsql на той же машине, но с записью на настоящий диск

зачем? на дешевом хостинге недоступен ssd, вот зачем
9 ilpar
 
27.12.14
15:25
+ в продолжение, у постгреса есть огромный минусище.
Когда падает винда и нет бэкапа - не многие знают как восстановить базу.
Только после обкатки такого восстановления можно залазить :) А про бэкапы - да слышали...Только когда они нужны диск с ними обычно был забит месяц назад и актуальных нет ))
10 ansh15
 
27.12.14
15:39
(9) И постгрес, конечно, виноват, Что и винда упала и бэкапов нету...
11 ilpar
 
27.12.14
15:41
(10) ну бэкап дневной давности в средней конторе к примеру 1С-нику обычно нахрен не нужен )
При MS SQL такой вопрос не поднимается обычно.
12 milan
 
27.12.14
16:02
Общался недавно с товарищем, у него мнение такое - экономия на лицензиях скл должна быть отыграна вложениями в железо и админа для получения какогото профита.
13 Chai Nic
 
27.12.14
16:17
Постгрес нормальное решение для самописки, но крайне неудачное для типовых.
14 OLень
 
27.12.14
16:58
что? у нас УПП, 100 пользователей. работает постгре 9.2
15 OLень
 
27.12.14
16:59
100 одновременно работающих. всего 160
16 ilpar
 
27.12.14
17:03
(15) ну мы то тебе не верим что все нормуль, пока данные apdex не увидим :)
17 OLень
 
27.12.14
17:05
да не верьте, мне-то что, я из этого профит не извлекаю :)
18 mobi
 
27.12.14
17:07
(9) Ну постгрес на винде это конечно не тру, родная ось для него линукс. В этом то и есть основная идея перевода 1с на постгрес. Просто когда начальство увидело ценник на лицензию виндовс сервер, лицензии на подключение к серверу, лицензии на скуль я понял, что нового сервера не будет. На тестах всё отлично, но тесты тестами, а вот как всё взлетит, когда подключатся 150 пользователей, вопрос интересный.
19 Chai Nic
 
27.12.14
17:18
Я уже писал неоднократно - у постгреса тупой оптимизатор запроса. Тупость заключается в том, что он применяет nested loop при соединении с подзапросом (виртуальной таблицей 1с). Поскольку на момент составления плана запроса неизвестно, какой будет размер таблицы, возвращенной подзапросом, постгрес слишком оптимистично предполагает, что подзапрос вернет очень мало строк, и надо применять nested loop. В 1с это чаще всего не так.
20 ilpar
 
27.12.14
17:19
21 Chai Nic
 
27.12.14
18:02
(20) Стоит, я в некоторых из них даже участвовал. Но решения, которое бы 100% работало на самом деле нет. Если отключать nested loop полностью для сервера замедляет работу в целом, если не отключать - есть риск наткнуться на дикие тормоза в частности.
22 MrStomak
 
27.12.14
20:35
(19) Причем тут тупой оптимизатор, вы описываете стандартный алгоритм любого оптимизатора при соединении с подзапросом, который непонятно что возвращать будет. И такого в 1С мало.
23 ilpar
 
27.12.14
20:36
Почитай по ссылкам темы с неадекватным поведением постгреса протим скуля :)
24 Chai Nic
 
27.12.14
20:36
(22) "вы описываете стандартный алгоритм любого оптимизатора при соединении с подзапросом"
Только вот почему-то mssql и db2 не делают nested loop, а постгрес - делает.
"И такого в 1С мало."
Сейчас в основном это учитывают, но старого кода еще достаточно, с тех времен, когда временных таблиц еще "не придумали")
25 MrStomak
 
27.12.14
20:54
(24) Конечно же и ms sql и db2 тоже могут залупить нестедлупс.

элементарный пример:
ВЫБРАТЬ
    ПоступлениеТоваровУслугТовары.Ссылка
ИЗ
    Документ.ПоступлениеТоваровУслуг.Товары КАК ПоступлениеТоваровУслугТовары
        ВНУТРЕННЕЕ СОЕДИНЕНИЕ (ВЫБРАТЬ
            Номенклатура.Ссылка КАК Ссылка
        ИЗ
            Справочник.Номенклатура КАК Номенклатура
        ГДЕ
            Номенклатура.Наименование ПОДОБНО "%а%"
            )
             КАК ВложенныйЗапрос
        ПО ПоступлениеТоваровУслугТовары.Номенклатура = ВложенныйЗапрос.Ссылка

план ms sql:
Rows         Executes     StmtText                                                                                                                                                                                                                                                                                 StmtId       NodeId       Parent       PhysicalOp           LogicalOp            Argument                                                                                                                                                                                                                                                           DefinedValues                                                                                     EstimateRows EstimateIO   EstimateCPU  AvgRowSize   TotalSubtreeCost OutputList                                       Warnings     Type         Parallel     EstimateExecutions
----         --------     --------                                                                                                                                                                                                                                                                                 ------       ------       ------       ----------           ---------            --------                                                                                                                                                                                                                                                           -------------                                                                                     ------------ ----------   -----------  ----------   ---------------- ----------                                       --------     ----         --------     ------------------
25765        1            Hash Match(Inner Join, HASH:([T3].[_IDRRef])=([T1].[_Fld12461RRef]), RESIDUAL:([aerofood].[dbo].[_Reference144].[_IDRRef] as [T3].[_IDRRef]=[aerofood].[dbo].[_Document468_VT12459].[_Fld12461RRef] as [T1].[_Fld12461RRef]))                                                            0            0                         Hash Match           Inner Join           HASH:([T3].[_IDRRef])=([T1].[_Fld12461RRef]), RESIDUAL:([aerofood].[dbo].[_Reference144].[_IDRRef] as [T3].[_IDRRef]=[aerofood].[dbo].[_Document468_VT12459].[_Fld12461RRef] as [T1].[_Fld12461RRef])                                                                                                                                                                36995,1      0            0,621689     23           1,95204          [T1].[_Document468_IDRRef]                                    PLAN_ROW     0            1                  
14842        1              |--Nested Loops(Inner Join, OUTER REFERENCES:([Expr1007], [Expr1008], [Expr1009]))                                                                                                                                                                                                     0            1            0            Nested Loops         Inner Join           OUTER REFERENCES:([Expr1007], [Expr1008], [Expr1009])                                                                                                                                                                                                                                                                                                                14601,9      0,111273     0,0162191    81           0,127492         [T3].[_IDRRef]                                                PLAN_ROW     0            1                  
0            0              |    |--Compute Scalar(DEFINE:([Expr1007]=LikeRangeStart([@P1]), [Expr1008]=LikeRangeEnd([@P1]), [Expr1009]=LikeRangeInfo([@P1])))                                                                                                                                                     0            2            1            Compute Scalar       Compute Scalar       DEFINE:([Expr1007]=LikeRangeStart([@P1]), [Expr1008]=LikeRangeEnd([@P1]), [Expr1009]=LikeRangeInfo([@P1]))                                                                                                                                                         [Expr1007]=LikeRangeStart([@P1]), [Expr1008]=LikeRangeEnd([@P1]), [Expr1009]=LikeRangeInfo([@P1]) 1            0            0            8017         0                [Expr1007], [Expr1008], [Expr1009]                            PLAN_ROW     0            1                  
1            1              |    |    |--Constant Scan                                                                                                                                                                                                                                                             0            3            2            Constant Scan        Constant Scan                                                                                                                                                                                                                                                                                                                                                                             1            0            0            0            0                                                                              PLAN_ROW     0            1                  
14842        1              |    |--Index Seek(OBJECT:([aerofood].[dbo].[_Reference144].[_Referen144_Descr_SR] AS [T3]), SEEK:([T3].[_Description] > [Expr1007] AND [T3].[_Description] < [Expr1008]),  WHERE:([aerofood].[dbo].[_Reference144].[_Description] as [T3].[_Description] like [@P1]) ORDERED FORWARD) 0            11           1            Index Seek           Index Seek           OBJECT:([aerofood].[dbo].[_Reference144].[_Referen144_Descr_SR] AS [T3]), SEEK:([T3].[_Description] > [Expr1007] AND [T3].[_Description] < [Expr1008]),  WHERE:([aerofood].[dbo].[_Reference144].[_Description] as [T3].[_Description] like [@P1]) ORDERED FORWARD [T3].[_IDRRef]                                                                                    14601,9      0,111273     0,0162191    81           0,127492         [T3].[_IDRRef]                                                PLAN_ROW     0            1                  
37092        1              |--Clustered Index Scan(OBJECT:([aerofood].[dbo].[_Document468_VT12459].[_Documen468_VT12459_IntKeyInd] AS [T1]))                                                                                                                                                                      0            12           0            Clustered Index Scan Clustered Index Scan OBJECT:([aerofood].[dbo].[_Document468_VT12459].[_Documen468_VT12459_IntKeyInd] AS [T1])                                                                                                                                                                           [T1].[_Document468_IDRRef], [T1].[_Fld12461RRef]                                                  37092        1,14905      0,0409582    39           1,19001          [T1].[_Document468_IDRRef], [T1].[_Fld12461RRef]              PLAN_ROW     0            1
26 MrStomak
 
27.12.14
21:02
Вот пример, что PG выбирает хэш, если есть статистика по таблице из подзапроса:

ВЫБРАТЬ
    док.Ссылка КАК Ссылка
ИЗ
    Документ.умпЗапросНаПеревозку КАК док
        ВНУТРЕННЕЕ СОЕДИНЕНИЕ (ВЫБРАТЬ
            контрагенты.Ссылка КАК Ссылка
        ИЗ
            Справочник.Контрагенты КАК контрагенты) КАК вложенныйзапрос
        ПО док.Контрагент = вложенныйзапрос.Ссылка

hash join  (cost=699.60..4148.76 rows=23972 width=20) (actual time=2.408..17.088 rows=23967 loops=1)
  hash cond: (t1.Контрагент = t3.Ссылка)
  ->  seq scan on Документ.умпЗапросНаПеревозку t1  (cost=0.00..2969.72 rows=23972 width=40) (actual time=0.003..4.153 rows=23972 loops=1)
  ->  hash  (cost=628.71..628.71 rows=5671 width=20) (actual time=2.397..2.397 rows=5671 loops=1)
        buckets: 1024  batches: 1  memory usage: 272kb
        ->  seq scan on Справочник.Контрагенты t3  (cost=0.00..628.71 rows=5671 width=20) (actual time=0.002..1.282 rows=5671 loops=1)
total runtime: 18.460 ms
27 mobi
 
27.12.14
21:06
(20) В том то и дело, что если по твоей ссылке в гугле включить отбор только за последний год, то про nested loops там будет всего пару тем, основные темы про косяк с нестедлупсом датируются 2012 годом. За пару лет могли уже и залатать.
28 MrStomak
 
27.12.14
21:16
(25) я вот ошибся кстати, тут ms sql тоже хэш использует, т.к. умело предположил, что на выходе будет около 14к строк.
Но в (26) видно, что pg также действует.
Но если в подзапросе посодеинять таблицы непредсказуемо - оба выдают nested loops
29 Chai Nic
 
28.12.14
19:51
(28) Всё-таки, по моему опыту, у mssql оптимизатор намного умнее и ошибка с нестедлупом для него нехарактерна и достаточно редка.. а вот постгрес очень любит такие методы.
Программист всегда исправляет последнюю ошибку.