Добрый день. Помогите пожалуйста решить проблему.
Недавно перешли по импортозамещению на Astra Linux Орел
На скриншоте видны характеристики сервера.
Версия ОС сервера - 2.12.40
Версия ОС клиентских машин - 2.12.42
Версия 1С - Предприятие 8.3 (8.3.15.2107)
Проблем конечно хватает с этой ОС, но они в принципе сильно работу не тормозят.
Самая главная проблема, которая появилась - зависание 1С (толстый клиент) при подключении посредством RDP. Зависания происходят бывает 3 раза в день, а бывает и чаще.
Не важно подключиться через Remmina или через xfreerdp.
Зависает как правило когда работают несколько человек в 1С одновременно (человек 6). Проблема наблюдается у трех пользователей с остальными проблем не наблюдал. Если у одного пользователя зависает 1С, все остальные работают без зависания, но чувствуется, что система работает "в напряг".
После зависания окна 1С приходится закрывать процесс 1С через "Системный монитор".
После закрытия 1С и повторном запуске 1С продолжает зависать при каком-либо действии. Бывает зависнет сразу при клике на любую кнопку на панели задач 1С, а бывает зависает при работе с документом, при вызове какого-либо раздела.
Далее выявил закономерность. Если на учетке Buh1 зависло, то так и будет зависать, хоть сколько раз перезапускай 1С. Приходится заходить в 1С под другой учеткой Buh2. Тогда 1С работает без зависаний, но это не всегда стабильно и не всегда помогает. Помогало также смена пользователя 1С. Заходил вместо Бухгалтера на ее компьютере под своей учеткой 1С и она не зависала.
Когда зависает окно 1С, окно программы замирает, становится неактивным. Его можно свернуть, передвинуть и т.д. но оно становится однотонным серым.
При зависании в Системной мониторе в Таблице процессов, напротив зависшего процесса в разделе ЦП (центральный процессор) стоит значение 25% или 1/4 суммарного потребления процессорного времени процессором. То есть одно ядро из 4 грузится дико и по полной на 100%.
Если долго подождать, то окно может развиснуть и выполнить действие, которое сотрудник последний раз предпринял. (нажал к примеру на какой-нибудь значок на панели задач). Потом снова висит.
Ну этому есть объяснение - ядро отведенное под данный процесс 1С загружено под 100%, соответственно можно и не ждать, что 1С будет работать стабильно.
Ключ 1С аппарантный. Попробовали выгрузить модуль ядра vhci-hcd." - ситуация не изменилась.
Куда копать??? Так невозможно работать. С ОС Windows привыкли работать, проблем не было, а Астра это ппц.....
Техподдержка Linux утверждают что проблема у 1С, а 1С говорят что проблема у Астры.
Очень прошу помочь, работать просто невозможно!!!!
Недавно перешли по импортозамещению на Astra Linux Орел
На скриншоте видны характеристики сервера.
Версия ОС сервера - 2.12.40
Версия ОС клиентских машин - 2.12.42
Версия 1С - Предприятие 8.3 (8.3.15.2107)
Проблем конечно хватает с этой ОС, но они в принципе сильно работу не тормозят.
Самая главная проблема, которая появилась - зависание 1С (толстый клиент) при подключении посредством RDP. Зависания происходят бывает 3 раза в день, а бывает и чаще.
Не важно подключиться через Remmina или через xfreerdp.
Зависает как правило когда работают несколько человек в 1С одновременно (человек 6). Проблема наблюдается у трех пользователей с остальными проблем не наблюдал. Если у одного пользователя зависает 1С, все остальные работают без зависания, но чувствуется, что система работает "в напряг".
После зависания окна 1С приходится закрывать процесс 1С через "Системный монитор".
После закрытия 1С и повторном запуске 1С продолжает зависать при каком-либо действии. Бывает зависнет сразу при клике на любую кнопку на панели задач 1С, а бывает зависает при работе с документом, при вызове какого-либо раздела.
Далее выявил закономерность. Если на учетке Buh1 зависло, то так и будет зависать, хоть сколько раз перезапускай 1С. Приходится заходить в 1С под другой учеткой Buh2. Тогда 1С работает без зависаний, но это не всегда стабильно и не всегда помогает. Помогало также смена пользователя 1С. Заходил вместо Бухгалтера на ее компьютере под своей учеткой 1С и она не зависала.
Когда зависает окно 1С, окно программы замирает, становится неактивным. Его можно свернуть, передвинуть и т.д. но оно становится однотонным серым.
При зависании в Системной мониторе в Таблице процессов, напротив зависшего процесса в разделе ЦП (центральный процессор) стоит значение 25% или 1/4 суммарного потребления процессорного времени процессором. То есть одно ядро из 4 грузится дико и по полной на 100%.
Если долго подождать, то окно может развиснуть и выполнить действие, которое сотрудник последний раз предпринял. (нажал к примеру на какой-нибудь значок на панели задач). Потом снова висит.
Ну этому есть объяснение - ядро отведенное под данный процесс 1С загружено под 100%, соответственно можно и не ждать, что 1С будет работать стабильно.
Ключ 1С аппарантный. Попробовали выгрузить модуль ядра vhci-hcd." - ситуация не изменилась.
Куда копать??? Так невозможно работать. С ОС Windows привыкли работать, проблем не было, а Астра это ппц.....
Техподдержка Linux утверждают что проблема у 1С, а 1С говорят что проблема у Астры.
Очень прошу помочь, работать просто невозможно!!!!
Прикрепленные файлы:
По теме из базы знаний
Ответы
Подписаться на ответы
Инфостарт бот
Сортировка:
Древо развёрнутое
Свернуть все
Не важно подключиться через Remmina или через xfreerdp.
Зависает как правило когда работают несколько человек в 1С одновременно (человек 6). Проблема наблюдается у трех пользователей с остальными проблем не наблюдал. Если у одного пользователя зависает 1С, все остальные работают без зависания, но чувствуется, что система работает "в напряг".
может сначала выяснить, что вы ждете от файловой базы ( ведь она у вас файловая ) - и при таком количестве пользователей
без наличия специалиста по линукс, как вы себе видите удаленную настройку системы :
нажать....ввести комбинацию...?
есть же публикация на апачи и подключение тонким клиентом.
у вас видеокарта присутствует NVIDIA ?
Зависает как правило когда работают несколько человек в 1С одновременно (человек 6). Проблема наблюдается у трех пользователей с остальными проблем не наблюдал. Если у одного пользователя зависает 1С, все остальные работают без зависания, но чувствуется, что система работает "в напряг".
может сначала выяснить, что вы ждете от файловой базы ( ведь она у вас файловая ) - и при таком количестве пользователей
без наличия специалиста по линукс, как вы себе видите удаленную настройку системы :
нажать....ввести комбинацию...?
есть же публикация на апачи и подключение тонким клиентом.
у вас видеокарта присутствует NVIDIA ?
Тонкий клиент со слов обслуживающей организации мы поставить не сможем. Якобы что-то не встанет. Точно не могу сказать, наверное что-то связано с платформой.
Что значит опубликовать базу через апач? Очень заинтересовало.
Что значит опубликовать базу через апач? Очень заинтересовало.
Да все потому, что все ОС Астра Линукс были приобретены на столько неожиданно и хаотично, что даже ничего не успели изучить. Да и организация производившая установку ОС нассала в уши, что проблем с этой ОС не возникает.
Про убунту вообще не размышляли. Наверное по неопытности. У нас в городе мало кто шарит в ОС Линукс
Про убунту вообще не размышляли. Наверное по неопытности. У нас в городе мало кто шарит в ОС Линукс
1. Толстый клиент виснет независимо от линуха - это болячка связана именно с RDP. У нас поднят xRDP и периодически конфигуратор виснет, в тонком клиенте проблем нет от слова совсем.
2. Апач тут не подойдет, ибо толстый клиент не умеет через него от слова никак.
3. Да. проблема решается путем подключения от другого юзера.
4. Проблема в 1С и xRDP совместно.
Заметил, что периодически не отрабатывает событие mouseUp мыши именно в 1С, при этом, получается, нажатие кнопки мыши вызывает ее "залипание" и любое движение производит перенос фактически того, то под курсором мыши. В конфигураторе легко копируется список справочников в список документов, например, в итоге все виснет до завершения ))) Ну тут явно косяк 1С - не могут сделать перетаскивание с вопросом, ибо вряд ли найдется человек в своем уме, который бы перетащил справочники в документы )))
Да, если вы хотите продолжать работать в обычном приложении и использовать Linux, то это будет проблемным, пока 1с не разберется с поведением своего приложения в этой среде. И раз она запилила обычные формы в виде отдельных компонентов, чесено где-то потыреных )могу ошибаться), то есть смысл разобраться с внутренним их поведением и отпусканием левой кнопки мыши.
2. Апач тут не подойдет, ибо толстый клиент не умеет через него от слова никак.
3. Да. проблема решается путем подключения от другого юзера.
4. Проблема в 1С и xRDP совместно.
Заметил, что периодически не отрабатывает событие mouseUp мыши именно в 1С, при этом, получается, нажатие кнопки мыши вызывает ее "залипание" и любое движение производит перенос фактически того, то под курсором мыши. В конфигураторе легко копируется список справочников в список документов, например, в итоге все виснет до завершения ))) Ну тут явно косяк 1С - не могут сделать перетаскивание с вопросом, ибо вряд ли найдется человек в своем уме, который бы перетащил справочники в документы )))
Да, если вы хотите продолжать работать в обычном приложении и использовать Linux, то это будет проблемным, пока 1с не разберется с поведением своего приложения в этой среде. И раз она запилила обычные формы в виде отдельных компонентов, чесено где-то потыреных )могу ошибаться), то есть смысл разобраться с внутренним их поведением и отпусканием левой кнопки мыши.
Для тонкого клиента нужна БГУ 2.0 и перенос данных в нее из БГУ 1.0.
Для 6-ти и выше одновременных пользователей желателен полноценный клиент-серверный вариант с соответствующими вычислительными ресурсами, а не "сервер" с 8 ГБ памяти. В роли СУБД - PostgreSQL.
Естественно - все 64-х разрядное.
Думаю, что когда действительно станет невозможно работать, подобного рода мысли станут приниматься во внимание, а финансирование найдется довольно быстро.
Для 6-ти и выше одновременных пользователей желателен полноценный клиент-серверный вариант с соответствующими вычислительными ресурсами, а не "сервер" с 8 ГБ памяти. В роли СУБД - PostgreSQL.
Естественно - все 64-х разрядное.
Думаю, что когда действительно станет невозможно работать, подобного рода мысли станут приниматься во внимание, а финансирование найдется довольно быстро.
Вот сейчас работают несколько человек. Все идет идеально. Загрузка система просто мизерная. Потом в один прекрасный момент у одного из двух бухгалтеров зависает 1С. И одно ядро начинает грузиться до 100%. Видимо они выполняют какое-то действие которое приводит к залипанию процесса.
Прикрепленные файлы:
Сам искал инфу по этому вопросу. Вот к чему я пришел.:
* проблема с обычными формами на linux машинах. Может не на всех релизах, но на Ubuntu точно. Работает нормально, нормально. Потом, бах завис и грузит одно ядро на 100%. Через несколько минут отвисает. Вообщем если у вас старая конфигурация (УПП и т.п.) ставим винду.
* если у вас управляемые формы (УНФ, УТ >=1.4, ERP) то можно запускать на линуксе. да и вообще веб клиент есть.
у меня конфигурации: Ubuntu 18.04, виртуалка Ubuntu 18.04 под kvm, 1с от 8.3.18 до 8.3.22.
* проблема с обычными формами на linux машинах. Может не на всех релизах, но на Ubuntu точно. Работает нормально, нормально. Потом, бах завис и грузит одно ядро на 100%. Через несколько минут отвисает. Вообщем если у вас старая конфигурация (УПП и т.п.) ставим винду.
* если у вас управляемые формы (УНФ, УТ >=1.4, ERP) то можно запускать на линуксе. да и вообще веб клиент есть.
у меня конфигурации: Ubuntu 18.04, виртуалка Ubuntu 18.04 под kvm, 1с от 8.3.18 до 8.3.22.
(30) Случайно обнаружил, что зависание 1С (1 ядро грузится на 100%) связано не с самой 1С, а с аппаратным ключем. При использовании програмного ключа все работает стабильно.
Попробую еще прикрутить аппаратный ключ через сервер лицензирования. Отпишусь что получилось.
Попробую еще прикрутить аппаратный ключ через сервер лицензирования. Отпишусь что получилось.
(33) Выгрузка модуля не помогает. Уловил закономерность в использовании буфера обмена. Как только я делаю снимок экрана или копирую "не текстовое" содержимое в буфер обмена, 1С зависает с загрузкой ядра на 100%, до следующего действия. Но как только я в буфер помещаю "текстовое" (простое) содержимое, система ожидает завершения последнего действия и далее работает как ожидается (без зависания).
(34) Было такое, что сеанс на рдп-сервере на Дебиан подвисал, когда в буфере обмена что-то "непотребное" находилось. Сворачивали рпд-соединение, копировали какой-нибудь текст, отвисало. Кажется, обновлением Дебиана эту проблему решили, больше года уже нет такого. С 1С не связана, можно было и просто рабочий стол подвесить.
Проблема наблюдается только в обычных формах. В управляемых формах такой проблемы нет.
1С:Предприятие 8.3 (8.3.23.1739)
Операционная система: Astra Linux Special Edition
Обновление: 1.7.4.7
Архитектура: x86, 64-разрядная
Ядро: 5.15.0-70-generic
Графическая платформа: X11
Процессоры: 2 × Intel Xeon Processor (Icelake)
Память: 1,9 ГиБ ОЗУ
Графический процессор: llvmpipe
1С:Предприятие 8.3 (8.3.23.1739)
Операционная система: Astra Linux Special Edition
Обновление: 1.7.4.7
Архитектура: x86, 64-разрядная
Ядро: 5.15.0-70-generic
Графическая платформа: X11
Процессоры: 2 × Intel Xeon Processor (Icelake)
Память: 1,9 ГиБ ОЗУ
Графический процессор: llvmpipe
На CentOS 8 Stream на обычных формах тоже периодически зависает с загрузкой 1 ядра на 100% в разных ситуациях не зависимо от версии платформы: при работе в разных внешних обработках (стандартных и нестандартных) - чаще всего. Решения этой проблемы так и нет?
1С 8.3.23.1865
Клиент-сервер
Лицензия программная
Использование аппаратной защиты выключено
postgre
Ubuntu 20.04.6 LTS (Focal Fossa)
xRDP
Модуль vhci-hcd выгружен.
Проблема имеется.
Виснет конфигуратор с загрузкой одного ядра на 100%
Фризится минут на 10, потом сам отвисает. За день может раз 10 так. Работать затруднительно.
В момент фриза иногда (но не всегда) есть артефакты отрисовки окон: часть окна конфигуратора на переднем плане заслоняет все остальное и не сворачивается, пока не отвиснет.
Проблема почти всегда возникает, когда в базе есть другие пользователи и они активно работают (есть загрузка сервера). Не важно, как они зашли, через web-клиент, тонкий клиент, или другой сеанс xRDP.
Когда конфигуратор единственный сеанс - проблема не возникает.
С буфером обмена не связано. Когда сеанс единственный, через буфер нормально передаются и тексты и картинки и файлы, ничего не виснет.
С обработкой событий устройств ввода, возможно, связано. Иногда фризится прямо на глазах при попытке проскроллить список перетягиваниьем ползунка в окне конфигурации. Также замечено, что проблема возникает при попытке найти что то в окне конфигурации по первым буквам подбором (не поиск по подстроке, который сверху).
При этом в тонких клиентах проблемы нет, в том числе и если запускать их в сеансе xRDP.
С другими приложениями (коих немало) в xRDP проблемы нет.
Кто нибудь решил эту проблему?
Клиент-сервер
Лицензия программная
Использование аппаратной защиты выключено
postgre
Ubuntu 20.04.6 LTS (Focal Fossa)
xRDP
Модуль vhci-hcd выгружен.
Проблема имеется.
Виснет конфигуратор с загрузкой одного ядра на 100%
Фризится минут на 10, потом сам отвисает. За день может раз 10 так. Работать затруднительно.
В момент фриза иногда (но не всегда) есть артефакты отрисовки окон: часть окна конфигуратора на переднем плане заслоняет все остальное и не сворачивается, пока не отвиснет.
Проблема почти всегда возникает, когда в базе есть другие пользователи и они активно работают (есть загрузка сервера). Не важно, как они зашли, через web-клиент, тонкий клиент, или другой сеанс xRDP.
Когда конфигуратор единственный сеанс - проблема не возникает.
С буфером обмена не связано. Когда сеанс единственный, через буфер нормально передаются и тексты и картинки и файлы, ничего не виснет.
С обработкой событий устройств ввода, возможно, связано. Иногда фризится прямо на глазах при попытке проскроллить список перетягиваниьем ползунка в окне конфигурации. Также замечено, что проблема возникает при попытке найти что то в окне конфигурации по первым буквам подбором (не поиск по подстроке, который сверху).
При этом в тонких клиентах проблемы нет, в том числе и если запускать их в сеансе xRDP.
С другими приложениями (коих немало) в xRDP проблемы нет.
Кто нибудь решил эту проблему?
(39)
Ровно такая же проблема на Debian11 + xRDP + 1C 8.3.24.1368
Модуля vhci-hcd я в Debian не нашел, поэтому выгрузил usbip.
Собственно зависания с артефактами происходят не всегда, но они есть.
Именно и только при работе в толстом клиенте(конфигураторе).
При пробрасывании с клиента на сервер буфера не с текстовым содержимым, проблема возникает сразу же.
С отключенным буфером и дисками(в настройках ярлыка RDP) проблема возникает достаточно редко, но не исчезает совсем.
Ровно такая же проблема на Debian11 + xRDP + 1C 8.3.24.1368
Модуля vhci-hcd я в Debian не нашел, поэтому выгрузил usbip.
Собственно зависания с артефактами происходят не всегда, но они есть.
Именно и только при работе в толстом клиенте(конфигураторе).
При пробрасывании с клиента на сервер буфера не с текстовым содержимым, проблема возникает сразу же.
С отключенным буфером и дисками(в настройках ярлыка RDP) проблема возникает достаточно редко, но не исчезает совсем.
Для получения уведомлений об ответах подключите телеграм бот:
Инфостарт бот