1C SQL, wine@etersoft SQL , Selta (жуткие тормоза, помогите советом)

[kerya33]

Переношу базу данных 1С v 7.7 SQL с MS 2000 SQL server на Debian Lenny, wine@etersoft 1.0.9 SQL, selta@etersoft v 1.0.4, Postgres v 8.2.11-eter13. Объем БД на MS SQL 28 Гб, Selta конвертировала базу 20 часов, объем БД в Postgres вырос до 40,7 Гб. Рекомендуемые etersoft настройки по оптимизации Postgres установил. При запуске 1С SQL под wine - selta открытие журнала документов происходит ~ 35-38 сек, перемещение по журналу фактически невозможно тоже из за жутких тормозов. Эти же действия (открытие журнала накладных) на этой же машине (P-IV, 2,4 ГГц, 512 Мб RAM) под MS 2003 проиисходят за 1 сек, перемещение по журналу тоже без задержек.
Select count(*) from _1sentry; (8846842 записей) из psql длится 60 - 65 сек, c использованием Selta тоже 60-65 сек, под MS SQL на этой же машине тот же запрос 30 сек.
На рабочем сервере (2-х процессорный Xeon, 8 Гб RAM, SCSI raid) под MS SQL - 7 сек, 1С просто летает. Вторые сутки пытаюсь разобраться, помогите в какую сторону копать, pl's.

[yaleks]

Сколько памяти на машине с PostgreSQL?

[kerya33]

Сколько памяти на машине с PostgreSQL?

P-IV, 2,4 ГГц, 512 Мб RAM база даных постгреса расположена на RAID 0 (для увеличения бвстродействия т.к. это тестовый вариант). Я понимаю, что памяти мало, и разница по времени запроса из MS vs Postgres - 2 раза может и допустима, но вот работа 1С медленне в 40 раз - это непонятно...

[yaleks]

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

[kerya33]

Поставьте хотя бы 2 гига

Память сегодня увеличу, но с 512 Мб MS 2000 SQL работает достаточно шустро на одном клиенте, а Postgres отказывается. Еще никак не пойму за счет чего БД увеличилась почти в два раза при конвертации? Количество записей по таблицам (выборочно, все не сверял) совпадает.

[Djelf]

При запуске 1С SQL под wine - selta открытие журнала документов происходит ~ 35-38 сек, перемещение по журналу фактически невозможно тоже из за жутких тормозов. Эти же действия (открытие журнала накладных) на этой же машине (P-IV, 2,4 ГГц, 512 Мб RAM) под MS 2003 проиисходят за 1 сек, перемещение по журналу тоже без задержек.

Работа с журналами, справочниками и т.п. в 1С очень часто идет с использованием динамических курсоров, в MS SQL они есть, в Postgress нет.
Selta имитирует динамические курсоры пересозданием обычных курсоров и передвижением по ним в нужную позицию, что и убивает возможность работы с документами в штатном режиме. Поможет только переход на прямые запросы, но это занятие не для слабонервных. Или ждать пока кое-кто догадается триггеры на базу поставить и не пересоздавать курсор по 500 раз на одну форму.

Select count(*) from _1sentry; (8846842 записей) из psql длится 60 - 65 сек, c использованием Selta тоже 60-65 сек, под MS SQL на этой же машине тот же запрос 30 сек.
На рабочем сервере (2-х процессорный Xeon, 8 Гб RAM, SCSI raid) под MS SQL - 7 сек, 1С просто летает. Вторые сутки пытаюсь разобраться, помогите в какую сторону копать, pl's.

Select count(*) , насколько я помню, в postgress значительно хуже оптимизирован MS SQL, если тестить то на чем то вроде select чтотатам. У меня на тестах запросы (именно запросы) практически не отличались по скорости.

Еще никак не пойму за счет чего БД увеличилась почти в два раза при конвертации? Количество записей по таблицам (выборочно, все не сверял) совпадает.

Юникод.

P.S. Если нужно обязательно слезть с MS SQL и база под прямые запросы не заточена можно попробовать DBEng32 под CodeBase или DBEng32 для Advantage по отзывам даже быстрее MS SQL.

[kerya33]

Спасибо большое за развернутый ответ

