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 запросов к серверу. Таким количеством, прилетающим от нескольких пользователей, можно заткнуть крутой сервер.