1c v7.7 ошибки транзакции - как отловить виновника? #558772

Вопрос наверняка не новый... Так что если уже было, ткните носом pls - поиск не дал нормальных результатов. Итак - есть база 1c v7.7 (самописная конфа для страхования на базе бухгалтерии). Периодически у пользователей возникает ошибка при проведении транзакции. База работает по терминалом. Нагрузка на дисковую подсистему небольшая, CPU на нуле, RAM до черта свободного. Ну да ладно, это к делу не относится - железо менять все-равно никто не захочет. Вопрос вот в чем - как отловить инициатора первой транзакции которая всех держит? В случае с sql базой все достаточно просто... А вот как это сделать с dbf версией? Пробовал использовать утилиты handle.exe (sysinternals) и openfilesview (nirsoft), но толку мало - они показывают все текущие открытые хэндлы без указания типа блокировки (вернее последняя утилита пытается их показывать, но они всегда одинаковые для всех пользователей и толку ноль). В то же время при использовании procmon (sysinternals) видны явные отказы на Lock file при попытке проведения транзакции, но вот кто конкретный файл залочил первым отследить с помощью нее в боевых условиях, при большом потоке запросов на блокировку практически нереально. Лог же 1с стандартный вообще в этом деле не помошник. Итак - как мне выкрутиться? ;)

Маленькое добавление - я не имею права и не могу лезть внутрь конфы и модифицировать ее (УРБД, филиал).

Документ, который проводится дольше всех

+ Посмотреть нет ли где в процедуре проверения Вопрос

Мне нужно отследить не документ, а пользователя. Есть подозрение, что во время проведения документов происходит дедлок с последующим подвисанием 1с и блокированием таким образом остальных транзакций. Мне нужно иметь возможность оперативно выявить пользователя-"виновника" и убить его. Сейчас приходится тупо срубать всех :(

Нет, вопросов нет. Но модули написаны так, что при вылете по таймауту при ожидании транзакции 1с остается в "подвисшем" состоянии, такое ощущение, что теряется фокус ввода.

Ошибки, кстати, возникают в основном на 1supdts

А сколько пользователей?

в недавнем прошлом тоже возникали транзакции! помогло дефрагментация индексов.

это сколько же гигов-то индексы весят?:)

Да, кстати самое нлавное, а как работают юзеры, терминал или локалка? Если локалка по возможно у кого то "прыгает" связь

*главное

1).мне ненужно сейчас решать проблему транзакций - способы с дефргаментацией, переписыванием модулей, увеличением мощности железа и т.д. меня сейчас не интересуют ;) все, что мог я уже сделал, а на большее денег все равно не дадут. а вмешиваться в саму конфигурацию я не имею права. 2).база работает под терминалом - смотри выше. 3).дефргаментация всей директории с данной конркетной базой производилась не так давно; У меня вполне конкретный вопрос - как отследить инициатора зависшей транзакции?

Каким образом 1с v7.7 производит блокировку dbf файла? Записывается какой-то признак в lck файл? Или просто производится открытие dbf файла с запретом записи в него другим?

"Ошибки, кстати, возникают в основном на 1supdts" а сколько она весит?

2 andrewks: 26 mb dbf, 16 mb индекс

на ответь

компоненту ромикса ставь и всё будет нормуль

пользователей 15-20 в заивсимости от времени дня... только какое это имеет отношение к делу? ;) конфа же все равно не типовая и прогнозы по ней давать на основании колва пользователей дело неблагодарное.

И у каждого пользователя свой каталог...?

ну вот это точно не имеет отношение к делу из : "CPU на нуле", да и подглючивает она. уж лучше таймаут по нулям выставить

Уверен?

в чём?

апдейтс 26 метров - это надо круто наколбасить. обмены принципиально не ведутся, чтоль?

и вообще, имхо, ошибка та же, где и всегда...

может даже около годика

порядка миллиона измененных объектов...

2ZOMI: еще раз - у меня нет проблемы 100% загрузки CPU. стоит аналог компонента ромикса - vk_sleep_1C, вшит в конфу. 2Kondrat: каталоги у пользователей у каждого свой. 2Mikeware: обмен ведется регулярно каждую неделю. не задумывался над объемом этого файла, покручу его подробней после обмена. но ругается то при блокировках не только на него, просто он чаще встречается.

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

хочешь сказать, что у тебя миллион объектов изменяется за неделю???? :-))

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

2Mikeware: не проверял насчет миллиона, но несклько сот тысяч более чем реально.

