История старая, была в прошлом году - при подключении к базе более 75 пользователей возникают жуткие тормоза.
прошлогодняя тема - Нужна помощь зала. Медленно освобождается файл блокировки юзверя.
сейчас вывели 2 дополнительных пользователей - кладовщиков. и опять "магическое число 75", и опять тормоза...
загрузка сиквела не изменилась.
что смотреть на файловом (там, где лежит конфигурация)?

Можно пройти бесплатное экспресс - обследования и выяснить причину тормозов.
Потом, соответственно, методы решения.
softpoint.ru

при <= 74 тормозов нет ?

(1) думаю, что там никто не знает ничего о 7ке

(3) там ее очень хорошо знают
(2) гораздо меньще, только при массовых операциях (пакетный прием заявок из EDI? Импорт из клиент-банка, обмены и т.п.)

зашел в монитор - Всего подключений 137

(5) колись :-)

как минимум  терминал ==>>гигабит ==>> SQL
в терминале настроить ярлык 1c с папкой темпы для каждого пользователя по короткому пути на диск с фат32

(3) Меньше думай за других.

насколько я помню - проблема
была с нечетным количеством файловых блокировок.  почему именно нечетным - не помню.В основном при кол-ве = 3.

как раз у софтпоинта была приблуда, которая следила за колвом блокировок и удалаяла толи лишние толи
все.

(9) Не заметил связи с четностью...

Причем увеличения тормозов при увеличении количества пользователей с 75 до 82 не заметил...

(0) Могу только посочувствовать. Посмотри на короткий путь (если будет хоть один длинный - будет такая бяка). По диску посмотри в свойствах кеширование. Ну и самая детская хрень - антивирус, конечно врядли, но как говорится ... Покоцай лог журнала, может он вырос дико. Ну может еще админ настроил аудит на каталог 1С, хотя я думаю врядли он такой идиот.
Ну типа пока все что пришло в голову. Попроси кого-то "со стороны" посмотреть на ваш бардак. Может со стороны оно как говорится видней будет.
(7) Т.е. фат32 решает все проблемы?.. Тогда уж сразу на нетварь ...

ну так чем кончилось?

(12) Лог нормальный, метров 200. антивирь, ессно, с нужными исключениями (корпоративная установка), аудит выключен.
смотрели "сторонние", не увидели ничего криминального.
а вот про путь - я не понял. ты хочешь сказать, надо диски мапить? у меня путь указан везде сетевой...  
(13) регламентно разнесли некоторые групповые операции. выгнали бушек лишних, пусть в упыпырище работают...

(14) Если у тебя путь типа \\server\base\ то ненужно, если же путь длинный то нужно маппить. При этом у некоторых почему-то странно реагирует на пробелы в пути (причина так и невыяснена). Поэтому я всегда стараюсь делать путь коротким. Пути к папкам пользователя только относительно базы, просто нелюблю переписывать.
Если у вас есть домен то посмотрите - глючит только на каком-то пользователе или на любом? Если на каком-то то нужно удалить его полностью и завести нового, но не в точности также. Т.е. был в DC Ivanov, заведите Ivanov_s ну или по другому как-то. И неполениться права руками раздать а не перетаскивать со старого. Был случай, но я думаю там кривизна рук админа была (но кто ж в этом признается). В общем, если стоит задача решить вопрос, а не искать крайних, то нужно пробовать.
Посмотреть на дисковую систему. Может просто скапливается очередь.
Проверить сетку на компе который глючит. Вплоть до замены сетевухи и гнезда на свиче. Лично у меня была ситуация с гнездом. Пока отловил прошло пару месяцев - падал коннект как-то рандомно.

(0) Через сколько свичей заходят? Есть ли цепочками?

(15) путь как раз вида \\File-srv\trade\center\, пробелов нет, русских букв нет, у всех одинаковый - сетевой
тормозит не на конкретных пользователях, а после перехода  их числа через 75 (независимо от того, в какой последовательности заходят)
пути к папкам, ессно, относительные.
"глючащие" сетевки бывали, но оперативно отлавливались админами...
(16) гигабитник между серверами и шкафами, от него - сотки, от них - клиенты. Более двух (включая центральный) в цепочке нет. Терминальные - те сидят на сервере через мегабитный.

917) а если взять филемон и помониторить проблему..?

(17) Т.е. тупо тормоза на кол-ве юзеров 1С?
Ну тогда, что б убедиться, запрети все подключения кроме терминальных и пооткрывай 1С под 90+ юзерами в терминале. Если терминал непотянет то временно выдели еще ящик на котором подними терминал. Результаты в студию.

Хм, не наблюдалось такого никогда и при бОльшем кол-ве :)
Отпишись

(0) Действительно странно . Связка sql2005-Citrix (сервера разнесены)-7.7 , работала без непонятных тормозов при >90 пользователей .
Если у тебя не терминал , ИМХО нужно сетку копать . Я бы попробовал часть пользователей через терминал подключить и посмотреть .
Если же у тебя терминал , и все пользователи через него работают , то же есть нюанс , если терминальник один , то на каком то количестве пользователей (как раз порядка 70-80) , на терминальнике начинаются глюки , не хватает дескрипторов для такого количества сессий . Либо разносить терминалку либо Citrix .

(20) Именно.
Собственно, в прошлом году такое наблюдалось, когда юзвери работали строго по сети. в этом году часть пересадили в терминал. Но ситуация начала повторяться именно после роста количества пользователей более 75. Причем при дальнейшем росте пользователей, до 80-84 никакого дальнейшего роста тормозов уже незаметно.

(4)>>> пакетный прием заявок из EDI? Импорт из клиент-банка, обмены и т.п

еди - Зло, там тупо без пауз создаются заявки. При этом они еще и проводятся, так же следовательно это тоже самое, что если запустить кукую либо обработку на перепроведение документов.

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

Так же стоит массивные отчеты, которые написаны на Запросах от 1С, переписать на прямые запросы с оптимизацией :)

Убрать из журнала документов лишние поля, к примеру поле, которое по текущему документу еще и просматривает подчиненные документы...
...
И так далее в таком духе :)

(24) ой. а я-то не знал... :-)

(22)Ты еще не зыбывай про антивирусники, Админы не очень заморачиваются по поводу настроек. И по сути каждая машинка еще и тестит сетевые ресурсы :)

Админы народ угловатый, им не в дамек, что 60 ПК при оновременном тесте сети смогут её заГадить :)

(25)Ой... а а мой телепат отдыхает :)

(26) не везде админы туповатые... :-)

(28)Я рад за твою самонадеянность...
Но ты проверь, ой как много ждет тебя откровений :)

(29) Ты глаголешь азбучные истины. а азбуку мы знаем...

(19) что именно мониторить?

Что-то не так.
У тебя до 86 юзеров должно летать.
А при 86-и падать вообще.

(23) Ну всетаки сделай как я сказал. Нужно отсечь проблему - либо терминал, либо локально вешают. Тогда дальше можно рыть.
(32) Тонкий юмор на 1986?.. Дык автору это негрозит.

Мониторинг серверов на загрузку
1) процессора
2) Дисковой системы
3) Оперативной памяти проводил
4) Сети между серверами

Что показывает, есть ли узкие места?