Оптимальное время ожидания захвата таблиц базы данных #15917

1сv77,Цитрикс,выделенный сервак на Ксеонах,DBF,30 активных юзеров, торговля самописная,активное создание и проведение документов.Исходя из опыта, САБЖ?

2 ноль

При таком значении вываливаются сообщение..

Очень интересный вопрос. Кажется, МуМу писал, что если > 0, то база вместо того, чтобы спокойно подождать (поспать, что ли) во время ожидания в бесконечном цикле долбится в очередь и сильно загружает процессор абсолютно бесполезной работай, в результате очередь увеличивается....Хотя, с другой стороны, ошибки пугают юзверей...

Ну так поделитесь опытом.

Больше 15 секунд врядли есть смысл ставить, лучше меньше.

Юзеров до 25, выделен терминальник без цитрикса - 25 сек.

Имхо под терминалом лучше ставить как можно меньше.Подробнее мое имхо на http://openconf.itland.ru/vk/priorСообщения об ошибках блокировки таблиц юзеровне пугают при должном их инструктаже.Пусть уж лучше оно сразу выскочит, чем в течении 30 секгрузить проц на 100% в призрачной надежде разблокировкитаблиц. Ну и конечно плюс максимальное ограничение работызадним числом. Если самописка грамотная, этого почтивсегда достаточно.

опытным эмпирическим путем:1-3 секунды, 0 не всегда удобно

(orefkov) У тебя не наблюдалось нестабильности работы 1с, с этой компонентой? У меня в терминале, W2003 при попытке использовать её, начала периодически вываливаться 1с-на, непонятно даже в какой момент. Релиз 1с-ки 19.

Мое ИМХО. Все это что мертвому припарка. Грузит проц 1С независимо от времени этого параметра другое делол что сообщение о захвате с разной частотой появляется.

10 А разве после вывода сообщения она грузить не перестает???

сейчас стоит 15 сек.А при попытке открыть Сервис-Параметры 1С вываливается молчаком, но не всегда.Используются несколько ВК, может из-за них?

дело говорит.

дело говорит.

В терминалке компонента орефкова уменьшает нагрузку на сервак очень существенно. Мне пришлось её отключить ввиду нестабильности :(.Вот хотел-бы услышать может кто сталкивался с такой проблемой.

То 11. В том то и дело что пользователи не зависисмо от инструктажа все равно долбят на кнопку проведения как обезьяны.(проверенно практикой:)) Конкретно проблему 100 процентов эллементарно решить с помощью установки lock time out на определнное значение больше 0.(вот в этом случае важно что бы оно было больше времени ожидания в 1С.) А вот проблема блокировок вообщем решается хоть и сложнее но эффективней черезhttp://serduk.ru/article.php?id=1

Статья хорошая, только это под SQL, а у меня DBF

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

Собственно проведение документов оптимизировано по максимому, но хочется добить до конца эту тему.

Для DBF особо не разбирался но вариантов может несколько - один из них организовать реализовать свой менеджер блокировок.(оповещение клиентов и запуск процесса например через сокеты) Сделать по идее это несложно - если будет коллективный заказ могу реализовать и для дбф.:)

см "multex_1c - преодоление 100% загрузки при работе 1с в терминале или Citrix"ссылка http://1c.proclub.ru/modules/mydownloads/personal.php?cid=78&lid=2836Хотя уже стоит задуматься о переходе к sql версии.

2Рассмешил, на SQL версии проблемма блокировок стоит есче более остро =))).

21 гонял тесты на sql версии. Проблема 100 решается не зависимо оттого dbf-1c bkb sql-1с. Все дело в реализации клиента 1с.exeЭто ж надо было написать для ожидания for(;;) {}Прямые запросы многое решают ну и спорить стобой не буду так как неконструктивно это.

Еще раз повторяю , проблема 100 процентной загрузки решается для SQL не просто а очень просто. Однако это не снимает основную часть проблем. Можности сервера при такой реализацию по прежнему используются от 20 до 70 процентов в зависимости от конфигурации и данных(оборота и специфики).

а насколько остро стоят эти проблемы на 4-8 процессорных серверах?

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

Оптимальное - то, которое по умолчанию стоит, ИМХО.А если тяготит частое появление ошибок, то проблема тут не во времени ожидания, а в самой конфигурации, и работать надо над ней. Не знаю, кто как, но лично я склонен полагать, что сообщений об ошибках вообще быть не должно, как и самих ошибок. Тем более, объяснять пользователям, что какие-то ошибки являются нормой - мне не кажется профессиональным решением проблемы. К тому же возникновение таких вот ошибок может быть довольно критично для логики алгоритма в целом, а предусматривать возникновение ошибки на каждом шагу гораздо более хлопотно, нежели исключить саму возможность таких вот ошибок. Для DBF можешь посмотреть вот такое решение:http://1c.proclub.ru/modules/mydownloads/personal.php?cid=5&lid=3931