2Mikeware: но более вероятен другой момент, что-то глюкануло в УРБД, так как файлы обмена обычно достаточно небольшие - около 20 мб. как можно вычистить зависшие записи из 1ssupdts?

ой сомневаюсь, что "что-то глюкануло".... да и за файлик в 20 метров я б тоже по голове не погладил... разве что если только ногами...

ну насчет по голове не погладил - у меня регламент, утвержденный свыше и я его исполняю ;) если в ЦО хватает мощностей чтобы за ночь втянуть файлы такого размера в ЦБ с 40 филиалов по всей стране - почему бы и нет? ;)

обмен, фактически, односторонний ПБ->ЦБ, обратно спукаются только общие справочники, изменения в конфигурации, плане счетов и т.д.

ну и возвращаясь к первому моему вопросу - есть все-таки документация как именно 1c осуществляет блокировку dbf файлов и по каким признакам можно отследить кто инициировал "зависшую" транзакцию?

1. Сколько юзеров ходят в базу 2. все ли по терминалу? 3. смотрели вы средня скрость записи на диск и среднюю очередь итп? 4. как часто индексы считаете 5. делаете ли архивацию лог файла 6. есть ли возможность делать обмн по чаще? 7. Если возможнсть передащиь чась юзеров  на локал или на др терминал? 8. думали ли вы скуль поставить.

посмотрел сейчас колво записей в dts - 791 тыс ;)

ничего не поможет. тольок танцы с бубном. Обычно  если все на терминала виновник это второй и последующие юзеры. Надо просто разделить всех на разные терминалы.

2Обработка: 1).15-20 в зависимости от времени дня; 2).да, все в терминале; 3).смотрел, все в норме. есть пики, но краткосрочные; 4).раз в два-три дня, ибо периодически с утра предлагает пересчет ;) 5).нет, пока не было? каким образом это может отразиться на ситуации? 6).теоритичсеки можно договориться с ЦО, практически пока не пробовал; 7).есть, но тогда пойдет сетевой обмен с базой, что еще больше ухудшит ситуацию с транзакциями; 8).думал, пока нет возможности; о скулем в плане отслеживаний вообще бы вопрос не возник, все просто.

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

кстати глянул сейчас 1supdts - около 250тыс записей с DWNLDID равным 0. это чего такое?

Поясню. Все сидят в терминале. В какой то момент несколько человек проводят документ. Кто запустил втрой по очереди котрый не дождался времени ожидание тот как раз начинает отжирать проц. третий и по цепочке. Первый может удачно провестись но все остальные песпорядочно начинают виснуть. И не важно кого ты выловишь второго или третьего или четвертого . Кого бы  ты не выкинул уже процесс лихорадосного зависона начальось. быть может придется тебе по очерди убивать почти всех и толок на последних двух отвиснет. Допустим очередь выстроились 5  6 человек.

на счет  перевести с терминала в сеть это не однозначно. Бвыает случаи. 1. Перход слабой сети и не равнозначных раб статци к хорошему и борому серверу терминалов убавляет на проядок зависоны связанные с тразакцией. 2. И наоброт слабый страры сервер терминало может оказаться хуже чем нормальные раб станции и хорошая сеть.

2Обработка: блин, ну говорю же - нет у меня проблемы 100% CPU. далее по поводу очереди - первый начал транзакцию, остальные висят и периодически проверяют базу на доступность, первый отпустил транзакцию - тут да, первым может успеть пролететь шестой, а не второй, но это мелочи - мне в любом случае нужно поймать того, кто находится на вершине этого своеобразного стека и который тормозит остальных, а он в единицу времени ВСЕГДА один (ну если, конечно, транзакция не затрагивает разные объеты). Разделить на два терминала можно, но толк вряд ли будет - основной сервак сейчас вполне хороший, ресурсы и на 10% не используются, под базу выделен отдельный RAID1 на sata. Второй сервак слабенький, но связан с первым гигабитом. Чисто теоритически можно попробовать, но эффект сомнителен - узкое место скорее всего все-таки hdd и "зависший" ПЕРВЫЙ.

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

ну если у вас проц многоядерный то у вас нагрузку проца не покажет выше 25% или 50%

1С+ прекасно все отслеживает. Ее dll-ки на инфостарте лежат...

