собственно, смысл вопроса: после очередного обновления серверов заметили, что файл блокировки пользователя освобождается и удаляется в течение 3-5 секунд. Т.е. стоит выйти из 1с, при попытке зайти обратно - в течение 5 секунд видим "каталог пользователя занят".
В условиях , когда юзверей в ЦБ немного увеличилось - начались чуствительные подтормаживания (ну, естественно, наложилось предновогоднее оживление...).
Вопрос - что в параметрах файловой системы отвечает за это "время"?

(0) 3-5 сек, это мечта. Я в одной фирме жду по 5-15 минут! Администрирования там не касаюсь вообще. Только сама 1с.

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

(1) Я так мучаюсь с архивированием перед внесением изменений.Сам закрываешь у пользователя программу, а он еще минут 10 в мониторе висит и блокирует архивирование.

Это кто ж у вас норматив по входу-выходу из 1с умудряется за 5 секунд выполнить?

(3)Вообще-то человек совета спрашивал,а ты ему о своих проблемах рассказываешь)))))

(5) Я думаю проблема одна...

(3) исповедь началась какая-то

Анекдот про _быстрых_ напоминает

Приходит сноубордист в ЗАГС - как о бычно - ширинка до пяток, за спной доска... сидит бабулька божий одуванчик - чего тебе, милок? - хочу фамилию сменить! - а какая у тебя фамилиё? - Стремительный!! - а хочешь какую? - ФФФЬЮЮЮИИИТТТЬЬЬЬЬ!!!!

(3) "каждому - своё"© Я б не выдержал и разобрался...
(4) Да дело не в нормативе. ПРосто начали жаловаться на подтормаживание. Варианта было два - или больше 75 пользователей стало, или что-то с базой. увеличения тормозов на сиквеле - не заметил, загрузка прежняя. а вот с файловиком, где лежит конфига - обнаружил такую каку...

(0) а в это время на _других_ базах не выполняются какие-нибудь регламентные процедуры типа перепроведения, пересчёта итогов, ТиИ, и т.п.?

(11) Нет, конечно...
Да я ж говорю, нагрузка сервера БД не изменилась

файловая система ни при чём. это 1с мутит

Родственная проблема с v7 на Novell. Когда штатно выходит из базы, все в порядке, а вот если комп завис, может и час не пускать, утверждая "каталог Пользователя занят", а в нем неудаляемый 1Cv7.LCK. Выходим из положения хирургически, каталог пользователя переносим рядом с каталогом базы, а внутри базы создаем новый.

(10) а что за волшебное число 75..?
.
м.б. тормоза держит не файл, а то, что делается до него? - реестр? cfg?

щас будет жутко глупый вопрос: а зачем одному юзверю выходить из 1с и в течение 5 секунд заходить обратно?

(15) плюсую этот вариант.

(15) cfg тормозит ДО закрытия главного окна

а может, какие внешние объекты не уничтожаются? у автора наверняка полно ВК

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

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

(21) сфигаль?

(22) а с чего каталог-то на файловом? если уже и процесса 1с на компе юзверя нет, да и связи компоненты  с каталогом не чуствую. поясни тогда механизм...

такое же наблюдаю последние полгода - ничего не обновлялось, искать конец не пытался.

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

(23) ты уверен, что процесса нет? а что говорит анлокер?

(24) дай ссылку которую упоминал ранее по сабжу!! - Ковычки Подсистема

почему у меня эта ветка упорно читается как "Нужна помощь ЗЛА"

(0) Пытался в свое время разобраться с проблемой долгого выхода из 1C 7.7. Вот что обнаружил.

При закрытии 1С процесс 1cv7.exe пытается по очереди удалять файлы из каталога БД *.$lk - файлы файловых блокировок. Например, sc123.$lk - файл блокировки для справочника sc123.
В каталоге БД таких файлов ровно столько, сколько открыто ТИПОВ справочников в данный момент всеми активными пользователями.
На попытку удаления каждого такого файла платформа тратит ровно 1 сек. Отсюда и получаем, что время корректного завершения может сильно отличаться в зависимости от конфигурации и активности пользователей. Причем, вы сами можете прикинуть примерное время завершения по количеству файлов блокировок.
В свое время не нашел никакого способа уменьшить это время.

