Вход | Регистрация
    1  2  3  4  5  6  7  8   
1С:Предприятие :: 1С:Предприятие 7.7 и ранее

v7: 1С 7.7 ТИС ДБФ УРИБ 40 юзеров. Надо победить блокировки транзакций

v7: 1С 7.7 ТИС ДБФ УРИБ 40 юзеров. Надо победить блокировки транзакций
Я
   tgu82
 
28.10.20 - 13:18
1С 7.7 ТИС ДБФ УРИБ 40 юзеров.

В понедельник вообще с утра работать не могли. И так почти полтора часа.
Только когда я стал по очередности выгонять всех ввидимо отцепилась блокировка и
и все наконец заработали.

Заметил что 3 варианта блокировок:
1. при обмене урбд, попытка захвата доступа к 1SUPDTS
2. При попытке создать новый документ - попытка захвата 1SJOURN
3. При поытке создать элемент справочника - попытка заквата SC214 или 1SDNLOCK
3.1 Блокировка 1SDNLOCK возникает и при создании нового документа (видимо из-за нумерации что ли)

Ну с обменами не так часто и понятно потому что обмен я вижу.
С остальным все на так ясно.

Базы не малые, регистр RA328 подходит к 1.7 ГБ
Я так понимаю что многие проблемы из-за проведения документов задним числом ну и перепроведения если надо
Время ожидания захвата БД сброшено в ноль у всех вроде бы, но уточню. Может кого прозевал.
Заметил что в понедельник много потому что делают много приходов и в пятницу тоже.
Причем всем надо с утра.

На ПБ как-то особенно с этим всем проблем и нет а вот на ЦБ бывают, и неприятные
Мне бы хотя бы четко понимать из-за кого в любой конкретный момент времени возникает блокировка (за исключением обмена)
Тогда бы можно было его притормозить а другие бы работали дальше.
В ЦБ банк касса розница енвд перемещения поступления оптовые реализации комплектации и т.д.
Магазины для себя в ЦБ делают большие перемещения с Центрального склада.

Мне бы хотя бы четко понимать из-за кого в любой конкретный момент времени возникает блокировка (за исключением обмена)
Тогда бы можно было его притормозить а другие бы работали дальше !!!
   Андрей_Андреич
 
401 - 03.11.20 - 11:25
(385) Просвети, пожалуйста - для ДБФ прямые запросы с виртуальными таблицами (РегистрОстатки) работают так же, как и СКЛ?
   АгентБезопаснойНацио
 
402 - 03.11.20 - 11:27
(401) да
   tgu82
 
403 - 03.11.20 - 11:28
(401) Да вроде похоже через 1sqlite или vfpoledb, только я так понял что если я использую kernel33 или 37 для решения проблемы 1 ГБ то рпямые запросы через 1С++ могут и не заработать
   Андрей_Андреич
 
404 - 03.11.20 - 11:29
(402) Тогда ТС может перейти на прямые запросы в ДБФ и ускорить проведение в разы
   АгентБезопаснойНацио
 
405 - 03.11.20 - 11:31
(403) почему не заработают-то? ограничения на 1Г - это ограничения движка 1с, а не структуры хранения. а 1с++ использует драйвер фокса. Ну или 1склайт (в нем тоже ограничений нет)
   АгентБезопаснойНацио
 
406 - 03.11.20 - 11:32
(403) я тебе даже больше скажу - в режиме чтения ты можешь прямыми запросами к сколь угодно большой базе (в пределах ограниченй дбф и файловой системы, конечно) обращаться
   tgu82
 
407 - 03.11.20 - 11:33
(401) Очередь проведения дает управляемость и ликвидирует блокировки фактически. Ибо ждут пока предыдущий не закончит проведение.
Просто я никак не могу дотумкать как формировать очередь.
1. первый документ с утречка который проводится и блокирует служебный элемент
2. тут же второй с проверкой блокировки служебного элемента, пусть 20 циклов ожидания. Но ведь тут же и третий и т.д. Как эта очередь будет работать по времени? Пока гоняется 20 циклов - остальные не могут свои циклы проверять?
   АгентБезопаснойНацио
 