1. поставь время ожидания всем "нуль" 2. найди приблуду в гугле который что-то патчит и после этого не происходит лавинообразного тормоза с базой при транзакциях. 3. делай по чаще переиндексацию. 4. делай бекап архива лога в мониторе 5. строго проинструктируй пользователей при выходе сообщения про транзакцию пусть нажимают "отмена" а не "ок". А после через несколько минут нажимают перепроведение заново. 6. организуй по чаще обмен. 7. выставь счетчики на сервере найди узкое место. 8. сообщи центру пусть займутся опитимизированием кода проведения. Есть же варианты раздельного проведения. 9. по возможности сворачивай базу чаще не раз в 5 лет а раз в год. разгрузи сервак если там есть затык в производительности. обычно 20 человек на одном терминале это тяжко если еще тот сервак не очень сильный, кстати какие у него характеристики?

ни разу не сталкивался... требуется модификация конфы? если да, то не пойдет :(

Передо мной поставили задачу вскопать огород. Денег, чтобы наннять трактор или работяг с лопатаим не дают, а сам я не имею права. Не понимаю как можно чем-то помочь?

Кстати, табличка 1supdts отвечает за обмен УРБД. Он у вас реально ходит? Если ходит, то есть мнение, что кто-то где-то много перепроводит документов и потом это все льется блокируя базу.

да все знают. Ну, или почти все. Только тебе это не поможет... размер записи в апдейтсе - ровно 26 байт. не учитывая заголовок, при размере файла 26*1024*1024 записей в нем должно быть 1024*1024. это еще невыгруженные. остальные - неподтвержденные.

естественно. в курсе ;) я смотрю загрузку по каждому ядру. 5). вот это хорошая мысль, попробую. я понимаю абсурдность ситуации, но меня интересовал конкертный вопрос о том, как отследить инициатора транзакции... а мне почему-то все пытаются объяснить как бороться с самим транзакциями. почему у нас народ не читает тред сначала, а по новому кругу начинает советовать то, что обсуждалось выше? ну так киньте ссылку с описанием этого мехнизма ;) По поводу сервера: S3420GPV, QuadCore Intel Xeon X3440, 2666 MHz, RAM 8GB, база на отдельном RAID1 sata.

Чую что проблема в коде базы. А точнее в самой архитектуре базы. НАверно все на бух проводках сделана база???

Я код сильно не копал, но с вероятностью 99% да, на бух.проводках. Во всяком случае регистры точно не используются ;)

Ну так что - кто-нибудь ткнет меня носом в доку с описанием методов и способов, которыми 1с осущесвляет блокировку dbf файлов и каким образом можно отследить владельца текущей транзакции?

такой "доки" в принципе нету, ибо 1с эту инфу по понятным причинам не раскрывает. Однако реверсировали и разобрались. Ищи на софтпойнте. Только тебе это не поможет - как минимум по двум причинам.

обратись к hojik на ИС

вы уже два раза сказали, что мне это не поможет ;) может сразу расскажите причины? ;) ИС - это что?

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

а я бы всё-таки в порядке бреда посоветовал, если есть такая возможность, погонять базу в реале на другой железяке. иной раз сталкиваешься с необъяснимыми вещами. вот, например, недавно столкнулся у знакомых: новый сервачина, фирменный hp proliant, на вынь2к3, рэйд, памяти предостаточно. и вот очень долго на нём пишется ТиСовский мдэшник (когда сохраняешь конфу). при этом антивири и вири отсутствуют как класс. всё остальное летает. т.е. в целом все операции с 1с в разы быстрее стали делаться по сравнению со старым серваком, КРОМЕ сохранения мдэшника, который стал сохраняться в четыре раза дольше, хотя на старой железяке антивирь был. мистика, копаться до причины лень было, но на проц точно нагрузки нет. вот такие случаи бывают. так что попробуй, а мало ли, вдруг проблема исчезнет?

В условиях задачи (нельзя менять код, база дбф) - решений нет никаких!

ok, спасибо. на другом железе попробовать возможности нет. Из вышеприведенных комментариев я делаю вывод, что в dbf версии 1c v7.7 (без установки дополнительных примочек типа 1c++) невозможно мониторить текущие транзакции и их инициаторов?

вианая 1Ска вроде как на CodeBase основе - чел из 62 в теме...

С 1С вообще проблема - запустил на сервере полный пересчёт итогов - так 1С несколько часов "что-то делала", при этом нагрузка была не более 50% (реально 13, но процессор четырёхядерный - то есть одно ядро грузилось на 50%). При этом, было, конечно, много обращений к диску, но дисковая подсистема не была полностью загружена, так как обращение что с перерывами. Возникает вопрос - что делала 1С ? (Есть предположение, что включённый дисковый кеш приводил вместо обращения к диску к простому перемещению данных в памяти командами блочного копирования, что процессор сильно не загружает).

Чегой? Расшифруйте pls...