Как выход - прибивать процесс 1cv7.exe вручную.

(25) phunter'ом смотрели... Нет процесса...

(30) пустота не может лочить файл. смотри анлокером, кто держит

(29) у меня файлов блокировок может быть и в районе 3 десятков.... однако выход - 3-5 секунд..

(28) потому, что добро уже не помогает.... :-(

(0) procmon'ом трассировку событий смотрели?

(31) Админ говорит, что "никто не держит"...
потому-то и задаю вопрос. Я их редко задаю - обычно сами справляемся. :-(

(35) не верю! ©

(34) каких именно событий?

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

(38) болеешь?

попробуй запусти файл gbpltw.exe

(37) Установка и снятие блокировок на файл, связь их с другими событиями, чтение/запись файлов, ключей реестра и т.д. Зачастую анализ лога procmon весьма помогает в таких вот непонятных случаях.

(35) короче, возьми САМ анлокер и посмотри, кто лочит файл. админу не верю.

Можно еще трассировку вызовов WinAPI снять при выходе. Правда, название программы запамятовал, давно не пользовался.

(32) Если у платформы получается удалить файл *.$lk, то, естественно, она не ждет секунду и сразу же начинает обработку следующего файла.

Я смотрел утилитой FileMon - там все с точностью до миллисекунд видно.

(29) имхо, вот причина

(44) ну с чего вдруг "получится удалить", если в базе еще человек 70 работает?

(46) Если у других пользователей нет файловых блокировок на определенный файл *.$lk - то почему не получится удалить? В реальности это говорит о том, что в данный момент ни у кого не открыто ни одного элемента справочника этого типа.

Утилита FileMon наглядно иллюстрирует это.

(46) В идеале рекомендую посмотреть на эту ситуацию, а вдруг будут новые мысли?

(47) Я этот механизм (файловых блокировок) прекрасно представляю.

(0) d httcnht gjghfdbnm 1 gfhfvtnh

в реестре поправить 1 параметр

(50)тебе поможет (40)

(51) "Имя, брат! Имя!!!!"©

че-нить в этом духе:
http://reestrwin.evgb4.ru/borba-s-zavisaniem-programm/

(54) Хотелось бы найти способ изменить время ожидания: 1 сек, например, на 100 мс. Это решило бы проблему.

(5) ты про WaifToKillServiceTimeout ? ставь 0, чего уж там.. вообще ждять не будет.
:)

(54) это все не то
(55) Не решило бы. По крайней мере, мою - точно.

(57) Боюсь, что проблему не решить, если не патчить платформу.

К сожалению, таких досадных проблем у 7.7 несколько, с которыми пока не получается бороться умом. Т.к. платформа снята с поддержки, то надеяться на исправление со стороны 1С бессмысленно.

(57) Конечно, пути обхода придумать можно. К сожалению, это пути именно обхода проблемы, а не пути решения.

(59) обход проблемы - это уже решение... :-)

(60) обходя грабли - мы лишаемся бесценного опыта!!!

(61) Страшнее граблей - только детские грабли...
зы. ладно, до НГ дотянем, а после - посмотрим... Все равно несмотря на очередной рекорд, до 100 тыс не дотянем... осталось 2 дня активной работы, и 1 на подчистку хвостов...

вот еще можешь попробовать:
автоматическая выгрузка DLL-файлов
   Windows Registry Editor Version 5.00

   [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer]

   "AlwaysUnloadDLL"="1"

(63) А зачем? если процесса уже нет, файл никто не держит. а винда освобождает его только через неск. секунд

(64) не подибил ?
мот еще какие ключи в реестре есть..не помню уже, типа сброса файлового кеша.