408 - 03.11.20 - 11:34
(404) я б сформулировал по-другому: "возможно перейти на прямые запросы". а может тс или нет - это совсем другая история...
   sdaf
 
409 - 03.11.20 - 11:35
(398) если не за сегодня проводили, то партии включались, а все что в течении текущего дня - нет. Но с проведением задним числом было строго. Ночью у тебя в монопольном режиме один день то за полчаса перепроведется. а в выхи перепроводилсось с ГП.
   tgu82
 
410 - 03.11.20 - 11:36
(408) Согдасен. Проблема не в переходе а втом что надо заново раскапывать что и зачем и как в модулях проведения и как все это увязывается. Время в-принципе есть конечно на это.
   Андрей_Андреич
 
411 - 03.11.20 - 11:36
(407) Если документы начнут проводиться в 10 раз быстрее - никакой очереди не возникнет. 40 человек
   АгентБезопаснойНацио
 
412 - 03.11.20 - 11:39
(411) причем у него практически все юзвери кроме банка долбят руками.
   tgu82
 
413 - 03.11.20 - 11:39
(411) Да не в этом дело, опять же новые проводятся за сотни милисек. А вот задние те долго раз в 20-40 дольше даже в монопольном режиме. Просто подскажи мне по повдоу очереди а то в моей голове она не до конца прояснена. Если вошел в ОбработкаПроведения - это означает что уже блокировка журнала началась или пока я не начнуб движениерасход или движениеприходвыполнить или движениевыполнить - все пока свободно?
   tgu82
 
414 - 03.11.20 - 11:41
(412) Ну да, это же логично а как еще? хотя реализации однйо кнопкой на основе заявок, поступления через загрузку файлов от поставщика большие. Или есть какие-то вообще автоматически варианты?
   АгентБезопаснойНацио
 
415 - 03.11.20 - 11:42
(413) когда Обработка проведения (или удаления проведения) началась - ты уже в трранзакции
   Андрей_Андреич
 
416 - 03.11.20 - 11:43
(413) На заднем проведении прямые запросы как раз максимальный выигрыш дают при расчете итогов.
   tgu82
 
417 - 03.11.20 - 11:44
(415) то есть если в этот момнет кто-то проводит уже сразу ошибка блокировки? То есть проверку блокировки служебного элемента надо делать вне этих процедур? Но тогда где? В каком месте проверять?
   tgu82
 
418 - 03.11.20 - 11:45
(416) Согласен. Давай попробуем. Окунусь в начало 2000-х опять )
   АгентБезопаснойНацио
 
419 - 03.11.20 - 11:45
(414) ну я ж говорю, у меня бегало с сотню торговых с планшетами, плюс прилетали заявки через EDI. Т.е. 95% заявок давали робот, принимающий с планшетов, и оператор, отслеживающий поступления от сетей.
   tgu82
 
420 - 03.11.20 - 11:47
(419) Ну это конечно другая ситуация.
   АгентБезопаснойНацио
 
421 - 03.11.20 - 11:52
(419) ну и 50-70 заявок делало вручную 4-5 человек из опта.
   tgu82
 
422 - 03.11.20 - 11:57
Звонят говорят что сегодня все спокойно да я сам вижу по журналу регистрации - нет ошибок транзакций сегодня кроме может милисекундных.
   Ёпрст
 
423 - 03.11.20 - 13:41
(401) нет. Там нет вирт.таблиц, все запросы руками. Можно конечно, через класс от вандслава писаиь, ноя им не пользовался, ибо у меня в конфе былм свои классы на перехватчике, ли и рукамииписаиь проще.
   Ёпрст
 
424 - 03.11.20 - 13:41
(403) неправильно понимаешь
   Ёпрст
 
425 - 03.11.20 - 13:44
Если не переписывать на прямой запрос, то делается период хранения 5 дней и привет. И любой твой докумкнт будет проводитсЯ в любом числе быстрее.
   Ёпрст
 
