Steve242,

В данном случае действительно не имеет смысла отвечать. Лучше послать в поиск.
Вопрос достаточно проработан кучей людей. Информации много. Притом вопрос не так прост, что бы дать ответ в нескольких предложениях. Почитайте инет, попробуйте разные советы. Если не получится, обратно сюда с вопросом в стиле:
Такая-то проблема на такой-то базе с таким-то документооборотом и пользователями, на таком-то железе. Мерял то и это, пробовал так-то. Подскажите, что еще делать.

Steve242,

Для начала мониторить загрузку процессора, дисков и сети на всех серверах. Особенно терминальном.
SQL-сервер, на мой взгляд, маловероятен как причина тормозов, поскольку вся база влазит в память.
Мониторить штатной "Производительностью" и не глазами, а сохранять счетчики в файл, потом рассматривать и анализировать пики.
Вангую, что на терминале вылезет 100% загрузка процессора на ровном месте.
И, кстати, озвучьте, ТиС более-менее штатный или переписанный. Неправильно переписанным ТиС (типа много расчетных колонок в журналах) можно поставить раком крутейший кластер. :)

Злой Бобр,

авторНа клюшках не было, нет и не будет кластеров.
Ну почему же совсем нельзя кластер. Можно сделать... нечто, по крайней мере, подходящее под каноническое определение кластера.
У меня стоит кластер на базе SQL AllwaysON High Availability. Правда распределение нагрузки в пределах одной базы 1С я не делал. Но но и не особо надо - баз 1С столько, что нагрузка вполне распределяется просто указанием первичного сервера для отдельных баз.

Злой Бобр,
А кто вас ограничивает нагружать кластер одной базой? Да и кластер необязательно использовать для балансировки нагрузки, можно и для повышения доступности.
У меня более 300 гигов баз 7.7, самая большая прилично за стольник. Кластер используется для ручного распределения нагрузки (базы разнесены по серверам) и повышения доступности (при выходе из строя или на техобслуживание одного сервера второй просто делается первичным, пользователи перезаходят в 1С и работа продолжается).

Злой Бобр,

Вы понимаете в чем ограничение приложения на клюшках? Судя по всему не очень. Объясняю "на пальцах".
У вас кажется синдром "самый умный парень на деревне". (Не обижайтесь, это шутка)
Физически вы можете иметь более-менее рабочую базу максимум со 100-120 пользователями. Будут незначительные тормоза, но всетаки будет работать.
Таки имею. Как раз порядка 100 пользователей в совокупности. База сделана распределенной из ряда соображений, в том числе и вопроса блокировок. Запас по производительности достаточный, что бы не переводить проведение документов на прямые запросы и, даже, иметь контроль остатков с позиции документа до текущего момента, замедляющий проведение раза в полтора.
Дальнейшее повышение количества пользователей приводит в итоге к тому что примерно на 160 пользователях наступает писец. Т.е. работать уже никак, от слова совсем. В этом и есть ограничение приложения 7.7.
Не ощущаю ограничения. Думаю, когда, с концом кризиса и активным расширением филиалов, количество пользователей подойдёт к этой цифре, я просто перепишу свой "расширенный контроль остатков" на прямые запросы, и никакого апокалипсиса не будет.
Возможно вы имеете в виду ограничение количества пользователей в одной физической базе. Но зачем себя ограничивать? Распределенную базу тоже можно использовать в качестве способа повышения быстродействия единой учетной системы.
Лично у меня была одна база 350+ Гиг. И даже не могло идти речи о кластерах и пр. ереси.
Что вам мешало поднять кластер? Конечно никакого распаралелливания нагрузки в пределах одной базы не будет и, для 7.7, подобное распараллеливание просто замедлит работу, а не ускорит. Но почему бы не использовать кластер для повышения надёжности и доступности? Лично мне, после поднятия кластера, стало гораздо спокойнее обслуживать сервера. Ну придёт кривое обновление, ну встанет раком сервер. Переводим пользователей на другой несколькими кликами мышки и продолжаем работу.
Правда было это когда я плотно сидел на 1С и наивно полагал что 1С решает все. Как же я заблуждался ...
:) Все не решает ни одна система или технология. Так что это вы, наверное, по молодости...
Сейчас у работодателя БД на мелкомягком скуле размером в несколько терабайт, 10к+ пользователей и кластером из 20+ серверов. И я реально осознаю что 1С в ближайшие лет 20 точно не выйдет на подобный уровень.
А оно ей особо надо? Рынок лопат процветает ничуть не меньше рынка экскаваторов. И оба людям нужны.
Поэтому забил я на 1С, чего и многим советую. Глупо развиваться по приложению которое не конкурентноспособно на мировом рынке.
Кажется я понимаю. Вы амбициозны. Стремитесь к глобальному - огромные базы, развесистые кластера, килобайты пользователей, лично котироваться на глобальных рынках... Прекрасно.
А я буду заниматься СМБ (средним и малым бизнесом), чувствуя себя нужным и важным. И это тоже прекрасно. Вы не находите? :)

