|
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
|
Вот темы на форуме стоит почитать
https://www.google.ru/webhp?sourceid=chrome-instant&ion=1&espv=2&es_th=1&ie=UTF-8#newwindow=1&q=enable_nestloop+site:forum.mista.ru |
|||
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 оптимизатор намного умнее и ошибка с нестедлупом для него нехарактерна и достаточно редка.. а вот постгрес очень любит такие методы.
|
Форум | Правила | Описание | Объявления | Секции | Поиск | Книга знаний | Вики-миста |