P.S. Если нужно обязательно слезть с MS SQL

В организации остро втал ворос лицензирования используемого ПО. К 1С SQL базе клинты обращаются в терминальном режиме. Одна и та же машина используется как сервер БД, терминальный и файл сервер. Часть клиентских рабочих мест переведена на линукс (rdesktop, CUPS для сетевой печати, samba), остальные в процессе перехода. MS 2003 serevr Enterprise + Terminal server + MS SQL 2000 в работе полностью устраивают, вот только лицензирование стоит не малых денег. Поэтому посмотрели в сторону Etersoft. На вышеуказанных объемах данных на данный момент тестирования система фактически не работоспособна. Руководство меня не поймет, если при переходе на Wine - Selta - Etersoft существенно упадет производительность. Переписывать работающую конфигурацию нет возможности да и некому ... Если не получу удовлетворительных результатов, придется сервер оставлять в старом варианте.

можно попробовать DBEng32 под CodeBase или DBEng32 для Advantage по отзывам даже быстрее MS SQL.

В свое время при увеличении объема БД ушли от файл серверной к SQL версии. Теперь возвращать опять? Да и отзывов по работе с такими объемами 1С БД для DBEng32 я чего-то не нашел.

[yaleks]

MS 2003 serevr Enterprise + Terminal server + MS SQL 2000 в работе полностью устраивают, вот только лицензирование стоит не малых денег. Поэтому посмотрели в сторону Etersoft. На вышеуказанных объемах данных на данный момент тестирования система фактически не работоспособна. Руководство меня не поймет, если при переходе на Wine - Selta - Etersoft существенно упадет производительность. Переписывать работающую конфигурацию нет возможности да и некому ...

лицензирование к тому же практически невозможно (SQL 2k). Франчайзи предлагают услуги по оптимизации SQL конфигураций, так что это можно включить в смету по миграции. Или на 1С 8.2 переходить (ещё дороже).

[kerya33]

Франчайзи предлагают услуги по оптимизации SQL конфигураций, так что это можно включить в смету по миграции.

Перед тем как начал заниматься сервером пообщался со многими конторами в городе, которые занимаются внедрением - поддержкой 1С. Вопрос был один - переход 1C на opensource платформу. Процентов 25 ответили, что 1С работает только под виндой и другого не дано. Пару человек предложили терминальные решения на линукс клиентах и MS сервере. И как они будут оптимизировать SQL версию под использование с Postgres ? Серверных внедрений у нас в городе не нашел. Разработчик конфигурации отошел от дел, у него другой бизнес. Я в программировании 1С опыта не имею, хотя чувствую придется заняться. Правда каким будет результат (и что немаловажно - когда) неясно. Переход на 1С 8.2 как вариант не рассматривается.

[Djelf]

В свое время при увеличении объема БД ушли от файл серверной к SQL версии. Теперь возвращать опять? Да и отзывов по работе с такими объемами 1С БД для DBEng32 я чего-то не нашел.

Я сам хотел с на selta перейти, но даже на 2Gb базы мне это показалось не совсем реальным, но я то могу с таким объемом позволить себе сидеть на dbf. А у тебя база жестокая, dbf не потянет. Но тут не dbf, тут замена самого движка 1С на клиент-серверную технологию, а это совсем-совсем другое. И пожалуй даже лучше лучше чем selta по идеологии: транслятор проще и почти весь сидит в движке самой базы данных (что хорошо), который обкатан уже не один год (что еще лучше). И кстати + штатные конструкции 1С работать все будут, - нештатные (прямые запросы) придется подпиливать под платформу, а когда этого не было?
Попробуй связаться напрямую с hogik (похоже это лучший спец по этой dll и ее он уже давно по косточкам разложил), может у него есть данные по реально используемым объемам баз под 1С с его решениями (в форум то не всегда все пишут).
Да и за "попробовать" денег и в этом варианте тоже не берут.

kerya33, честно скажу, "я не в доли" в патче к dbeng32 и я не пробовал это решение, но вариант думаю все таки очень соблазнительный (я уже на прямых запросах под 1sqlite, поэтому мне это не подойдет).
Кстати если что-то удастся или не сложится пожалуйста не оставь нас в неведении