426 - 03.11.20 - 13:45
Как и получение любого отчета на чорном запросе
   АгентБезопаснойНацио
 
427 - 03.11.20 - 13:51
(425) лениво только каждые 5 дней период открывать. На сиквеле хоть можно автооткрытие сделать...
   Ёпрст
 
428 - 03.11.20 - 13:57
(427) ты не поверишь, но на дбф тоже можно не руками..
   АгентБезопаснойНацио
 
429 - 03.11.20 - 14:17
(428) пакетным?  честно говоря, не пробовал.
   tgu82
 
430 - 03.11.20 - 14:19
(428) Понимаешь есть у мення и учойс и унижурнал и сетаттр и реплвал которым я порой пользуюсь.
Но вот 5 дней в периоде - сильно напрягает почему-то
 
 Рекламное место пустует
   tgu82
 
431 - 03.11.20 - 14:30
(430)+ Ну а на магазинах - то же 5 дней? Или там можно месяц оставлять?
   tgu82
 
432 - 03.11.20 - 16:52
(428) А как делать квартальное перепроведение, ведь это сколько же периодов у меня откроется - порядка 20?
Открыть период-то не проблема даже роботом как-то
   hogik
 
433 - 03.11.20 - 17:21
(388)
«Я так понял что кернел33 обеспечивает только...»(с)
Верно поняли.
(390)
«То есть мне надо DBEng32 Ваше себе установить?»(с)
Не надо. 
«Заменить НачатьТранзакицю Попытка Исключение КонецПопытки ?»(с)
У нас ВСЕ (!!!) операции модификации БД были охвачены «Попыткой».
«Ставить на проведение в очередь? Каким образом?»(с)
Для ответа на этот вопрос надо смотреть Вашу конфигурацию. Но... :-) Что точно надо делать - это убирать из модуля проведения документа ЛЮБЫЕ операции по модификации БД кроме работы с регистрами, «проводками» и самим  только ЭТИМ документом. Во всех других случаях может/будет возникать "Взаимная блокировка (deadlock)" с тупым/бесполезным ожиданием средствами самой 1С, любым «решением проблемы 100%», Вашими «ручными» циклами с паузами.
«При чем тут учойс сетатрс или униджорнал?»(с)
Я не знаю что это такое.
(391)
«А как мне понять теперь уже у меня кернел33 используется или кернел37?»(с)
Сравнить файл с файлами из ZIP-а где скачали.
«Получается что если время ожидания в ноль то мне достаточно кернел33 для решения проблемы 1 ГБ?»
Да.
(392)
«Получается что при установке времени ожидания в ноль - кернел37 избыточна?»(с)
Больше того. :-) Вредна.
   tgu82
 
434 - 03.11.20 - 17:35
(433) Спасибо за развернутый ответ. Но вотту непонтяно ибо было очень давно и zip уже не сохранилось сохранили сами kernel33.dll и kernel37.dll  а вот что я использую увы теперь не пойму. И какие файлы патчились. Подскажите как уже тперь разобратся раз момент подошел.
   Ёпрст
 
435 - 03.11.20 - 17:39
(432) какая-то каша у тебя в голове, разобраося что ле, что такое регистр, как он устроен, что такое итоги останкового и оборотного регистра. И что такое открытие периода. И как получается остаток на  произвольную дату.
   Ёпрст
 
436 - 03.11.20 - 17:40
И чем получение остатка за произвольную датутотличается от получения остатка на ТА..и что вообще такое ТА.
   tgu82
 
437 - 03.11.20 - 17:46
(436) Ну стодбко лет с этим работаю - расчет регистра, ТА, остатка на ТА и тд - вроде понятно что к чему. Просто из-за перепродаж и работы задним числом приходится делать перепроведение базы за квартал (если 5 днеЙ) значит в месяц 6 открытий периода примерно - а может я и правда не понимаю что-то?
   tgu82
 
