Решение проблемы 100% загрузки процессора при ожидании транзакции (ВК+перехват DLL) #170627

Компонента с исходным кодом (Delphi 6) и тестовой конфигурацией выложена здесь:

Компонента с исходным кодом (Delphi 6) и тестовой конфигурацией выложена здесь:

Компонента с исходным кодом (Delphi 6) и тестовой конфигурацией выложена здесь:

Компонента с исходным кодом (Delphi 6) и тестовой конфигурацией выложена здесь:

Компонента с исходным кодом (Delphi 6) и тестовой конфигурацией выложена здесь:

Компонента с исходным кодом (Delphi 6) и тестовой конфигурацией выложена здесь:

Решил посмотреть, что же происходит, когда 1С ожидает блокировку. Создал простейшую конфу, в которой есть всего один документ. В модуль проведения вставил Предупреждение, чтобы она останавливалась и все блокировала. Открываю другую копию той же конфигурации, и пытаюсь создать новый документ. (или провести старый). 1С в этом случае загружает проц на 100% и крутится в непрерывном цикле, опрашивая время.

так что делает компонента, я так и не понял?

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

Устраняет 100% загрузку процессора, когда кто-то проводит документ, а кто-то второй пытается тоже начать его проводить.

(+4) Точнее, когда один юзер проводит документ, а другой пытается создать новый документ или провести другой документ - тогда в терминале (да и не в терминале тоже) все, что называется, встают.

"устраняет" - вот это не совсем понятно, как она обходит платформу или что она делает (конечно можно исходник посмотреть, но может в двух словах... а то мне SoftIce, увы, ни о чем не говорит)

Короче 1С-ка непрерывно долбится в функцию KERNEL32!LockFile, и пытается заблокировать файл. Программисты забыли вставить вызов sleep, и поэтому при многопользовательской работе в 1С включаются тормоза.

Я перехватываю системный вызов GetLastError - возврат последнего кода ошибки. Если он равен 33 (21h), то я включаю паузу на указанное (при вызове внешней компоненты) количество миллисекунд.

ага, понял, а ты этот вызов обходишь?

+9 все, уже прочитал

Я взял этот код из дампа (см. выше): Код ошибки 33 MSDN расшифровывает так: 33 The process cannot access the file because another process has locked a portion of the file. ERROR_LOCK_VIOLATION

Инициализация компоненты в коде 1С:

т.е. проверка "проведенности" будет производиться не в вечном цикле, а с интервалом 1с, так?

Короче, если кто-то другой проводит документ, то ты не можешь провести свой документ, и не можешь создать новый документ - 1С-ка ждет в цикле, пока другой пользователь не освободит таблицу. Я вставляю паузы sleep, которые не потребляют процессорного времени. Получается, что ожидание происходит с минимальной загрузкой проца и сети.

спасибо, дошло :)

по ссылке есть исходники и пример, но нет самой компоненты TerminalSleep.dll ?

Посмотри сейчас.

а ты компоненту свою потестировал в разделенном режиме :-) ?

спасибо.

Запускал 2 копии одной конфы на одном компе. Как еще тестить, пока не придумал. Блокировку ловит, что видно из отладочной печати.

Загруженность процессора должна упасть до 0. Ты в Диспетчере задач ее смотришь?

Точнее, время ожидания захвата таблиц = 15

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

Ты в обработчике нажатия на кнопку (к примеру) можешь вызвать событие? Еще вариант - событие попадает в форму справочника, т.к. там есть его обработчик.

Т.е. там можно и вписать продолжение алгоритма, если вызвать событие с особым названием, и в кач. параметра передать нажатую клавишу.

в "другом" - ничего нет вообще, чисто. А в обработчик события отладчик не идет КонецПроцедуры вот сюда попадает и все глСервис.ВнешнееСобытие("FormEx","ВводСимвола",прм_Символ);

это только для дбф ?

Хм, к сожалению нету у меня сегодня xp sp2, завтра посмотрю. На всякий случай, у меня 25 релиз 1С. DBENG32 7.70.0.14

а если не через файл, а через сообщения или реестр?

Надо чтобы на разных тачках его было видно. Файл-сервер же :-)

Там короче надо открыть две копии конфы, в одной из них начать проводить документ, а в другой попытаться создать новый док. Без ВК загрузка процессора под 100%, с ВК загрузка = 0 (или близка к 0).

Отправил на адрес, который у тебя в карточке :)

Кстати, скачал и попробовал на ХР 0) Загрузка проца с ВК - от силы 2%.

+103) а без ВК - 52%. Проц Интел 3000, памяти 1Г. Здорово!

ладно пользователь нажмет несколько раз повторить, а если работает обработка например обмена с клиент-банком, то она прервется с ошибкой.

ну да прирвется. Она спросит повторить или нет, но при этом не будет 100 процентного висяка.

