Скорее всего проблема именно в коде (разберите права, роли, возможно на уровне записей).

Еще проверьте ПК на которых работают эти пользователи, при каких обстоятельствах начинает подвисать.

Возможно, не хватает оперативной памяти, при каких-то операциях в 1С.

Разберитесь что делают эти пользователи.

Более точно, советом помочь не смогу. Здесь нужно смотреть.

Зависать начинает на одной операции - обращении из Формы Списка ЗаказыПокупателей по гиперссылке к Регистру Сведений Комментарии. У меня в базе клиента Админ и полные права. Когда захожу в базу под логином Директора (то же админ и полные права) все работает корректно. Если захожу под своим пользователем или под тем пользователем, у которого проблемы - зависает.

1) Вхожу через РДП на сервере на котором развернута база - т.е. не зависит от ПК.

2) Никакого программного кода при открытия СпискаНабораЗаписей этого регистра нет.

3) Роли и права, судя по всему, ни при чем.

4) Замер производительности в момент зависания ничего не отражает.

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

6) Курсор мыши  "крутит колесо"

7) так продолжается до выдачи критической ошибки при обращении к серверу и выбора "выйти" или "перезапустить" программу.

Очистка Кэша пользователя так же не помогает

Нужно собрать показатели с помощью Performance Monitor.

Также стоит посмотреть ЦУП-ом, возможно есть взаимоблокировка (Судя по зависанию).

Возможно это подтолкнет вас к верному решению.

Проблему удалось решить полным сносом настроек пользователей, у которых происходили зависания. Вобщем то проблема оказалась связанна не с администрированием сервера, а с внутренними настройками пользователей в 1С.

Отлично! Да в основном проблемы с производительностью находят именно в самой 1С.

Добрый день, Богдан!

Подскажите, можно ли в режиме работы пользователей в 1С (т.е. на "горячую") уменьшить в свойствах базы потребляемый размер памяти SQL или нужно всех выгонять, отключать и перезагружать Сервак? И есть ли какие то оптимальные значения для выставления этих значений, например, в моём случае при 10 Гигах оперативы? Какие лучше выставить значения, а то СКУЛ съедает 9,8  Ггб, а 1С "курит в сторонке") и начинает тупить у всех пользователей.

Заранее спасибо.

Настройка должна сработать без перезагрузки сервера СУБД.

Посмотрите вот этим запросом, текущее состояние распределения памяти в MS SQL

SELECT  
(physical_memory_in_use_kb/1024) AS Memory_usedby_Sqlserver_MB,  
(locked_page_allocations_kb/1024) AS Locked_pages_used_Sqlserver_MB,  
(total_virtual_address_space_kb/1024) AS Total_VAS_in_MB,  
process_physical_memory_low,  
process_virtual_memory_low  
FROM sys.dm_os_process_memory;

Помните, MS SQL не будет брать больше памяти чем ему надо.

Возможно Вам просто стоит увеличить объем  ОЗУ на сервере.

Или оптимизировать запросы, вполне вероятно причина там.

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

Но можно предположить что  10 Гб просто мало.

Пользователей порядка 40 чел., база выросла до 19 гигов, даже не знаю, что с ней делать... огроменная просто. Это при включенной функции сжатия в SQL при бэкапе.

40 пользователей и 19 Гб база и ко всему этому еще и сервер 1С. Там однозначно 10 гб оперативной, мало.

Нужно стремится к тому чтоб объем ОЗУ был равен размеру базы в идеале. А так хотя бы 50% - 70% процентов от нее.

План обслуживания настроен ?

Как часто делаете бэкап средствами СУБД ?

Буду знать, спасибо! Да, средствами SQL настроен план обслуживания (но настроено было ещё до моего прихода в организацию).

Также и настроено Резервное копирование баз (ежедневно, в 12 ночи). У меня используется 3 БД.

Скрины во вложении.

Вернувшись к вопросу оперативной памяти, возможно стоит настроить ежедневный рестарт SQL, может это немного оживит работоспособность?

Рестарт кардинально ничего не даст, MS SQL быстро заберет необходимый ему объем оперативной памяти.

Можно конечно попытаться ограничить потребление ОЗУ.

sp_configure 'show advanced options', 1;  
GO  
RECONFIGURE;  
GO  
sp_configure 'max server memory', 5096;  
GO  
RECONFIGURE;  
GO  

Но здесь смысла в этом не вижу, 40 пользователей 19 Гб база и Сервер 1С говорят о том что 10 Гб очень мало.

Как минимум еще 8 - 16 Гб нужно брать. Или сервер 1С перенести на другой сервер, это еще может ненадолго помочь.

Спасибо за советы! Попробую выбить деньги) Если хотят избавиться от тормозов...