438 - 03.11.20 - 17:50
(435) Остаток на произвольную дату - остаток на ближайшую (скажем начало месяца+приход за время от начала периода до произвольной даты-расход за время от начала периода до произвольной даты)
   hogik
 
439 - 03.11.20 - 18:00
(434)
Выслал ZIP-ы на почту.
   tgu82
 
440 - 03.11.20 - 18:05
(439) Спасибо. Хоть сориентируюсь
   tgu82
 
441 - 03.11.20 - 18:06
(439) Пока не получил. tgu82@yandex.ru
   hogik
 
442 - 03.11.20 - 18:32
(441)
Блокируют. :-)
Повторил отправку.
Пароль на ZIP - hogik
   tgu82
 
443 - 03.11.20 - 18:34
(442) Да, каспер. Отключил
   hogik
 
444 - 03.11.20 - 18:36
Думаю yandex.ru блокирует.
   tgu82
 
445 - 03.11.20 - 18:37
ну да, не доходит, хотя если в архиве - должен пропустить по идее
tgu_82 скайп
Может через телеграм?
   tgu82
 
446 - 03.11.20 - 18:40
(444) Спасибо большое, дошло. Отпишусь
   Ёпрст
 
447 - 03.11.20 - 20:44
(437) при проведении документа никаких "открытий периода" нет.
А перепроводить что-то нужно в потоке, если что.
   tgu82
 
448 - 03.11.20 - 20:51
(447) Открытий периода нет, но переход на следующий период есть и порой долго переходит прежде чем проводить начинает уже в новом периоде, ну скажем за квартал - 4 раза, перед 1 месяцем, затем на второй, затем на третий ну и на четвертый на начало
   Ёпрст
 
449 - 03.11.20 - 20:59
(448) какой переход ? какой квартал ?
   Ёпрст
 
450 - 03.11.20 - 20:59
кто куда у тебя переходит ?
   tgu82
 
451 - 03.11.20 - 21:18
(450) Ну запустите групповое перепроведение документов и сначала будут итоги на начало пересчета причем даже если я считая с 25 числа, все равно он высчитывает итоги на 1 число а потом уже так идет до 25 числа.
   tgu82
 
452 - 03.11.20 - 21:18
В потоке - это в одном терминальном сеансе?
   tgu82
 
453 - 03.11.20 - 21:20
Каждый квартала я делаю групповое перепроведение документов один раз перед квартальной отчетностью (выгрузкой в бухгалтерию)
   tgu82
 
454 - 03.11.20 - 21:25
(453)+ Хотя же можно точку актуальности просто откатить и будет наверное намного шустрее перепроводиться. пробую прям сейчас
   Злопчинский
 
455 - 03.11.20 - 21:30
(454) конечно будет гораздо шустрее. у тебя не будет расчетов задним числом, все будет проводиться в ТА
   Злопчинский
 
456 - 03.11.20 - 21:31
другое дело если в базе трэш и угар - то будет затыкаться на проведении документов...
   tgu82
 