не спросит, если самому через исключение не обрабатывать

не так конечно лучше никто не спорит. Ладно будем ждать под СКЛ решение :)

Ром, а 102) смотрел?

В 0 тоже можно убрать. Однако хотелось бы чтобы работало по-человечески, и была возможность прервать массовую обработку, когда юзер запрашивает проведение своего документа. Нет еще, тока пришел, щас гляну..

Вообще кто ж грузит компоненты не в попытке ))

Под СКЛ когда можно будет тестировать ? Я готов стать тестером.

Да я специально вынес в параметр - кому как больше нравится. Помимо загрузки процессора, есть еще такая фишка, как задалбывание сервера лишними запросами - не факт что они кешируются, и не приводят к сбою позиционирования головок HDD, когда кто-то слишком часто долбится в одно и то же место... Да, наверное можно (даже лучше) и так - иначе приколы с языком раскладки в обычном SendKeys.

Протестил - порадовало )) Была проблемма с одно кассой - вечно че-то там захватывала, чеки с трудом проводила, ща крсиво все стало :)

А что именно ты тестил? Для SQL или для DBF?

Ну не знаю, я 8-ку боюсь :)

А можно ли в файл который пишется на диск при транзакции, писать имя пользователя? или любую информацию, которая поможет определить кто создал данную транзакцию

Так что скажешь насчет ситуации, когда время ожидания в параметрах установлена в 0? Я всегда подозревал, что это не выход - надо процессу дать шанс подождать... 15 сек. + компоненте будет гламурнее?

Эта проблема была решена давным-давно без всяких ВК.

и как?

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

Да счаз.. Ты не работал с большим числом пользователей на терминале. все 4 сожрет если пользователей много и представь 4 сессии начнут проводить доки, и распиханы эти 4 сесии по разным процам вот тебе и 100% загрузки сервака со всеми его процами, 5й пользователь начинает проводить док, на том проце, который проводит в данный момент: как результат - у того кто проводил было 25% проца, стало 12,5% еще лдин влез, и в результате имеем полностью остановившуюся базу т.к. заблокировано все из-за проведения, и допровестись проблема, т.к. несколько сессий отжирает проц этими циклами.

ну ситуации разные бывают.

Ты сам че-то зацикливаешься без пауз. :-)

погонял на рабочей базе при работе 20 пользователей с групповым перепроведением-работает нормально. задержка 10мс, время ожидания захвата 30с. единственное уточенние - путь к маркерному файлу надо указывать полный или относительно каталога ИБ, иначе он будет создаваться в рабочих каталогах пользователей, и обработка группового проведения их не увидит, а будет видеть только свой собственный файл, хотя даже при отсутствии проверки на файл документы у пользователей проводятся без задержки.

Ты че-то маленькую задержку ставишь имхо. Я бы поставил секунду-две. Это опрос заблокированности таблицы, который завершился неудачей (объект заблокирован). Если объект свободен, то и паузы не будет. Слишком часто долбиться в одно место на диске - как бы дыру в нем не прожечь :-)

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

+ Подтверждаю тормоза в ТиС (dbf) при подборе номенклатуры и даже при перемещении по перечню номенклатуры внутри документов. Изменение времени Sleep результатов не приносит.

DBF. работа в терминале. не важно, есть проведение в данный момент или нет... т.е. на мой вгляд происходит слип опроса всех таблиц...

Ок, спасибо, вечером посмотрю.

Патч только для 7-ки, и он исправляет явную ошибку 7-ки. К 8-ке он не имеет отношения, и работать там и не должен.

см.

:-) убедил. Твое лучше.

могу предполодожить что ошибка в HANDLE WINAPI CreateMutex( ); я как то делал в тестовых целей для себя ВК работающей с mutex, так, надо было верно создовать. могу вечером посмотреть как было дело. так вот, с Mulex1C возникло ощущение, что не верно инициализировался мутекс, и сессии под другими логинами его не видели.

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

под SQL не тестировалось, в dbf нормально ждем твоих исправлений для dbf. Кстати и в текущем варианте тормозов не замечено в справочнике. Конфа самописная, транзакции исчезли :) за что большое спасибо.

Предложение модератору открыть новую ветку - уж больно "тяжела" страница для закачки ч/з Dial-up (настроек по разбиению на страницы не нашел) И еще хотелось бы услышать о другом подходе к решению проблемы блокировок для SQL - именуемое как "гибкие блокировки". У кого это чудо работает и может быть даже подкинуть идеи тем кто только на этот путь становится...

Не пробовал нажимать в 12345>> рядом с темой?

Ром! А можно узнать, как самому получить файл odbc33.txt из своей 32-й длл-ки, чтобы сравнить с той, что лежит в архиве?

tdump.exe ИмяDLL ВыходнойФайл