Steve242,

Команды
exec sp_configure 'show advanced options', 1
reconfigure with override
exec sp_configure 'max degree of parallelism', 1
reconfigure with override
отключают распараллеливание запросов. При методах работы 7.7 с SQL-сервером попытки распараллелить запрос только зря тратят ресурсы сервера.

Можно еще выполнить
exec sp_configure 'show advanced options', 1
reconfigure with override
exec sp_configure 'default trace enabled', 0
reconfigure with override
Это отключает несколько снизит нагрузку на дисковую подсистему, если, конечно, у вас она как-то лимитирует.

Steve242,

Почитайте http://infostart.ru/print/330256/
Может поможет.
Хотя, никакой оптимизацией сервера нельзя достичь того быстродействия, которое достигается оптимизацией конфигурации. Возможно у вас там есть буквально считанные тонкие места, которые грузят сервер.
Например, я как-то оптимизировал журнал документов. В нём было десятка полтора вычисляемых колонок. Это порождало просто при открытии журнала порядка 8000 запросов к серверу. Таким количеством, прилетающим от нескольких пользователей, можно заткнуть крутой сервер.

Steve242,

Положите в общую автозагрузку на сервере батничек с

mkdir R:\TEMP\%USERNAME% >nul
set TEMP=R:\TEMP\%USERNAME%
set TMP=R:\TEMP\%USERNAME%
reg ADD HKCU\Environment /v TEMP /t REG_SZ /d R:\TEMP\%USERNAME% /f
reg ADD HKCU\Environment /v TMP /t REG_SZ /d R:\TEMP\%USERNAME% /f

При втором входе темпы окажутся на рамдиске.

Для запуска 1С сделайте ярлык с параметром запуска
/T"R:\TEMP\%USERNAME%\"

Volochkova,

1, Преждем чем отключать парарлелизм, надо сначала посмотреть статистику - чего больше ждал сервер.
А так в лоб отключайте поможет - ИМХО бред.
Для 1С7.7 отключение параллелизма вполне обычная рекомендация. Если, конечно, сервер используется почти исключительно под 1С.
Не знаю, на сколько вы в курсе особенностей работы 7.7 с SQL, поэтому поясню.
Подавляющая часть обращений 7.7 к SQL серверу (процентов эдак 99) это вызовы хранимых процедур для получения одной строки одной конкретной таблицы. Такие запросы не имеет смысл даже пытаться распараллеливать. Плюс постоянное использование TABLOCK. Плюс несколько таблиц SQL, использующихся при большинстве действий в 1С. Отсюда получаем низкую скорость работы и большую вероятность ожидания блокировки.

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

Для ТС: попробуйте обратить внимание на http://infostart.ru/public/64620/ . Цитирую оттуда: "По факту, в моей базе, формирование ведомости по партиям с групировками Фирма/Поставщик/Склад ускорилось в три раза во сравнению с неоптимизированным запросом"