457 - 03.11.20 - 21:39
(456) Ну нет вроде треша никакого  - ведь перепроводится все более менее без проблем а те что есть - разруливаю сразу (типа заявка на склад по времени позже реализации на основе той заявки и т.д. Кстати в-основном приходится поправлять именно все эти запутки с резервами. И потом документы меня мало интересующие я вообще из перепроведения исключаю
   tgu82
 
458 - 03.11.20 - 21:44
(456) Если я откатываюсь на 1 июля то опять же долгго соображает с перенос остатков на 01.07.2020 - все это в копии конечно я делаю. В рабочей финальный обмен идет
   tgu82
 
459 - 03.11.20 - 21:59
(456) 33000 доков перепроводятся за 12 минут - это один месяц после того как ТА передвинул на начало этого месяца. В-принципе РКО ПКО и банк можно было бы не проводить но поскольку их вводят задним числом (банк) то после пересчета последовательность взаиморасчетов с контрагентами восстанавливается путем такого проведедния
   tgu82
 
460 - 03.11.20 - 22:01
(459)+ Опять перенос остатков на 01.08.2020 - долго а перепроводятся шустро
 
 Рекламное место пустует
   tgu82
 
461 - 03.11.20 - 22:39
(460)+ Как резуюме - почти 100000 документов за период 01.07.2020 - 30.09.2020 перепровелись вместе с переносами остатков за 50 минут.
Комп мой рабочий с hdd с 8 гб оперативки однопроцессорный win7-64 установлено, рейдов никаких нет.
Это хороший результат или не особенно?
   Злопчинский
 
462 - 03.11.20 - 22:45
(461) я думаю хороший
   tgu82
 
463 - 03.11.20 - 22:46
(462) А задним чисслом тормозит
   tgu82
 
464 - 03.11.20 - 22:51
(463)+ При интерактивном проведении - почему не пойму
   Злопчинский
 
465 - 03.11.20 - 22:59
(463) потому что заднее число. при проведении в потоке ТА - итоги просто читаются. при заднем числе итоги читаются+вычисляются. причем чем дальше вычисление от начала месяца -тем больше объем вычислений. поэтому перевод на периодичность в 5 дней существенно ускорит проведение задним числом.
   tgu82
 
466 - 03.11.20 - 23:02
(465) Я понимаю что ускорит, да надо пробовать на копии.
Ну и потоковое проведение или ты говорил ещекакие-то варианты - меня заинтересовало
   tgu82
 
467 - 03.11.20 - 23:08
(465) И от ПриЗаписи надо отказываться. Просто процедура и в конце Записать(), вот в ней все бухтовки автоперемещения и т.д.
   tgu82
 
468 - 03.11.20 - 23:44
(450) Переделываю в копии на 5 дней. Долго изменяется период. Жду
   Злопчинский
 
469 - 03.11.20 - 23:47
(468) это у тебя сейчас ВСЯ БАЗА пересчитывается на итоги в 5 дней. это может быть небыстро
   tgu82
 
470 - 04.11.20 - 00:05
(469) Да, это я понимаю
   Злопчинский
 
471 - 04.11.20 - 00:10
(470) це успix!
   Ёпрст
 
472 - 04.11.20 - 00:49
(468) Прерывай процесс, удаляй все rg***.dbf и rg***.cdx и запущай заново. Будет быстро, если итоги норм закрываются
   Злопчинский
 
473 - 04.11.20 - 02:46
(472) тьфу, точно, так быстрее будет
   tgu82
 
474 - 04.11.20 - 08:17
Да, точно. Прорву сейчас. Ночь прошла. Еще идет. А может пусть идет, интересно когда он завершится
   Андрей_Андреич
 
475 - 04.11.20 - 08:17
(465) Еще и "Регистры.Актуальность(1)", за что писателям типовой ТиС памятник прижизненный из навоза.
   tgu82
 
476 - 04.11.20 - 08:19
(475) Это да. Придумали на нашу голову.
Если RG удалить то они же сформируются потом на основании RA
   АгентБезопаснойНацио
 
477 - 04.11.20 - 08:21
(475) при нормальной реализации - почему бы и нет?
впрочем, архитектура 98 года, и ждать там нормальной реализации странно.
   tgu82
 
478 - 04.11.20 - 08:39
Удалил rg установил 5 дней и теперь пересчитываются итоги но медленновато что-то хотя комп обычненький
   tgu82
 
479 - 04.11.20 - 08:44
(478)+ Получается 360 точек итогов. интересно когда же они пересчитаются
   Злопчинский
 
480 - 04.11.20 - 10:16
(477) да по сравнению с текущими типовыми ТИС образец практически вылизанности
   АгентБезопаснойНацио
 
481 - 04.11.20 - 10:23
(480) я про архитектуру платформы.
   tgu82
 
482 - 04.11.20 - 10:46
Пока пересчиталось 50 с лишним периодов. Сентябрь 2016 заканчивается
   tgu82
 
483 - 04.11.20 - 12:15
(482)+ За три часа один год
   tgu82
 
484 - 04.11.20 - 13:25
(483)+ Нужны почти полные сутки а еще ведь по каждому магазину тоже надо переделывать на 5 дней. То есть вроде вариант а фактически не вариант все-таки
   Ёпрст
 
485 - 04.11.20 - 13:42
(483) год пересчитывается 10 минут или меньше, не помню уже, в комплексной, с задвоенными записями иирегистрами, а не какой-то там голый тис. И у нас размер вмех дбф примерно 21 гиг был. У тя просто или комп целерон, или регистры не закрыты/есть строковые измерения
   Ёпрст
 
486 - 04.11.20 - 14:32
дай хоть *.dd посмотреть от этой базы
   tgu82
 
487 - 04.11.20 - 14:39
(486) Куда прислать dd?
   АгентБезопаснойНацио
 
488 - 04.11.20 - 14:42
(484) хосспадяяяяяяяя... ну сделай в конце концов для каждого магазина файл регистра остатков за последнюю декаду, подмени штатный, и запрети лазить больше чем на 10 дней.  ПОтом пересчитай в каждой копии все, и подмени взад. ну и пересчитай последние 5 или 10 дней тупой сдвижкой ТА.
   Ёпрст
 
489 - 04.11.20 - 15:08
(487) на любую файлопомойку, ссылку сюда
   Arbuz
 
490 - 04.11.20 - 17:04
(359) >есть только в ПриЗаписи чтоб в единой транзакции все было иможно было откатиться.
Дык, у него там вся разбухтовка считается в транзакциях! Я правильно понимаю?
плюс, в модулях проведения много лишних телодвижений понадобавлено.
плюс, работа задним числом.
Вот и тупит оно адски.
   tgu82
 
491 - 04.11.20 - 19:02
Хорошо, точно не сообразид )
   tgu82
 
