Имеем 2 независимых физических сервера.
На обоих до недавнего времени был установлен сервер 1С версии 8.3.13.
Угораздило вляпаться в 8.3.16.1063.
Обновили настройки серверов в соответствии с лицензией уровня ПРОФ, соблюдая все новые ограничения.
Всё взлетело. Есть мелкие косяки в работе обычных форм, но это мелочи.
Основная проблема - оба сервера начали иногда терять аппаратные ключи по ночам. Ключ светится, в диспетчере устройств есть, перевтыкание не помогает - сервер 1С его не видит.
Закономерность выявить не удается. Приходим утром - "Не обнаружена лицензия на запуск сервера". Техники ребутят сервер - всё снова работает несколько дней.
На 8.3.13 проблем не было. Два аппаратных ключа на разных серверах не могли начать глючить одновременно.
В перечне известных ошибок платформы данный баг найти не удалось.
Кто-то еще сталкивался?
Как решается?
Пока на ум приходит только ежедневный рестарт сервера 1С до начала рабочего дня.
На обоих до недавнего времени был установлен сервер 1С версии 8.3.13.
Угораздило вляпаться в 8.3.16.1063.
Обновили настройки серверов в соответствии с лицензией уровня ПРОФ, соблюдая все новые ограничения.
Всё взлетело. Есть мелкие косяки в работе обычных форм, но это мелочи.
Основная проблема - оба сервера начали иногда терять аппаратные ключи по ночам. Ключ светится, в диспетчере устройств есть, перевтыкание не помогает - сервер 1С его не видит.
Закономерность выявить не удается. Приходим утром - "Не обнаружена лицензия на запуск сервера". Техники ребутят сервер - всё снова работает несколько дней.
На сервере 1С:Предприятия не найдена лицензия. Не обнаружен ключ защиты программы или полученная программная лицензия!
по причине:
локальный ключ недоступен: Status=0, ENSR8 Локальный, не установлен
Файл программной лицензии не найден
локальный ключ недоступен: Status=0, EN8SA Локальный, не установлен
Поиск лицензии в сервисе лицензирования:
Файл программной лицензии не найден
по причине:
локальный ключ недоступен: Status=0, ENSR8 Локальный, не установлен
Файл программной лицензии не найден
локальный ключ недоступен: Status=0, EN8SA Локальный, не установлен
Поиск лицензии в сервисе лицензирования:
Файл программной лицензии не найден
На 8.3.13 проблем не было. Два аппаратных ключа на разных серверах не могли начать глючить одновременно.
В перечне известных ошибок платформы данный баг найти не удалось.
Кто-то еще сталкивался?
Как решается?
Пока на ум приходит только ежедневный рестарт сервера 1С до начала рабочего дня.
Прикрепленные файлы:
По теме из базы знаний
- Универсальная подсистема ДМ
- Настройка PostgreSQL 11.5 и 1C: Предприятие 8.3.16 на Windows Server 2008R2
- Собираем образ виртуальной машины с PostgreSQL и платформой 1С. Цикл "Многопоточный CI для 1С c Packer, Vagrant и Jenkins", часть 2
- Хранение изображений прикрепленных документов 1С: Бухгалтерия 8 на SQL сервере 1С:Предприятие 8.3 (8.3.16.1063) Бухгалтерия предприятия, редакция 3.0 (3.0.77.78) Microsoft SQL Server Enterprise (64-bit) 14.0.2027.2
Найденные решения
(1)
Установить 8.3.15.1778 ! И не торопиться переходить на 8.16 , так как помимо проблем с ключами , есть проблемы и с принтерами и с запросами оборотных регистров ( выдает разные результаты Пример: Запрос на платформах 8.3.13 ,8.3.14,8.3.15 результат = 10, на 8.3.16 результат = 0 )
Вам оно надо?
Угораздило вляпаться в 8.3.16.1063.
Установить 8.3.15.1778 ! И не торопиться переходить на 8.16 , так как помимо проблем с ключами , есть проблемы и с принтерами и с запросами оборотных регистров ( выдает разные результаты Пример: Запрос на платформах 8.3.13 ,8.3.14,8.3.15 результат = 10, на 8.3.16 результат = 0 )
Вам оно надо?
Остальные ответы
Подписаться на ответы
Инфостарт бот
Сортировка:
Древо развёрнутое
Свернуть все
(4) была мысль. Только вот проблема не локализована.
В центре лицензирования тоже не экстрасенсы работают. Уверен, что в ответ пришлют общие рекомендации типа "обновите драйвер ключа, используйте другой юсб-порт, замените ключ".
Проблема возникла одновременно на 2ух серверах при обновлении до 8.3.16.1063. Я процентов на 90% уверен, что это глюк релиза, тк таких совпадений не бывает. Меня смущает, что я не смог найти никакой информациях на профильных ресурсах относительно этой ошибки данного релиза и подтвердить свою догадку.
В центре лицензирования тоже не экстрасенсы работают. Уверен, что в ответ пришлют общие рекомендации типа "обновите драйвер ключа, используйте другой юсб-порт, замените ключ".
Проблема возникла одновременно на 2ух серверах при обновлении до 8.3.16.1063. Я процентов на 90% уверен, что это глюк релиза, тк таких совпадений не бывает. Меня смущает, что я не смог найти никакой информациях на профильных ресурсах относительно этой ошибки данного релиза и подтвердить свою догадку.
(5) Я всмысле про то, что если это ошибка платформы, то им возможно уже обращались с подобными вопросами. А вообще в новых платформах ведется лог лицензий где записывается конфигурация компьютера на момент установки лицензий и на момент слета. Я так однажды определил, что сисадмин периодически менял объем жесткого диска (на вирт. сервере), хотя до этого ни в какую не признавался и говорил что не в курсе почему лицензии слетают :)
(1)
Установить 8.3.15.1778 ! И не торопиться переходить на 8.16 , так как помимо проблем с ключами , есть проблемы и с принтерами и с запросами оборотных регистров ( выдает разные результаты Пример: Запрос на платформах 8.3.13 ,8.3.14,8.3.15 результат = 10, на 8.3.16 результат = 0 )
Вам оно надо?
Угораздило вляпаться в 8.3.16.1063.
Установить 8.3.15.1778 ! И не торопиться переходить на 8.16 , так как помимо проблем с ключами , есть проблемы и с принтерами и с запросами оборотных регистров ( выдает разные результаты Пример: Запрос на платформах 8.3.13 ,8.3.14,8.3.15 результат = 10, на 8.3.16 результат = 0 )
Вам оно надо?
(7) Решение о выборе платформы принимал не я. Я бы дальше 8.3.14 прыгать не стал.
Я конечно могу поднять вопрос о необходимость отката до ближайшего стабильного релиза, озадачить технический отдел, но хотелось бы быть уверенным, что это ошибка платформы и её нет возможности исправить без отката.
Но я нигде не могу найти этому официального или хотя бы косвенного подтверждения, хотя релизу уже 4 недели.
Я конечно могу поднять вопрос о необходимость отката до ближайшего стабильного релиза, озадачить технический отдел, но хотелось бы быть уверенным, что это ошибка платформы и её нет возможности исправить без отката.
Но я нигде не могу найти этому официального или хотя бы косвенного подтверждения, хотя релизу уже 4 недели.
(8)
4 недели -это не срок...
как вам такие финты
"Повышение стабильности при работе с принтерами
Повышена стабильность при работе с «проблемными» принтерами. Ранее недоступность принтера могла приводить к недоступности всей платформы или проблемам с закрытием терминальной сессии. Проблемы с драйверами — к падению. В новой версии платформы работа с принтерами вынесена в отдельный процесс и указанные выше проблемы больше не будут беспокоить пользователей."
и тут же не является ошибкой
"Описание:
При использовании удаленного доступа к рабочему столу печать на некоторые принтеры, например, Kyocera, может выполняться некорректно.
Способ обхода:
Не использовать терминальный сервер, использовать другие принтеры."
это как?
А на все документального подтверждения и не найдете! потому как баг лист составляется только после регистрации ошибки в 1с и ее подтверждения!
Но я нигде не могу найти этому официального или хотя бы косвенного подтверждения, хотя релизу уже 4 недели.
4 недели -это не срок...
как вам такие финты
"Повышение стабильности при работе с принтерами
Повышена стабильность при работе с «проблемными» принтерами. Ранее недоступность принтера могла приводить к недоступности всей платформы или проблемам с закрытием терминальной сессии. Проблемы с драйверами — к падению. В новой версии платформы работа с принтерами вынесена в отдельный процесс и указанные выше проблемы больше не будут беспокоить пользователей."
и тут же не является ошибкой
"Описание:
При использовании удаленного доступа к рабочему столу печать на некоторые принтеры, например, Kyocera, может выполняться некорректно.
Способ обхода:
Не использовать терминальный сервер, использовать другие принтеры."
это как?
А на все документального подтверждения и не найдете! потому как баг лист составляется только после регистрации ошибки в 1с и ее подтверждения!
(10)
и тут же не является ошибкой
"Описание:
При использовании удаленного доступа к рабочему столу печать на некоторые принтеры, например, Kyocera,
Да-да. И способ решения - "купите другой принтер или не используйте терминалы". Читал, тоже вызвало недоумение.
Я не спорю, что в 8.3.16 куча косяков. Другое дело, что с ними в нашем конкретном случае пока можно жить и ждать более стабильной версии 8.3.16.
А вот потеря лицензий - с этим мириться мы не можем.
Я пытаюсь найти хоть кого-то у кого есть именно этот глюк на этом релизе. Пока глухо =( .
и тут же не является ошибкой
"Описание:
При использовании удаленного доступа к рабочему столу печать на некоторые принтеры, например, Kyocera,
Да-да. И способ решения - "купите другой принтер или не используйте терминалы". Читал, тоже вызвало недоумение.
Я не спорю, что в 8.3.16 куча косяков. Другое дело, что с ними в нашем конкретном случае пока можно жить и ждать более стабильной версии 8.3.16.
А вот потеря лицензий - с этим мириться мы не можем.
Я пытаюсь найти хоть кого-то у кого есть именно этот глюк на этом релизе. Пока глухо =( .
(13) Типовая УПП с 1.3.96.1 по релиз 1.3.128.2 ( других под рукой не было ) и на типовой демо тоже , причем кривой результат выдает только в клиент-серверном исполнении :) в файловом все ок :).
а ответ поддержки " ...бла бла бла... УПП не предназначена для использования на 16 платформе используйте платформу 12 или 13 " вот такие они молодцы :)
а ответ поддержки " ...бла бла бла... УПП не предназначена для использования на 16 платформе используйте платформу 12 или 13 " вот такие они молодцы :)
(7) на платформах 8.3.12, 8.3.13, 8.3.14 наблюдал проблемы с отборами в СКД (видимо по другому отрабатывает запрос с SQL). Проблема на типовом отчете "Ведомость по учету затрат" для нас это очень большая проблмеа, на 8.3.15 такой проблемы нет, но есть проблемы с вылетами по дампу при проведении документов, отправкой писем, масштабирование при печати. Остаётся пробовать 16й релиз, 1С не оставила альтернатив
(2) В диспетчере ключ виден.
Служба сервера 1С его не находит, пока не ребутнешь.
Ребут службы сервера 1С помогает, отсюда я делаю вывод, что проблема вероятнее всего не железная, а софтовая и она где-то на стороне сервера 1С. Да и какова вероятность, что железная проблема появилась одновременно на двух разных физических серверах, находящихся в разных зданиях.
При очередном глюке постараюсь заглянуть в Хасп менаджер. Глубоко не копали, с утра нужно было быстро запускать офисы в работу. Потому и прошу коллег поделиться опытом =).
Служба сервера 1С его не находит, пока не ребутнешь.
Ребут службы сервера 1С помогает, отсюда я делаю вывод, что проблема вероятнее всего не железная, а софтовая и она где-то на стороне сервера 1С. Да и какова вероятность, что железная проблема появилась одновременно на двух разных физических серверах, находящихся в разных зданиях.
При очередном глюке постараюсь заглянуть в Хасп менаджер. Глубоко не копали, с утра нужно было быстро запускать офисы в работу. Потому и прошу коллег поделиться опытом =).
(3) Подтверждаю... платформа 8.3.16.1063 (сервер на Debian).
Потерял сегодня USB-ключ
Сервис 1С рестартовать не стали, просто передернули aksusbd
до этого момента аптайм был около 10 дней
Потерял сегодня USB-ключ
На сервере 1С:Предприятия не найдена лицензия. Не обнаружен ключ защиты программы или полученная программная лицензия!
Сервис 1С рестартовать не стали, просто передернули aksusbd
до этого момента аптайм был около 10 дней
(16) Sentinel Run-time Installer какой версии используется? Сейчас последняя - 7.102.
Может, 8.3.16 ведет себя так с более старыми версиями.
Сам aksusbd, при этом, не подвисает? Когда-то ранние версии Sentinel Run-time Installer этим грешили, самопроизвольным подвисанием, даже приходилось в cron-е скрипт держать, который проверял раз в несколько минут статус и, при необходимости, делал рестарт aksusbd.
Может, 8.3.16 ведет себя так с более старыми версиями.
Сам aksusbd, при этом, не подвисает? Когда-то ранние версии Sentinel Run-time Installer этим грешили, самопроизвольным подвисанием, даже приходилось в cron-е скрипт держать, который проверял раз в несколько минут статус и, при необходимости, делал рестарт aksusbd.
(17) aksusbd-7.100.1. Весь софт х64
никаких подвисаний не наблюдаю... используем эту версию пару месяцев.
Костыль после сегодняшнего случая тоже подставили... раз в сутки рестартовать весь этот зоопарк.
В логах вот это:
Dec 18 10:49:19 db kernel: [1888693.674150] INFO: task aksusbd_x86_64:542 blocked for more than 120 seconds.
Dec 18 10:49:19 db kernel: [1888693.674176] Tainted: G O 4.9.0-11-amd64 #1 Debian 4.9.189-3+deb9u2
Dec 18 10:49:19 db kernel: [1888693.674197] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
Dec 18 10:49:19 db kernel: [1888693.674213] aksusbd_x86_64 D 0 542 1 0x00000000
Dec 18 10:49:19 db kernel: [1888693.674215] 0000000000000086 ffff9e1c791e2800 0000000000000000 ffff9e1c7c8d3040
Dec 18 10:49:19 db kernel: [1888693.674217] ffff9e1cc51d8980 ffff9e1c7dd0a080 ffffb160c6fbfc38 ffffffff84619609
Dec 18 10:49:19 db kernel: [1888693.674218] ffff9e1878fe1840 0000000000000296 ffff9e1cc51d8980 ffffffffc01800b0
Dec 18 10:49:19 db kernel: [1888693.674219] Call Trace:
Dec 18 10:49:19 db kernel: [1888693.674224] [<ffffffff84619609>] ? __schedule+0x239/0x6f0
Dec 18 10:49:19 db kernel: [1888693.674225] [<ffffffff84619af2>] ? schedule+0x32/0x80
Dec 18 10:49:19 db kernel: [1888693.674232] [<ffffffffc0163546>] ? usb_kill_urb+0x86/0xc0 [usbcore]
Dec 18 10:49:19 db kernel: [1888693.674233] [<ffffffff840beb30>] ? prepare_to_wait_event+0xf0/0xf0
Dec 18 10:49:19 db kernel: [1888693.674238] [<ffffffffc0163ba2>] ? usb_start_wait_urb+0xe2/0x170 [usbcore]
Dec 18 10:49:19 db kernel: [1888693.674241] [<ffffffffc0163d0d>] ? usb_control_msg+0xdd/0x140 [usbcore]
Dec 18 10:49:19 db kernel: [1888693.674245] [<ffffffffc016e397>] ? proc_control+0x2d7/0x3f0 [usbcore]
Dec 18 10:49:19 db kernel: [1888693.674249] [<ffffffffc0170427>] ? usbdev_do_ioctl+0x717/0x1250 [usbcore]
Dec 18 10:49:19 db kernel: [1888693.674250] [<ffffffff84264f3e>] ? do_lock_file_wait+0x4e/0xd0
Dec 18 10:49:19 db kernel: [1888693.674254] [<ffffffffc0170f7a>] ? usbdev_ioctl+0xa/0x10 [usbcore]
Dec 18 10:49:19 db kernel: [1888693.674255] [<ffffffff84221c82>] ? do_vfs_ioctl+0xa2/0x620
Dec 18 10:49:19 db kernel: [1888693.674256] [<ffffffff84222274>] ? SyS_ioctl+0x74/0x80
Dec 18 10:49:19 db kernel: [1888693.674258] [<ffffffff84003b7d>] ? do_syscall_64+0x8d/0x100
Показать
Используем два сервера (одинаковое железо, одинаковый софт).
На первом этот глюк поймали сегодня, впервые. Сервер не сказать что сильно нагружен. 5 баз, около 50 сеансов.
На втором такого не наблюдал ни разу... правда на нем и нагрузки никакой
никаких подвисаний не наблюдаю... используем эту версию пару месяцев.
Костыль после сегодняшнего случая тоже подставили... раз в сутки рестартовать весь этот зоопарк.
В логах вот это:
Dec 18 10:49:19 db kernel: [1888693.674150] INFO: task aksusbd_x86_64:542 blocked for more than 120 seconds.
Dec 18 10:49:19 db kernel: [1888693.674176] Tainted: G O 4.9.0-11-amd64 #1 Debian 4.9.189-3+deb9u2
Dec 18 10:49:19 db kernel: [1888693.674197] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
Dec 18 10:49:19 db kernel: [1888693.674213] aksusbd_x86_64 D 0 542 1 0x00000000
Dec 18 10:49:19 db kernel: [1888693.674215] 0000000000000086 ffff9e1c791e2800 0000000000000000 ffff9e1c7c8d3040
Dec 18 10:49:19 db kernel: [1888693.674217] ffff9e1cc51d8980 ffff9e1c7dd0a080 ffffb160c6fbfc38 ffffffff84619609
Dec 18 10:49:19 db kernel: [1888693.674218] ffff9e1878fe1840 0000000000000296 ffff9e1cc51d8980 ffffffffc01800b0
Dec 18 10:49:19 db kernel: [1888693.674219] Call Trace:
Dec 18 10:49:19 db kernel: [1888693.674224] [<ffffffff84619609>] ? __schedule+0x239/0x6f0
Dec 18 10:49:19 db kernel: [1888693.674225] [<ffffffff84619af2>] ? schedule+0x32/0x80
Dec 18 10:49:19 db kernel: [1888693.674232] [<ffffffffc0163546>] ? usb_kill_urb+0x86/0xc0 [usbcore]
Dec 18 10:49:19 db kernel: [1888693.674233] [<ffffffff840beb30>] ? prepare_to_wait_event+0xf0/0xf0
Dec 18 10:49:19 db kernel: [1888693.674238] [<ffffffffc0163ba2>] ? usb_start_wait_urb+0xe2/0x170 [usbcore]
Dec 18 10:49:19 db kernel: [1888693.674241] [<ffffffffc0163d0d>] ? usb_control_msg+0xdd/0x140 [usbcore]
Dec 18 10:49:19 db kernel: [1888693.674245] [<ffffffffc016e397>] ? proc_control+0x2d7/0x3f0 [usbcore]
Dec 18 10:49:19 db kernel: [1888693.674249] [<ffffffffc0170427>] ? usbdev_do_ioctl+0x717/0x1250 [usbcore]
Dec 18 10:49:19 db kernel: [1888693.674250] [<ffffffff84264f3e>] ? do_lock_file_wait+0x4e/0xd0
Dec 18 10:49:19 db kernel: [1888693.674254] [<ffffffffc0170f7a>] ? usbdev_ioctl+0xa/0x10 [usbcore]
Dec 18 10:49:19 db kernel: [1888693.674255] [<ffffffff84221c82>] ? do_vfs_ioctl+0xa2/0x620
Dec 18 10:49:19 db kernel: [1888693.674256] [<ffffffff84222274>] ? SyS_ioctl+0x74/0x80
Dec 18 10:49:19 db kernel: [1888693.674258] [<ffffffff84003b7d>] ? do_syscall_64+0x8d/0x100
Используем два сервера (одинаковое железо, одинаковый софт).
На первом этот глюк поймали сегодня, впервые. Сервер не сказать что сильно нагружен. 5 баз, около 50 сеансов.
На втором такого не наблюдал ни разу... правда на нем и нагрузки никакой
месяц назад обновились с 8.3.13.1513 на 8.3.14.1976.
18.12.19 вышла новая конфа БП 3.0.75.37, требующая минимум 8.3.15.1747
Хотели обновиться на 8.3.16.1063, но почитав отзывы, решили остановиться на 8.3.15.1778.
На долго ли ее хватит не знаем.
18.12.19 вышла новая конфа БП 3.0.75.37, требующая минимум 8.3.15.1747
Хотели обновиться на 8.3.16.1063, но почитав отзывы, решили остановиться на 8.3.15.1778.
На долго ли ее хватит не знаем.
Установили платформу 8.3.16.1063 (клиент 32х, сервер 64х). При входе 17-го пользователя получил сообщение "Операция не может быьть выполнена с текущим составом лицензий...." Надо настроить параметры кластера сервера 1С как описано тут
В ЗУП 3.1.11.113 и 3.1.12.110 на форме документа "Исполнительный лист" по щелчку на гиперссылке(разворачиваемой группе реквизитов) аварийно вылетает клиент. Ошибка на уровне движка клиента. Решили изменением формы. Группа элементов из "свертываемая" на "обычная".
В ЗУП 3.1.11.113 и 3.1.12.110 на форме документа "Исполнительный лист" по щелчку на гиперссылке(разворачиваемой группе реквизитов) аварийно вылетает клиент. Ошибка на уровне движка клиента. Решили изменением формы. Группа элементов из "свертываемая" на "обычная".
Поставили 16, так как последний релиз ЗУП требовал именно 16 версию программы.
Была та же самая ошибка. Переустановили платформу на сервере, но установили только админку и клиента. Ошибка вроде бы ушла.
Но теперь RPHost отжирает всю память, а RMNGR загружает процессор 100%. Написал письмо в 1С жду ответа. Сейчас буду пробовать ставить 15 платформу.
Была та же самая ошибка. Переустановили платформу на сервере, но установили только админку и клиента. Ошибка вроде бы ушла.
Но теперь RPHost отжирает всю память, а RMNGR загружает процессор 100%. Написал письмо в 1С жду ответа. Сейчас буду пробовать ставить 15 платформу.
Вот такая версия 1с 8.3.25.1394
Windows server 2012 в нем наблюдается потеря ключа сервера каждое утро пока не ребутнешь службу 1с.
В другом офисе была похожая ошибка сервер тоже 2012 почему я думаю с ним какая то несовместимость у 1с на 2022 такого вродь не наблюдается.
Windows server 2012 в нем наблюдается потеря ключа сервера каждое утро пока не ребутнешь службу 1с.
В другом офисе была похожая ошибка сервер тоже 2012 почему я думаю с ним какая то несовместимость у 1с на 2022 такого вродь не наблюдается.
Сервер на нем развернут vmware esxi 8 вирт машина сервер 2012 в нее прокинуты два usb ключа . Ключ на 10 пользователей. Работает как часы . И ключ на запуск сервера. И вот ключ на запуск сервера отваливается после того как пару часов не пользуются сервером 1с . Хотя запускаются иногда регламентные задания вижу их в консоле. В 23 -00 скриптом делаются копии все юзеры завершают работу в 18-00. Копии тоже самое файловые базы архивируются всегда но sql базы раз через раз. Видимо в тот момент если кто то задержался на работе и проработал до 22 то в 23-00 копии делаются нормально. Если де все закрыли 1с в 18 то копии не делаются зависает процесс ибо ключа га запуск сервера не обнаружено. То же самое с утра . Иногда юзеры приходят в 6-00 иногда в 7-00 иногда в 8-00 посему запускать скрипт перезапуска сервера не понятно во сколько. Физически ключ сфотографирую позже. Сервер работает в режиме макс производительности. В сон не уходит. Так же в настройках юзб запретил управлять питанием. В логах
Прикрепленные файлы:
Это логи устройств. Видно что ничего не видно ключ не отключался и не отваливался от сервера уже 4 дня но 1с каждое утро его теряет. 20 числа удалено и подключено устройство это я нажал установить драйвера ключа защиты из релиза 1с .
Прикрепленные файлы:
Крайне информативный ответ. Сам отвечаю на свой вопрос . Итого на сервере недавно появились две новых базы. И две тестовых. И началось . Происходит следующее один процесс на 8 баз данных по дефолту потребляет более 3гб в результате 32х не справляется в этот момент происходит отвал ключа. Подправил каждой базе свой процесс полет нормальный всем всего хватает. В настройках кластера где то там. Ночью в 4 тестовых базах и основных 4 крутятся регламентные задания и к утру видимо память переваливает за 3 гб и процесс зависает . Он вродь как работает. Но процесс более 3гб висит (его видно в консоли управления сервером) и ключ отваливается. И подключения более не идут тип нет ключа. А когда перезапускаешь службу процессы 1с удаляются и заново все работает. И происходит это все как раз в тот момент когда добавляешь на сервер новые базы. И бац ключик отваливается. Посему вмварь тут не при делах.
(37)
Тогда не совсем понятно, почему с ваших слов "наблюдается потеря ключа сервера каждое утро", а не днем в момент наивысшей нагрузки.
Количество ИБ на процесс - это же вроде функционал КОРП, т.е. его можно изменить только в случае, если в одной базе запущено не более 10 одновременных сеансов, а при запуске 11-го сервер должен выдать что-то вроде: "Операция не может быть выполнена с текущим составом лицензий. Использование этих функций возможно только для лицензий на платформу уровня КОРП".
Или в новых версиях что-то изменилось?
Происходит следующее один процесс на 8 баз данных по дефолту потребляет более 3гб в результате 32х не справляется в этот момент происходит отвал ключа.
Тогда не совсем понятно, почему с ваших слов "наблюдается потеря ключа сервера каждое утро", а не днем в момент наивысшей нагрузки.
Подправил каждой базе свой процесс полет нормальный всем всего хватает.
Количество ИБ на процесс - это же вроде функционал КОРП, т.е. его можно изменить только в случае, если в одной базе запущено не более 10 одновременных сеансов, а при запуске 11-го сервер должен выдать что-то вроде: "Операция не может быть выполнена с текущим составом лицензий. Использование этих функций возможно только для лицензий на платформу уровня КОРП".
Или в новых версиях что-то изменилось?
Для получения уведомлений об ответах подключите телеграм бот:
Инфостарт бот