Если не получу удовлетворительных результатов, придется сервер оставлять в старом варианте.

Если есть возможность, любым способом, уломать на это, оставь как есть! Да простят меня все пользующиеся OpenSource
Но с лицензиями то ж... п... на сервер, на подключение к нему, на терминальную сессию, на sql сервер, на подключение к нему...
Мммммм..... покажика руководству selta в действии, может и денюжки найдутся

[arahorn]

Переношу базу данных 1С v 7.7 SQL с MS 2000 SQL server на Debian Lenny, wine@etersoft 1.0.9 SQL, selta@etersoft v 1.0.4, Postgres v 8.2.11-eter13. Объем БД на MS SQL 28 Гб, Selta конвертировала базу 20 часов, объем БД в Postgres вырос до 40,7 Гб. Рекомендуемые etersoft настройки по оптимизации Postgres установил. При запуске 1С SQL под wine - selta открытие журнала документов происходит ~ 35-38 сек, перемещение по журналу фактически невозможно тоже из за жутких тормозов. Эти же действия (открытие журнала накладных) на этой же машине (P-IV, 2,4 ГГц, 512 Мб RAM) под MS 2003 проиисходят за 1 сек, перемещение по журналу тоже без задержек.
Select count(*) from _1sentry; (8846842 записей) из psql длится 60 - 65 сек, c использованием Selta тоже 60-65 сек, под MS SQL на этой же машине тот же запрос 30 сек.
На рабочем сервере (2-х процессорный Xeon, 8 Гб RAM, SCSI raid) под MS SQL - 7 сек, 1С просто летает. Вторые сутки пытаюсь разобраться, помогите в какую сторону копать, pl's.

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

во первых памяти с таким объемом базы явно должно быть не менее гига, идеально было бы три
во вторых, производительность PostgreSQL очень сильно зависит от того как его настроить, рекомендации по настройке попробуйте посмотреть вот здесь http://postgresmen.ru/articles/view/38 , и вот здесь http://www.phpclub.ru/detail/store/html/po...000000000000000

рекомендованная конфигурация от etersoft у меня также жутко тормозила, хотя за основу я взял именно ее, вот моя рабочая конфигурация сервера (следует учесть что условия у нас с Вами различаются)

Код: Выделить всё

listen_addresses = '*'        # what IP address(es) to listen on;
max_connections = 30            # (change requires restart)
shared_buffers = 128MB            # min 128kB or max_connections*16kB
temp_buffers = 16MB            # min 800kB
max_prepared_transactions = 5        # can be 0 or more
work_mem = 64MB                # min 64kB
maintenance_work_mem = 256MB        # min 1MB
max_stack_depth = 7MB            # min 100kB
max_fsm_pages = 2097152        # min max_fsm_relations*16, 6 bytes each
max_fsm_relations = 20000        # min 100, ~70 bytes each
vacuum_cost_delay = 200
vacuum_cost_page_hit = 6
vacuum_cost_limit = 100
fsync = off                # turns forced synchronization on or off
full_page_writes = off            # recover from partial page writes
wal_buffers = 256kB            # min 32kB
checkpoint_segments = 25
random_page_cost = 8.0
effective_cache_size = 500MB
default_statistics_target = 100        # range 1-1000
constraint_exclusion = on
redirect_stderr = on            # Enable capturing of stderr into log
log_directory = 'pg_log'        # Directory where log files are written
log_truncate_on_rotation = on        # If on, any existing log file of the same
log_rotation_age = 1d            # Automatic rotation of logfiles will
log_rotation_size = 0            # Automatic rotation of logfiles will
client_min_messages = error        # Values, in order of decreasing detail:
log_line_prefix = '%t%%%d%%%h'        #   %u = user name
stats_command_string = on
stats_start_collector = on        # needed for block or row stats
stats_block_level = off
stats_row_level = on
stats_reset_on_server_start = off    # (change requires restart)
autovacuum = on             # enable autovacuum subprocess?
autovacuum_naptime = 1min        # time between autovacuum runs
datestyle = 'iso, dmy'
lc_messages = 'ru_RU.UTF-8'            # locale for system error message
lc_monetary = 'ru_RU.UTF-8'            # locale for monetary formatting
lc_numeric = 'ru_RU.UTF-8'            # locale for number formatting
lc_time = 'ru_RU.UTF-8'                # locale for time formatting
deadlock_timeout = 2s
max_locks_per_transaction = 5000        # min 10
escape_string_warning = off
standard_conforming_strings = off

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