492 - 04.11.20 - 19:02
пока 01.01.2018 05.01.2018 идет
   tgu82
 
493 - 04.11.20 - 19:07
   tgu82
 
494 - 04.11.20 - 19:16
(488) Ну сделай в конце концов для каждого магазина файл регистра остатков за последнюю декаду
Думаю )
   tgu82
 
495 - 04.11.20 - 19:24
(490) Гуру провел тесты и выясник что ПриЗаписи к транакциям отношение не имеет
И пришёл к выводу, что само МЕСТО (процедура ПриЗаписи) создания документа не порождает конфликтов и клинчей.

Я думаю что если документов в понедельник с утра до фига и часть из них задним числом и проводится 3-4 скунды а то и больше то вот отсюда блокировки и лезут. Все время пытаются жать кнопку ОК, их отшибает по ошибке Они говорят Да и их может опять отшибить по ошибке. Уступать друг другу не хотят уж точно. Хотя может дело в чем-то еще
   tgu82
 
496 - 04.11.20 - 19:30
(490) Нет транзакций явных при разбухтовке. Там просто ДокБухт.НОвый(), Записать(), Провести()
Но никаких транзакций в ПриЗаписи нет явных нет а где были я их повыкидывал.
   Злопчинский
 
497 - 04.11.20 - 19:34
(495) сделай как я сказал - при открытии дока - если док существующий и нет изменений - все кнопки ОК, Записать, Провети - сделать недоступными. в доступность переводить только если что-то в документе поменяли. вот как начнут в первый день после изменений звонить что кнопки не нажимаются - вот и понятно откуда транзакции.. ;-0
   tgu82
 
498 - 04.11.20 - 19:36
(497) если док существующий и нет изменений - все кнопки ОК, Записать, Провети
Ну это друг другу противоречит. Или  ты имеешь в виду что модифицированность=0 то есть
ничего с ним не делали а если делали то открывать кнопки к доступу
   Злопчинский
 
499 - 04.11.20 - 19:44
(498) да
   tgu82
 
500 - 04.11.20 - 19:54
(499) Согласен тут бы еще знать где попытка исключение конецпопытки выставить, заменить ими начатьтранзакцию зафиксироватьтранзакцию
  1  2  3  4  5  6  7  8   

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