|
Вылет серверных баз 1С | ☑ | ||
---|---|---|---|---|
0
user997283
25.09.18
✎
11:55
|
Коллеги, столкнулись с необъяснимым вылетом баз 1С. Прошу помощи, может, у кого случалось подобное?
Комплексная автоматизация 2.4.5.41, обработка «Рабочее место работника склада» - проблема воспроизводится со 100% вероятностью. Жмем кнопку «Приемка», далее выбираем задание, жмем «выбрать», жмем «Перейти к сканированию», затем (ничего не сканируя) жмем «3. Назад», жмем «Отменить выполнение задания» - и в этот момент получаем ошибку "Не удалось снять блокировку с объекта. Объект не заблокирован". Аналогичная ошибка выдается в момент завершения задания на размещение товара в той же обработке. Ошибки начали появляться примерно неделю назад. На тот момент была платформа 8.3.11.3133. Перешли на 8.3.12.1567 – проблема осталась без изменения. Какое-то конкретное событие, после которого начались проблемы, выявить не удалось. Воспроизводится на всех серверных базах «комплексной автоматизации 2.4.5.41» (и рабочая, и тестовые). В файловых тестовых базах (выгрузка-загрузка dt файла из рабочей) ошибка НЕ воспроизводится. В развернутой с нуля (из шаблона конфигурации) демо-базе (серверной) – воспроизводится. В файловой – НЕ воспроизводится. Перезаливка dt-файла в другую серверную базу не помогает. Переподключение базы в списке баз и непосредственная очистка кеша не помогают. Службу сервера 1с перезапускали – не помогает. 21 сентября перезагрузили сервер, на котором работает служба сервера 1с, и сервер, на котором работает sql, – после этого сразу проверили – проблема исчезла. 23 сентября проблема снова появилась. Также, одновременно с появлением проблем с «комплексной автоматизацией 2.4.5.41», стала ненормально вести себя (тоже серверная) база «комплексная автоматизация 1.0». А именно: при попытке пользователя редактировать объект, если он уже заблокирован другим пользователем, обычно программа просто сообщает «…объект заблокирован…» и позволяет нормально продолжить работу. Теперь же в подобной ситуации продолжить работу невозможно, так как в окне о блокировке есть только кнопка «завершить сеанс». Еще симптом, который наблюдается во всех серверных базах: если кто-то сидит в конфигураторе (просто открыли его и ничего не меняли) и в это время кто-то другой пытается запустить сеанс предприятия, он не сможет зайти (не всегда, но часто) - получит сообщение об ошибке вида "Активны сеансы: Иванов Иван, конфигуратор". После выхода из конфигуратора проблема исчезает и зайти дает. Сервер 1с и сервер sql едины для всех баз. Сервер 64-битный, клиенты тоже. Пожалуйста, помогите решить проблему. Если нужны дополнительные данные, готовы предоставить. |
|||
1
shuhard
25.09.18
✎
12:10
|
(0)[сервер sql едины для всех баз]
и что использовано в качестве СУБД ? |
|||
2
arsik
гуру
25.09.18
✎
12:14
|
ставьте 13 платформу. Как раз зарелизили
|
|||
3
tesseract
25.09.18
✎
12:18
|
Это больше похоже на ошибку в коде 1С. Пытаются снять блокировку, которую не установили.
|
|||
4
mcarrowd
25.09.18
✎
12:41
|
(0) на хотлайн писать не пробовали?
|
|||
5
PR
25.09.18
✎
12:45
|
(0) Отладчик тебе поможет
|
|||
6
lubitelxml
25.09.18
✎
12:45
|
(0) КА 2.4 - видел такую ошибку в "Рабочее место работника склада" - файловая или нет была - не вспомню. После сканирования и попытки добавить в документ позиции - вылезала ошибка про блокировку объекта.
|
|||
7
user997283
25.09.18
✎
13:26
|
СУБД - Microsoft SQL Server
Ставить самую свежую (и возможно сырую) платформу - имеет ли смысл? Добавит новых глюков без гарантии исправления текущей проблемы... Не думаю, что проблема в коде. Повторюсь - при загрузке dt из рабочей (проблемной) базы в файловую глюка с блокировкой нет. И все остальные описанные странности в поведении другой базы (КА 1.0) возникли примерно одновременно с этой "блокировкой". Это, совместно с тем, что проблема исчезла на краткий промежуток времени непосредственно после перезагрузки серверов 21 сентября, дает причину подозревать проблему на серверах. Наверно, можно вытащить что-то полезное из техножурнала, но детально расшифровать его не могу. Включили его на полчаса, собрали логи, среди записей есть такие: 42:51.594083-0,EXCP,0,process=rphost,OSThread=6372,Exception=dd149677-3d47-4e05-a55f-4e75b13a441f,Descr='src\RMngrCalls.cpp(584): dd149677-3d47-4e05-a55f-4e75b13a441f: Процесс завершается. Исходящий вызов запрещен.' 42:51.594085-0,EXCP,0,process=rphost,OSThread=6372,Exception=ba8a0cd1-c2cc-4b84-a837-a0dda720ff4e,Descr='src\RHostImpl.cpp(5855): ba8a0cd1-c2cc-4b84-a837-a0dda720ff4e: Не найдено ни одного сервера с размещенным сервисом serviceName=ClusterLockService;' 42:51.594086-0,EXCP,0,process=rphost,OSThread=6372,Exception=dd149677-3d47-4e05-a55f-4e75b13a441f,Descr='src\RMngrCalls.cpp(737): dd149677-3d47-4e05-a55f-4e75b13a441f: Процесс завершается. Исходящий вызов запрещен.' 42:51.594087-0,EXCP,0,process=rphost,OSThread=6372,Exception=dd149677-3d47-4e05-a55f-4e75b13a441f,Descr='src\RMngrCalls.cpp(737): dd149677-3d47-4e05-a55f-4e75b13a441f: Процесс завершается. Исходящий вызов запрещен.' 42:51.594088-0,EXCP,0,process=rphost,OSThread=6372,Exception=96380a22-60f7-4a8b-8fca-1224e6bc518f,Descr='src\RMngrCalls.cpp(949): 96380a22-60f7-4a8b-8fca-1224e6bc518f: onFinishConnection' Не факт, что эти строки техножурнала связаны именно с нашими гляками, просто этих Exception много. |
|||
8
user997283
25.09.18
✎
13:29
|
Еще в SQL Profiler искали проблемные блокировки, в соответствии с этой инструкцией: https://its.1c.ru/db/metod8dev#content:1738:hdoc
Трассировка показала, что таковых нет. |
|||
9
Temai
25.09.18
✎
13:31
|
Причем тут СУБД ебанарот! Ошибка в обработке.
|
|||
10
PR
25.09.18
✎
13:35
|
(9) Расступитесь шире, гений пришел! Ебанаротовый!
|
|||
11
user997283
25.09.18
✎
13:56
|
Еще один симпом стал появляться: сижу в конфигураторе одной базы, а юзеров выкидывает из двух других. Им вылезает сообщение "Активные сеансы: ... конфигуратор..." и две кнопки "Завершить работу" и "Перезапустить". При попытке перезайти - то же самое.
После выхода из конфигуратора - всех сразу пустило. |
|||
12
tesseract
25.09.18
✎
13:59
|
(11) А почему сидение в конфигураторе, должно выбивать пользователей?
|
|||
13
Temai
25.09.18
✎
14:03
|
(12) Потому что когда не умеешь пользоваться отладчиком, ищешь любую возможность за что зацепиться
(10) Все верно, спасибо |
|||
14
user997283
25.09.18
✎
15:14
|
(12) Вот именно, что не должно. И не выбивало никогда раньше.
Тем более сидение в конфигураторе другой(!) базы. |
|||
15
arsik
гуру
25.09.18
✎
15:16
|
Может на сервере с памятью чего случилось? В Виндовом журнале ничего нет?
|
|||
16
user997283
25.09.18
✎
15:17
|
(4) Написали на [email protected], пришел автоответ, что "обращение зарегистрировано и будет рассмотрено в ближайшее время"
|
|||
17
tesseract
25.09.18
✎
15:35
|
(14) У тебя что-то с сервером не то. Почистить ему кэш, возможно rmanager отвалился или места нет.
|
|||
18
user997283
25.09.18
✎
15:48
|
(15) В журнале событий Windows сервера, на котором запущена служба "сервера 1С", не вижу ничего криминального.
Из последних событий (ближайших к моменту специально вызванной ошибки с блокировокой): The "vmGuestLibrary" is successfully initialized for this Virtual Machine. The "vmStatsProvider" is successfully initialized for this Virtual Machine. WMI namespace: "root\cimv2". За последние сутки несколько записей есть с типом "ошибка": раз: Сбой служб шифрования в ходе обработки вызова OnIdentity() в объекте "Системный модуль записи". Details: AddLegacyDriverFiles: Unable to back up image of binary Протокол Microsoft LLDP. System Error: Отказано в доступе. два: Ошибка в процедуре открытия службы "BITS" из библиотеки "C:\Windows\System32\bitsperf.dll". Данные производительности не будут доступны для этой службы. Первые четыре байта (DWORD) в разделе данных содержат код ошибки. три: Сбой активации лицензий (slui.exe) со следующим кодом ошибки: hr=0x8007232B Аргументы командной строки: RuleId=502ff3ba-669a-4674-bbb1-601f34a3b968;Action=AutoActivateSilent;AppId=55c92734-d682-4d71-983e-d6ec3f16059f;SkuId=8c1c5410-9f39-4805-8c9d-63a07706358f;NotificationInterval=1440;Trigger=UserLogon;SessionId=4 И есть одна запись с типом "предупреждение": Не удалось собрать данные об использовании физической памяти NUMA. Первые четыре байта (DWORD) в разделе данных содержат код состояния. |
|||
19
user997283
25.09.18
✎
15:54
|
На сервере, где работает MS SQL server, в журнале windows сообщения такие же. Тоже ничего подозрительного.
На обоих серверах процессор занят на 10-25 процентов. На сервере 1с кратковременные (до минуты) скачки до 60% бывают. Память: на сервере 1с занято 16-35 ГБ (из 32), на сервере SQL занято 30 ГБ (из 32). Так было и месяц назад, когда не было глюков. |
|||
20
arsik
гуру
25.09.18
✎
15:54
|
(18) Уууу. Так вы на виртуалке. Это все объясняет.
|
|||
21
tesseract
25.09.18
✎
16:00
|
(18) Может их просто не замечали?
Ставить 1С на виртуалку или запускать ее от доменного пользователя вообще не рекомендуется. Ставить SQL сервер на виртуалку без толстенного iSCSI я бы вообще не стал. |
|||
22
arsik
гуру
25.09.18
✎
16:05
|
+(20) Тебе нужно не логи гостя смотреть а хоста. И для начала отключите совместное использование памяти в настройках хоста.
|
|||
23
Cyberhawk
25.09.18
✎
16:05
|
(20) Что, глюки (именно ошибки) сервера 1С, вызывающие вылеты, вызваны именно виртуалкой? Вроде ни одной ошибки такого рода никогда не фиксировалось
|
|||
24
tesseract
25.09.18
✎
16:18
|
(23) У хостов на виртуалке бывают сбои с ip/dns именем или временем. Их 1С очень и очень не любит.
|
|||
25
Cyberhawk
25.09.18
✎
17:58
|
(24) Есть какие-то признаки в ТЖ, помогающие определить эти сбои хостовой ОС, или - как обычно - невнятная последовательность EXCP? ))
|
|||
26
tesseract
25.09.18
✎
18:03
|
(25) Вот это мне сильно не понятно:
Не найдено ни одного сервера с размещенным сервисом serviceName=ClusterLockService;' |
|||
27
user997283
25.09.18
✎
20:45
|
Выловили в техножурнале кусок, явно относящийся к ошибке с блокировкой:
21:06.200023-312011,SDBL,3,process=rphost,p:processName=ka2_test2,OSThread=8200,t:clientID=36,t:applicationName=1CV8C,t:computerName=MSK1-1S2,t:connectID=9,SessionID=1,Usr=tsd_big,AppID=1CV8C,Trans=0,Func=HoldConnection,Context='Форма.Вызов : Обработка.РабочееМестоРаботникаСклада.Форма.ФормаРабочегоМеста_480х640.Модуль.ОтменитьВыполнениеЗаданияНаСервере Обработка.РабочееМестоРаботникаСклада.Форма.ФормаРабочегоМеста_480х640.Форма : 760 : РабочееМестоРаботникаСкладаСервер.ОтменитьВыполнениеЗадания(ЭтаФорма); ОбщийМодуль.РабочееМестоРаботникаСкладаСервер.Модуль : 813 : ПараметрыЗадания = РабочееМестоРаботникаСкладаПрограммныйИнтерфейс.ОтменитьВыполнениеЗадания(Задание, ОбщийМодуль.РабочееМестоРаботникаСкладаПрограммныйИнтерфейс.Модуль : 1587 : УстановитьИсходныйСтатусСкладскогоЗадания(Задание, ТипЗадания, ПараметрыЗадания); ОбщийМодуль.РабочееМестоРаботникаСкладаПрограммныйИнтерфейс.Модуль : 5125 : ДокументОбъект.Записать(РежимЗаписи);' 21:06.231003-0,EXCP,3,process=rphost,p:processName=ka2_test2,OSThread=8200,t:clientID=36,t:applicationName=1CV8C,t:computerName=MSK1-1S2,t:connectID=9,SessionID=1,Usr=tsd_big,AppID=1CV8C,Exception=580392e6-ba49-4280-ac67-fcd6f2180121,Descr='src\VResourceInfoBaseImpl.cpp(1176): 580392e6-ba49-4280-ac67-fcd6f2180121: Неспецифицированная ошибка работы с ресурсом Ошибка при выполнении запроса POST к ресурсу /e1cib/logForm: e0506925-b3e4-4dfb-b2fd-309eb7908ae3: Ошибка снятия блокировки объекта. Объект не заблокирован' |
|||
28
tesseract
25.09.18
✎
22:23
|
(27) Как мы долго этого ждали. Осталось найти это в обычном журнале. CallStack обрезан, с фоновыми заданиями это нормально.
Я ставлю на это место : УстановитьИсходныйСтатусСкладскогоЗадания(Задание, ТипЗадания, ПараметрыЗадания); Скорее всего не проверяется создано ли вообще задание. ЗЫ: Я бы взял тебе тестировщиком, если бы были места. |
|||
29
cons24
21.11.18
✎
15:39
|
Я не понял, каков итог? Где был источник проблемы? Устранили ли его?
|
Форум | Правила | Описание | Объявления | Секции | Поиск | Книга знаний | Вики-миста |