в отличие от Вас у меня при внедрении были тепличные условия никто не требовал чтобы сразу на ура заработало и пользователей о том что будет тормозить и они будут недовольны я предупреждал и они даже все это терпели. Вам рекомендую имитировать плотную нагрузку от 3-4 пользователей и пытаться отладить по максимуму.

P.S. имхо напрямую сравнивать быстродействие 1С 7.7 под MS и под Linux+postgresql+wine@etersoft+selta@etersoft не совсем корректно, какие то операции выполняются значительно быстрее, какие то значительно медленнее, к сожалению особенно в начале перехода пользователи обращают внимание только на то что выполняется медленнее

удачи

[Djelf]

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

Ни в коем случае, если Вы нашли или даже не нашли "золотое зерно" это все равно сейчас очень актуально.
Если БД у Вас сейчас не тормозит, можно ли узнать Ваши характеристики железа, размер БД, что за БД (бухгалтерия, торговля, склад, ТИС, ИТРП...), сколько человек с БД обычно работают, есть ли при работе неадекватные (в 2-3-10раз отличные от MS+MS SQL) "тормоза" и т.п.
Я понимаю, некорректно все один к одному с Виндой сравнивать, но хоть с чем то сравнить то надо.

[arahorn]

Ни в коем случае, если Вы нашли или даже не нашли "золотое зерно" это все равно сейчас очень актуально.
Если БД у Вас сейчас не тормозит, можно ли узнать Ваши характеристики железа, размер БД, что за БД (бухгалтерия, торговля, склад, ТИС, ИТРП...), сколько человек с БД обычно работают, есть ли при работе неадекватные (в 2-3-10раз отличные от MS+MS SQL) "тормоза" и т.п.
Я понимаю, некорректно все один к одному с Виндой сравнивать, но хоть с чем то сравнить то надо.

Баз несколько
3 комплексных размер у двух по 15 Гб, у одной минимальный
1 ТиС - размер метров 100
конфигурации практически типовые, внесенные изменения минимальны
1 8-ка УПП, размер минимальный, учет ведется всего пару месяцев на небольшое предприятие, сервер 8-ки крутится на этой же машине
все базы кроме 8-ки периферийные, автообмен с центральными запускается раз в полчаса

активно работающих пользователей от 0 до 6 - зачастую работают с несколькими базами поэтому что нибудь конкретно сказать не могу
пользователи работают локально со своих машин (машины не прошлого века и сеть гигабитная)

по тормозам: после последних изменений в конфигурации postgresql пользователи жаловаться перестали, отсюда делаю вывод что особых тормозов нет.
Я в своей работе в части программиста 1С также разницы в работе с MS-SQL которая бы меня сильно бесила не замечаю, хотя возможно уже просто привык, какие то тесты на равнозначном железе проводить просто нет времени.

характеристики железа: Pentium 4 3 Гц, 1 Гб оперативки, 3 винта SATA по 80 Гб, как используются винты писал выше.

операционная система Slackware 12.1 ядро 2.6.21.5-smp из штатной поставки (не пересобирали)

используется wine WINE@Etersoft 1.0 SQL (1.0.9)
Selta@Etersoft 1.04

клиентские машины - откровенный зоопарк, Ubunta 8.04, Ubunta 7.10, Slackware 11, Windows XP

версии 1С-к последние

[kerya33]

честно скажу, "я не в доли" в патче к dbeng32 и я не пробовал это решение, но вариант думаю все таки очень соблазнительный (я уже на прямых запросах под 1sqlite, поэтому мне это не подойдет).
Кстати если что-то удастся или не сложится пожалуйста не оставь нас в неведении

Если с Selta ничего вразумительного не получу обязательно буду пробовать, по результатам буду отписывать.

Мммммм..... покажика руководству selta в действии, может и денюжки найдутся