(208, Drok) Обновил компоненту для DBF, вставив проверку на источник вызова (смотрю на вершину стека, что там лежит). Проверить не на чем, т.к. у меня пролистывание справочников и журналов не тормозит. Если торможение будет продолжаться, прошу выслать справочник (перетащите его мышкой в пустую конфу).

Компонента лежит по адресу: Я добавил текстовое описание (порядок установки) и разделил на две папки с версиями для DBF и SQL.

Результы теста: 2-х головый XEON 2.0, 8 гиг ОЗУ, SQL DE, Win2003 EE. До патчинга скачек при блокировке транзакции до +40% (у сервака еще своя боевая нагрузка была). После патчинга... Скачков при блокировке небыло вообще. Delay оставил по умолчанию - 1000. Тест провел 3 раза. Каждый раз получая одинаковые результры. Огромный респект автору.

Тоже пробовал компоненту Ромикса - положительный эффект есть, отрицательные есть, но несущественны.

ну что, восьмерку не смотрел еще?

Тестировал на сервере, через терминал. Большого смысла патчить клиентские 1С ИМХО нет смысла. Пользователь обычно работает только с одной 1С. А для терминальника самое то. Сегодня вечером пользователи свалят из базы, поставлю в боевом режиме.

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

(+258) 8-ка жж0т. Интересно, в 8-ке для SQL эта проблема тоже дает о себе знать?

Проблема у меня не воспроизводится. Что именно вы делаете? Можно ли простейший случай на "почти пустой" базе? Есть идея: перехватывать появления окна: --------------------------- 1С:Предприятие --------------------------- При выполнении транзакции произошла ошибка! Таблица: 1SJOURN Ошибка обращения к данным при транзакции, выполняемой другим пользователем Повторить попытку выполнить транзакцию? --------------------------- Да   Нет   --------------------------- Вместо вывода окна делать паузу, и имитировать, что пользователь нажал Да. Тогда будет работать независимо, SQL или DBF. Для достижения полезного эффекта потребуется выставить время ожидания захвата таблиц в 0.

Да собссно я имел ввиду не смену приоритета у задачи, а переключение на другой процесс, т.е. при любом обращении к системе вызывающий процесс принудительно освобождает процессорный ресурс, вплоть до ближайшего прерывания RTC или таймера внутреннего шедулера. Я работал с ОС реального времени, там эта процедура выполнялась всегда.

Обновил патч для DBF - теперь он сделан не как внешняя компонента, а как патч+заменяющая DLL. И перехватывает окно (предупреждение) с ошибкой. Подробности - в readme.txt внутри архива .

Восьмерка у тебя явно неактуальный движок.

Я кажется понял, из-за чего у тебя тормоза. Возможно, ты не поставил патч SQL на 1С-ку, которая делает массовое проведение доков. Кстати, административная установка - это всего лишь, когда папка BIN лежит на сетевом диске (и открыта юзерам только на чтение). А у юзеров на рабочем столе - только ярлыки в эту папку.   А зашли мне плиз DBEng8.dll от новой версии 1С-ки... Я заценю что там новое.

У меня три терминал сервера на которых локально установлена 1С. Административных установок у меня вообще нигде нет и я ими не пользуюсь. На одном из терминалов, самом мощном, стоит и лежит база SQL. Файл от восьмерки вышлю завтра.

Давай. Для DBF-ной базы 7.7 сейчас все проблемы я думаю решатся (т.к. я в новой версии перехватываю всего лишь окно сообщения, не вмешиваясь глубоко в движок 1С), а для SQL-ной - надо еще смотреть. Лог могу приделать, какие SQL-запросы приводят  к блокировке. Может у тебя там периодические реквизиты воду мутят...

Апаю. Внедрили в рабочей базе. Без траблов. СУПЕР!

Ну здорово... Т.е. у вас убрались частые блокировки при транзакциях?

Ну да, операторы теперь не тормозят, когда проводят документов кучу...

Т.е. обработка массового проведения теперь не тормозит работу пользователей? Или у вас так много пользователей, что они друг дружку все время тормозили?

Пользователей - порядка 30, активных - человек 10. Операторы, когда набивали заказы, расходы - загружали весь процессор, сидели в ожидании и "нервно курили (с)". Теперь - тормозов нет. Еще раз спасибо.

Да не за что.. Я просто не понимаю откуда такой сильный эффект. У вас терминал + SQL? И они курили, когда кто-то массово перепроводил документы обработкой, или даже без перепроведения обработкой - тоже курили?

Да я думаю партнеры напишут, если окажется, что сеть 1С после этого работает намного лучше.

В старых операционках (RSX-11 и др.)файл хранился в нескольких версия. И всегда использовалась самая последняя. Так, что идея хорошая! :)

Роман, если сделаешь и - цены твоему творению не будет!