Блог Кухара Богдана – Администрирование и программирование в 1С › Форумы › ODIN – Форум по 1С Предприятию › Проблемы зависания 1С для отдельных пользователей
- В этой теме 14 ответов, 3 участника, последнее обновление 7 лет, 8 месяцев назад сделано Аноним.
-
АвторСообщения
-
-
24 января 2017 в 19:31 #1455АнонимНеактивированный
Добрый день.
На сервере развернут 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)Режим серверный.
В журнале регистраций никаких ошибок не зафиксировано. Можете помочь диагностировать проблему?
-
25 января 2017 в 8:34 #1456Богдан КухарХранитель::
Скорее всего проблема именно в коде (разберите права, роли, возможно на уровне записей).
Еще проверьте ПК на которых работают эти пользователи, при каких обстоятельствах начинает подвисать.
Возможно, не хватает оперативной памяти, при каких-то операциях в 1С.
Разберитесь что делают эти пользователи.
Более точно, советом помочь не смогу. Здесь нужно смотреть.
-
25 января 2017 в 15:15 #1457АнонимНеактивированный::
Зависать начинает на одной операции – обращении из Формы Списка ЗаказыПокупателей по гиперссылке к Регистру Сведений Комментарии. У меня в базе клиента Админ и полные права. Когда захожу в базу под логином Директора (то же админ и полные права) все работает корректно. Если захожу под своим пользователем или под тем пользователем, у которого проблемы – зависает.
1) Вхожу через РДП на сервере на котором развернута база – т.е. не зависит от ПК.
2) Никакого программного кода при открытия СпискаНабораЗаписей этого регистра нет.
3) Роли и права, судя по всему, ни при чем.
4) Замер производительности в момент зависания ничего не отражает.
5) Счетчик серверных вызовов периодически включается и накручивает от 50 до 100 обращений за один короткий цикл (доли секунды), потом опять стоит.
6) Курсор мыши “крутит колесо”
7) так продолжается до выдачи критической ошибки при обращении к серверу и выбора “выйти” или “перезапустить” программу.
-
25 января 2017 в 15:16 #1458
-
26 января 2017 в 7:51 #1481Богдан КухарХранитель
-
26 января 2017 в 10:06 #1483
-
26 января 2017 в 10:07 #1484Богдан КухарХранитель
-
9 марта 2017 в 12:42 #1862АнонимНеактивированный::
Добрый день, Богдан!
Подскажите, можно ли в режиме работы пользователей в 1С (т.е. на “горячую”) уменьшить в свойствах базы потребляемый размер памяти SQL или нужно всех выгонять, отключать и перезагружать Сервак? И есть ли какие то оптимальные значения для выставления этих значений, например, в моём случае при 10 Гигах оперативы? Какие лучше выставить значения, а то СКУЛ съедает 9,8 Ггб, а 1С “курит в сторонке”) и начинает тупить у всех пользователей.
Заранее спасибо.
-
9 марта 2017 в 13:31 #1867Богдан КухарХранитель::
Настройка должна сработать без перезагрузки сервера СУБД.
Посмотрите вот этим запросом, текущее состояние распределения памяти в MS SQL
Transact-SQL1234567SELECT(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_lowFROM sys.dm_os_process_memory; -
9 марта 2017 в 13:34 #1868Богдан КухарХранитель::
Помните, MS SQL не будет брать больше памяти чем ему надо.
Возможно Вам просто стоит увеличить объем ОЗУ на сервере.
Или оптимизировать запросы, вполне вероятно причина там.
Я конечно не знаю кофигурацию, в которой у Вас работают пользователи и собственно количество активных пользователей, размер базы! (и другие показатели).
Но можно предположить что 10 Гб просто мало.
-
10 марта 2017 в 12:44 #1869
-
-
10 марта 2017 в 16:28 #1870Богдан КухарХранитель::
40 пользователей и 19 Гб база и ко всему этому еще и сервер 1С. Там однозначно 10 гб оперативной, мало.
Нужно стремится к тому чтоб объем ОЗУ был равен размеру базы в идеале. А так хотя бы 50% – 70% процентов от нее.
План обслуживания настроен ?
Как часто делаете бэкап средствами СУБД ?
-
13 марта 2017 в 3:49 #1892АнонимНеактивированный::
Буду знать, спасибо! Да, средствами SQL настроен план обслуживания (но настроено было ещё до моего прихода в организацию).
Также и настроено Резервное копирование баз (ежедневно, в 12 ночи). У меня используется 3 БД.
Скрины во вложении.
Вернувшись к вопросу оперативной памяти, возможно стоит настроить ежедневный рестарт SQL, может это немного оживит работоспособность?
-
-
13 марта 2017 в 7:58 #1897Богдан КухарХранитель::
Рестарт кардинально ничего не даст, MS SQL быстро заберет необходимый ему объем оперативной памяти.
Можно конечно попытаться ограничить потребление ОЗУ.
Transact-SQL12345678sp_configure 'show advanced options', 1;GORECONFIGURE;GOsp_configure 'max server memory', 5096;GORECONFIGURE;GOНо здесь смысла в этом не вижу, 40 пользователей 19 Гб база и Сервер 1С говорят о том что 10 Гб очень мало.
Как минимум еще 8 – 16 Гб нужно брать. Или сервер 1С перенести на другой сервер, это еще может ненадолго помочь.
-
14 марта 2017 в 12:57 #1898
-
-
-
АвторСообщения
- Для ответа в этой теме необходимо авторизоваться.