Да денюжки-то конечно найдутся, скажу больше, 1С на серверной линух платформе - это моя инициатива. Шефы по поводу возможных граблей в этом вопросе все прекрасно понимают. Просто результат при перходе должен быть приемлемым или все останется "as is".

To arahorn
Спасибо за совет. По любому прежде, чем рассматривать другие варианты, постараюсь выжать все, что можно из Postgres.

Вам рекомендую имитировать плотную нагрузку от 3-4 пользователей и пытаться отладить по максимуму.

Пока и имитировать нечего, база под одним то юзером еле ползает ...

[BIgAndy]

Переношу базу данных 1С v 7.7 SQL с MS 2000 SQL server на Debian Lenny, wine@etersoft 1.0.9 SQL, selta@etersoft v 1.0.4, Postgres v 8.2.11-eter13. Объем БД на MS SQL 28 Гб, Selta конвертировала базу 20 часов, объем БД в Postgres вырос до 40,7 Гб. Рекомендуемые etersoft настройки по оптимизации Postgres установил. При запуске 1С SQL под wine - selta открытие журнала документов происходит ~ 35-38 сек, перемещение по журналу фактически невозможно тоже из за жутких тормозов. Эти же действия (открытие журнала накладных) на этой же машине (P-IV, 2,4 ГГц, 512 Мб RAM) под MS 2003 проиисходят за 1 сек, перемещение по журналу тоже без задержек.
Select count(*) from _1sentry; (8846842 записей) из psql длится 60 - 65 сек, c использованием Selta тоже 60-65 сек, под MS SQL на этой же машине тот же запрос 30 сек.
На рабочем сервере (2-х процессорный Xeon, 8 Гб RAM, SCSI raid) под MS SQL - 7 сек, 1С просто летает. Вторые сутки пытаюсь разобраться, помогите в какую сторону копать, pl's.

1)Отключите DE и выполните этот запрос из psql.
2)Включите оптимизатор запросов и выполните еще раз. Если время во втором случае будет значительно меньше первого случая, оставьте его включенным.
3) Изучите графы выполнения запросов. Возможно они составлены неоптимальным способом.
4) Не мешало бы привести настройки, в частности величину кеша СУБД и включена ли перекодровка cp1251-utf8?

[yaleks]

3) Изучите графы выполнения запросов. Возможно они составлены неоптимальным способом.

в этом нет сомнений, поскольку это перекодировка белиберды из 1С для MS SQL в PostgreSQL

[arahorn]

таки сейчас наверное меня забанят ибо пьян я ик... и не собираюсь соблюдать политкорректность

ребят о чем вы говорите
какие нафиг умности по поводу "прямые запросы", "Если есть возможность, любым способом, уломать на это, оставь как есть! Да простят меня все пользующиеся OpenSource", "Select count(*) ", "Работа с журналами, справочниками и т.п. в 1С очень часто идет с использованием динамических курсоров"

вы о чем вообще
вы умные что ли ?
если умные то что вы делаете на форуме ? у вас должно быть дофига делов чтобы заработать дофига денежек
в данном случае речь идет о том чтобы сэкономить денег на легализации софта для родной конторы
честно говоря я сам был в шоке когда Etersoft объявила о трансляторе в PostgreSQL возникла просто мысль почему не в MySQL, таки посмотрев на Postgre я его таки возлюбил, его можно подстроить под любые свои нужды, главное вытащить руки из жопы и перекочевать мозг из спинного в головной

сорри зачинателю темы

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

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

и таки еще один довод почему компания Etersoft пошла в сторону Postgre, потому что компания 1С пошла в ту же б...ь самую сторону итого при условии использовании Selta и Postgre мы без лишних затрат денег и дублирования серверов можем обеспечить переход наших любимых и платящих нам денег контор со снимающейся с обслуживания 1С 7.7 на 1С 8.1

P.S. ну хоть и виноват не баньте строго, не вру ей богу, скажи серега, и если б водку гнать не из опилок то чтоб нам было с 3, с 4-х, с 5 бутылок

[kerya33]

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

сорри зачинателю темы

последую совету, т.к. следующие строчки

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

обнадеживают

[kerya33]

