Проблемы зависания 1С для отдельных пользователей

[Аноним]

Добрый день.

На сервере развернут MS SQL server 2008 R2 b 1C:Enterprise 8.3 server.

На 1С сервере установлена 20 разных баз из которых активно эксплуатируются 3-4.

На одной рабочей базе (1С:Управление торговлей 11)  постоянно происходят подвисания отдельных пользователей при обращении к данным одного регистра сведений. У других пользователей такого зависания нет.

Платформа 1С:Предприятие 8.3 (8.3.6.2332)

Конфа Управление торговлей, редакция 11.1 (11.1.5.16) (http://v8.1c.ru/trade/)
Copyright © ООО «1C», 2003-2013. Все права защищены
(http://www.1c.ru)

Режим серверный.

В журнале регистраций никаких ошибок не зафиксировано. Можете помочь диагностировать проблему?

[OdinES]

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

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

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

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

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

[Аноним]

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

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

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

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

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

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

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

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

 

[Аноним]

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

 

[OdinES]

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

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

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

 

 

[Аноним]

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

 

[OdinES]

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

[Аноним]

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

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

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

 

 

[OdinES]

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

Посмотрите вот этим запросом, текущее состояние распределения памяти в 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;

[OdinES]

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

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

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

 

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

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

 

 

[Аноним]

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

[OdinES]

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

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

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

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

 

 

[Аноним]

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

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

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

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

[OdinES]

Рестарт кардинально ничего не даст, 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С перенести на другой сервер, это еще может ненадолго помочь.

 

[Аноним]

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

[Автор]

Сообщения