8.3 бух 3.0 долго открывает список пользователей
Приветствую. На вашем форуме впервые, так что не обессудьте.
8.3 бух 3.0 долго открывает список пользователей. Куда копать непонятно.
Совершенно рандомно, после выбора базы, происходит задержка, окно со списком пользователей можно ждать от 15 сек до 2,5 минут. такое далеко не всегда. бух баз несколько, говорят что такое только с ними, УТ типа работает нормально.
Сервер терминальный Windows Server 2008 R2 Standard 6.1.7601 Service Pack 1 сборка 7601.
Лицензии программные, также вставлен ключ на 5 лицензий, но он не используется походу, LM стоит там же. галка использовать аппаратную лицензии стоит у юзеров.
1С:Предприятие 8.3 (8.3.7.2008)
лицензии лежат тут
Бухгалтерия предприятия, редакция 3.0 (3.0.43.173)
Тонкий клиент
Серверный (сжатие: усиленное)
расход ОЗУ в среднем - 17,7 из 32 гб
cpu - 0-15% i7-2600.
Используется сервер 1с. конфига пока не знаю.
на прошлой неделе смог помониторить с помощью process monitor, поймал тупняк, но там какой то ад. названиям серверов верить нельзя, srvbase это терминал, а srvterm это сервак 1с.
зачем терминал ломится сам себе на 1540 вообще не понятно. и это самое интересное.
серваки не наши, поэтому что там и как неизвестно.
лог - это промежуток от выбора базы, до загрузки окна списка пользователей
8.3 бух 3.0 долго открывает список пользователей. Куда копать непонятно.
Совершенно рандомно, после выбора базы, происходит задержка, окно со списком пользователей можно ждать от 15 сек до 2,5 минут. такое далеко не всегда. бух баз несколько, говорят что такое только с ними, УТ типа работает нормально.
Сервер терминальный Windows Server 2008 R2 Standard 6.1.7601 Service Pack 1 сборка 7601.
Лицензии программные, также вставлен ключ на 5 лицензий, но он не используется походу, LM стоит там же. галка использовать аппаратную лицензии стоит у юзеров.
1С:Предприятие 8.3 (8.3.7.2008)
лицензии лежат тут
Бухгалтерия предприятия, редакция 3.0 (3.0.43.173)
Тонкий клиент
Серверный (сжатие: усиленное)
расход ОЗУ в среднем - 17,7 из 32 гб
cpu - 0-15% i7-2600.
Используется сервер 1с. конфига пока не знаю.
на прошлой неделе смог помониторить с помощью process monitor, поймал тупняк, но там какой то ад. названиям серверов верить нельзя, srvbase это терминал, а srvterm это сервак 1с.
зачем терминал ломится сам себе на 1540 вообще не понятно. и это самое интересное.
серваки не наши, поэтому что там и как неизвестно.
лог - это промежуток от выбора базы, до загрузки окна списка пользователей
По теме из базы знаний
- Перенос данных из УПП 1.3 / КА 1.1 в БП 3. Переносятся документы, справочники и начальные остатки
- [8.3] Журнал документов по контрагенту для БП 3.0 + Восстановление последовательности проведения документов контрагента
- Анализ расхождений выручки НДС и Налога на прибыль в декларациях (БП 3.0 ПРОФ и КОРП, КА 2, ЕRP)
- Обработка обмена из Комплексной автоматизации 1.1 (2012г.) в Бухгалтерию 3.0 (для сотен организаций с плохими данными)
- Система интерактивных ролей и обработчиков с возможностью интерактивной настройки и не только (платформа 8.3.17+, расширение) для УТ 11 (все), КА 2, ERP 2, Розница 2, УНФ 1.6/3.0, БП 3, ЗУП 3.1, ААА 6
Ответы
Подписаться на ответы
Инфостарт бот
Сортировка:
Древо развёрнутое
Свернуть все
(3) starik-2005, на терминале nethasp.ini? там NH_SERVER_ADDR = IP адрес терминала, больше ничего нет. но как видно по логам, на 475 порт обращения ни разу нет, он получает программные лицензии.
интересует что такого можно было там наделать что он продолжает ломится себе на порт 1540 %) зачем вообще %)
(2) drim87, "Почисти кеш 1с для начала и смотри монитор ресурсов при запаске базы (на диски в первую очередь)"
диски на sql-сервере смотреть? смущает то что утверждают УТ работает ок, хотя доверия пользователям у меня 0.
вообщем я понял что нужно вникать целиком и полностью во всю инфраструктуру, где что, на каких дисках, может там действительно буховские базы на тормозных дисках лежат.
интересует что такого можно было там наделать что он продолжает ломится себе на порт 1540 %) зачем вообще %)
(2) drim87, "Почисти кеш 1с для начала и смотри монитор ресурсов при запаске базы (на диски в первую очередь)"
диски на sql-сервере смотреть? смущает то что утверждают УТ работает ок, хотя доверия пользователям у меня 0.
вообщем я понял что нужно вникать целиком и полностью во всю инфраструктуру, где что, на каких дисках, может там действительно буховские базы на тормозных дисках лежат.
(5) chastener, да. Диски проверь там где базы лежат. Порт 1540 это порт кластера серверов - так что ничего удивительного что он туда ломится. Там по идее целая пачка портов 1540 - кластер(ragent), 1541 менеджер кластера(rmngr) и диапазон 1560-1590 для рабочих процессов rphost (с диапазоном мог напутать, не помню я его). ТАк что ломится он у тебя на сервер 1с в процесс ragent, а вот что он там дальше делает и почему тупит нужно искать. По идее если поверить пользователям (но лучше проверить) нужно смотреть либо в сторону производительности дисков где хранится база либо причина в самой базе. Возможно там никогда не делалось обслуживание, тут я имею в виду, шринк, чистка процедурного кеша, дефрагментация и реиндексация индексов. После реиндексации обычно по первости наоборот подтупливает, но делать это все же иногда надо...раз в неделю например.
Вообще в этом вопросе нужно на все смотреть. Бывает до нелепости доходит. Выше про nethasp.ini писали, вот я про такое только с форумов слышал, но якобы бывает такое что 1с много времени тратит на проверку параметров в этом конфиге, ищет серваки если они там в списке определены, если включен опрос сети на наличие сереверов с nhasp то еще и сеть опрашивает. В теории такое вполне может получиться.
Вообще в этом вопросе нужно на все смотреть. Бывает до нелепости доходит. Выше про nethasp.ini писали, вот я про такое только с форумов слышал, но якобы бывает такое что 1с много времени тратит на проверку параметров в этом конфиге, ищет серваки если они там в списке определены, если включен опрос сети на наличие сереверов с nhasp то еще и сеть опрашивает. В теории такое вполне может получиться.
(6) drim87, ну мне сказали что в nethasp полезли уже после начала тормозов, типа думали из-за лицензий тормоза.....
на 1540 он вообще не должен обращаться по идее, только на порт менеджера кластера, а это 1541, я это проверил в нашей сети еще спецом, всё именно так, только 1541, потом уже с портом рабочего процесса идет общение. в данном же случае идет обращение не на сервер 1с, а самому себе, возможно из-за каких-то перетасовок ролей серверов между собой, в общем дело ясное, что дело тёмное.
на 1540 он вообще не должен обращаться по идее, только на порт менеджера кластера, а это 1541, я это проверил в нашей сети еще спецом, всё именно так, только 1541, потом уже с портом рабочего процесса идет общение. в данном же случае идет обращение не на сервер 1с, а самому себе, возможно из-за каких-то перетасовок ролей серверов между собой, в общем дело ясное, что дело тёмное.
Все что угодно может быть. Почисти кеш 1с для начала и смотри монитор ресурсов при запаске базы (на диски в первую очередь). И только потом уже копай дальше. Смени плтформу, выполни ТиС базы (бекап сделать не забудь). Выполни регламентые операции по обслуживанию базы рекомендованые 1с: помимо того что там есть шринк лога транзакций выполни.
Соберите технологический журнал, ищите длительные события или задержки между событиями.
<?xml version="1.0" encoding="UTF-8"?>
<config xmlns="http://v8.1c.ru/v8/tech-log">
<dump create="true" location="C:\1C\dumps" type="3" prntscrn="true"/>
<log location="C:\1C\v83\logs\" history="2">
<event>
<ne property="Name" value=""/>
</event>
<Property Name="All"/>
</log>
</config>
Показать
Для получения уведомлений об ответах подключите телеграм бот:
Инфостарт бот