Вообщем после увеличения памяти до 4 Гб и манипуляций с postgresql.conf включил подробный лог postgre, вот кусок его:

Код:

duration: 2297.399 ms statement: CLOSE dyn_cur_3557_02588BA0; DECLARE dyn_cur_3557_02588BA0 SCROLL CURSOR WITH HOLD FOR SELECT JOURN.* FROM _1SJOURN JOURN, _1SCRDOC CRDOC WHERE JOURN.DATE_TIME_IDDOC=CRDOC.CHILD_DATE_TIME_IDDOC AND CRDOC.MDID=442 AND CRDOC.PARENTVAL=E'U ' AND CRDOC.CHILD_DATE_TIME_IDDOC>=E'20080101 0 0 ' AND CRDOC.CHILD_DATE_TIME_IDDOC<=E'20081231FHML6O 0 ' ORDER BY CRDOC.MDID, CRDOC.PARENTVAL, CRDOC.CHILD_DATE_TIME_IDDOC; MOVE FORWARD 1 IN dyn_cur_3557_02588BA0;

курсор при этом содержит порядка 120000 записей, при открытии журнала, курсор создается и убивается 3 раза (время ~ 18 сек при первом открытии журнала и 6-7 сек при повторном обращении). Аналогичная картина просто при перемещении по журналу, постоянно пересоздается курсор на 120 тыс. записей MS SQL на этом же железе работает с динамическими курсорами и все происходит в несколько раз быстрее.

Работа с журналами, справочниками и т.п. в 1С очень часто идет с использованием динамических курсоров, в MS SQL они есть, в Postgress нет.
Selta имитирует динамические курсоры пересозданием обычных курсоров и передвижением по ним в нужную позицию, что и убивает возможность работы с документами в штатном режиме. Поможет только переход на прямые запросы, но это занятие не для слабонервных. Или ждать пока кое-кто догадается триггеры на базу поставить и не пересоздавать курсор по 500 раз на одну форму.

Похоже Djelf прав на все сто и ничего другого здесь не придумаешь ...

[prof]

курсор при этом содержит порядка 120000 записей,

А есть какая-то необходимость в работе с журналом документов в широком диапазоне? Я давненько "допиливал" торговлю одним барыгам, там SQL не было, а тормоза были, у них было настроено так, что в журналах документов виден был только текущий день, а у тех для кого работа в "реальном времени" не важна можно открывать журналы "подекадно" или "понедельно". Без изменения "стиля работы" не обойтись...
Эти тормоза и меня останавливают от перехода на SQL, но мне размер базы пока позволяет сидеть на dbf.

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

А каковы последствия обсуждения этих тезисов с разработчиками Selta?

[Djelf]

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

А каковы последствия обсуждения этих тезисов с разработчиками Selta?

Почти никакие
Я начал тестировать selta с появления первой доступной beta-версии, через некоторое время получил полную selta по акции для покупателей wine@etersoft.sql (для этого sql и покупал). Удалось поймать определенное количество багов, некоторые не дождавшись ответа поддержки, пофиксил сам и отправил решение etersoft. В процессе этого удалось связаться напрямую с разработчиком selta (на тот момент).
Я с ним постоянно общался по почте и естественно "распечатал" заявку

От: "Служба поддержки Etersoft" <support@etersoft.ru>
Дата: 25 Декабрь 2007

Это сообщение было автоматически сгенерировано в ответ на создание вами
заявки "Тормоза в журнале документов",
общая информация о которой идет ниже.

Не нужно отвечать на это сообщение прямо сейчас. Вашей заявке был назначен
идентификатор в [etersoft.ru #3110].

По этой заявке и был сделан переход на курсоры, до этого использовался простой select (было еще медленнее). Был забавный случай на одной из сборок: журналы почти "взлетели", я уж совсем собрадовался, но оказалось что курсоры просто не пересоздаются, потом это пофиксили и все вернулось на круги своя. Ну а теперь больше года прошло и поддержка должна была кончится..

Насчет триггеров я писал разработчику в марте 2008г.

Почему бы не имитировать динамические курсоры? Можно нарисовать триггеры обновляющие в отдельной таблице информацию о времени последней модификации каждой из таблиц. Тогда можно сравнивая эту информацию с сreation_time курсора в pg_cursors определить нужно ли вообще обновлять курсор.

В OpenLink ODBC Driver for PostgreSQL что-то подобное реализовано: Dynamic Cursor Sensitivity http://docs.openlinksw.com/ee/eepostgresqlwin.html

Никакой реакции не последовало, потом разработчик переехал в другой город, потом наступило затишье в разработке selta...
Сейчас новые разработчики, я с ними связи не имею. База у меня переведена на новый сервер под dbf, поэтому тестировать selta мне нет никакой необходимости, да и честно говоря никакого желания - и так кучу времени на это угробил

А есть какая-то необходимость в работе с журналом документов в широком диапазоне? Я давненько "допиливал" торговлю одним барыгам, там SQL не было, а тормоза были, у них было настроено так, что в журналах документов виден был только текущий день, а у тех для кого работа в "реальном времени" не важна можно открывать журналы "подекадно" или "понедельно". Без изменения "стиля работы" не обойтись...

Еcли бы было дело в одних журналах... А оно же и в справочниках так.
У меня прием заказов с клавиатуры с такой скоростью набирают, что когда сервер начинает чуток подтормаживать сразу начинается истерика. На selta скорость такая что меня живьем закопают

[warlomak]

мдааа... Поставил postgre 8.3.5 selta 1.0.5 попробовал загрузить 10 документов по ~8000 позиций (обработкой самописной для переноса остатков в док. поступление тмц розница), а потом попробовал их провести ;-(((( Ужас, тормоза неимоверные, на ms sql просто летает...

p.s.
Железо одинаковое. Рановато мне есче сельту в раб.условиях гонять...

[prof]

Насчет триггеров я писал разработчику в марте 2008г.

Почему бы не имитировать динамические курсоры? Можно нарисовать триггеры обновляющие в отдельной таблице информацию о времени последней модификации каждой из таблиц. Тогда можно сравнивая эту информацию с сreation_time курсора в pg_cursors определить нужно ли вообще обновлять курсор.

В OpenLink ODBC Driver for PostgreSQL что-то подобное реализовано: Dynamic Cursor Sensitivity http://docs.openlinksw.com/ee/eepostgresqlwin.html

Мне тяжело об этом рассуждать, т.к. в SQL не силён, в поисках информации по dynamic cursors нашел один документ чем отличается реализация динамических курсоров предложенная в нём от того что есть сейчас? И какая функциональность именно динамических курсоров является необходимой для работоспособности 1С?

[Djelf]

чем отличается реализация динамических курсоров предложенная в нём от того что есть сейчас? И какая функциональность именно динамических курсоров является необходимой для работоспособности 1С?

Работоспособность в принципе уже есть Скорости не хватает...
А для скорости требуется всего лишь чтобы курсор мог обновляться, а именно этого в Postgresql и нету.
Почитать о работе с курсорами в MSSQL можно тут: http://www.intuit.ru/department/database/p...l2000/27/1.html

Ну а отличия в реализации курсоров и причина тормозов такая:
1. Обновление курсора на несколько порядков быстрее пересоздания: MS SQL не пересоздает курсоры, а обновляет их. Selta+Postgresql пересоздает.
2. Потеря времени на движения позиции курсора: в MS SQL не требуется после обновления лишний раз двигать позицию курсора. В Postgresql после пересоздания позицию приходится двигать.
1+2 и создают задержки.

[prof]

Почитать о работе с курсорами в MSSQL можно тут:
...
Ну а отличия в реализации курсоров и причина тормозов такая:

Это как раз понятно, тут вопрос в другом, какие ещё варианты реализации "динамических курсоров" на postresql известны? И самое главное, каким образом курсоры используются в 1С? Может можно съэмулировать их как-то ещё. 1С нужны курсоры, он плюётся соответствующими запросами, selta их перевирает до неузнаваемости, существующий способ не эффективен, т.к. требует регулярного пересоздания огромного набора данных. Выход видится в увеличении интервала "обновления данных", а другого варианта нет? Ну например, "жульничать", и создавать ещё и набор данных по-меньше...

А что 1С применяет в таких случаях на восьмёрке? Или там так же, всё очень печально?

[Djelf]

какие ещё варианты реализации "динамических курсоров" на postresql известны? И самое главное, каким образом курсоры используются в 1С? Может можно съэмулировать их как-то ещё. 1С нужны курсоры, он плюётся соответствующими запросами, selta их перевирает до неузнаваемости, существующий способ не эффективен, т.к. требует регулярного пересоздания огромного набора данных. Выход видится в увеличении интервала "обновления данных", а другого варианта нет? Ну например, "жульничать", и создавать ещё и набор данных по-меньше...

А что 1С применяет в таких случаях на восьмёрке? Или там так же, всё очень печально?

prof я ж не toypaul, я не настолько хорошо знаю внутренности 1С чтоб дать готовый рецепт

[prof]

prof я ж не toypaul, я не настолько хорошо знаю внутренности 1С чтоб дать готовый рецепт

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

[Djelf]

prof я ж не toypaul, я не настолько хорошо знаю внутренности 1С чтоб дать готовый рецепт

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

Ладно, ладно, просто не охота чайником то выглядеть, тем более что я сам понимаю, что в этой области я почти полный чайник
Я так понял, что ты лог postgresql включал, количество пересозданий курсора видел. Значит вводную часть о том насколько 1С зависима от курсоров опустим.
Беда в том что без etersoft и очень серьезных изменений в selta мою идею невозможно реализовать. Примерная реализация такова: рисуются триггеры на изменение таблиц, триггеры при изменении таблицы увеличивают ее серийный номер в отдельной служебной таблице. При запросе строки курсора selta сравнивает серийные номера на момент создания курсора с номерами в служебной таблице и в случае их совпадения не делает пересоздание курсора и лишних движений по нему. Будет небольшое замедление при записи для отработки триггеров, но скорость работы курсоров (в том случае когда таблицы не менялись) возрастет в 100-1000 раз. Естественно будут тормоза при необходимости пересоздания курсора, но они хотя бы будут не всегда, а периодически.
Если говорить о нестандартных конфигурациях то отказаться от динамических/обновляемых курсоров можно, но не везде. Например, при проведении нас мало волнует изменение наименования номенклатуры и т.п., но selta этого не знает и узнать не может никак, поэтому в идеале нужна еще и ВК через которую можно взаимодействовать с selta и объяснять ее транслятору, что в данном конкретном случае нас вполне устроит статический курсор, и это еще больше ускорит работу.

[yaleks]

Мне тяжело об этом рассуждать, т.к. в SQL не силён, в поисках информации по dynamic cursors нашел один документ чем отличается реализация динамических курсоров предложенная в нём от того что есть сейчас? И какая функциональность именно динамических курсоров является необходимой для работоспособности 1С?

Кстати, неплохой документик, надо предложить etersoft сделать версию для DB2 (бесплатная имеет ограничения только на количество CPU и 2 гига памяти, на количество данных ограничений нет).
На http://www.swissql.com/products/sqlserver-...ver-to-db2.html предлагают утилиту для конвертации запросов (изучить что она выдаёт и добавить в транслятор). Динамические курсоры в DB2 есть, так что должно работать быстрее.

[prof]

Динамические курсоры в DB2 есть, так что должно работать быстрее.

Только, мне кажется, тут что-то с терминологией не так. Я не случайно просил высказаться на предмет оценки реализации "динамических курсоров" в данном документе. Вот, что по мнению авторов документа "заменяет" DYNAMIC Cursors в терминах DB2:

Код: Выделить всё

$$
DECLARE
    sqlString VARCHAR(500);
    selCur refcursor;

BEGIN
    sqlString = 'SELECT product_no,name ' ||
        'FROM products ' ||
        'WHERE product_no IN (SELECT product_no ' ||
            'FROM invoice WHERE cust_id = ' || iCuID || ') ' ||
            'AND invoice_year = ''' || sYear || ''') ' ||
        'ORDER BY product_no';

    OPEN selCur FOR EXECUTE sqlString;
    RETURN selCur;
END
;
$$

Я понял так что "динамическим" получается текст запроса, а не его поведение, вот кстати ещё один пример подобных "динамических" запросов: http://okbob.blogspot.com/2008/08/using-cu...ting-cross.html