Процессор Intel 2667V4 (14 ядер) ОЗУ 128
ОС Server 2019
MSsql 16
1с 8.3.23.1865
Web сервер
Базы 1с все стандартные.
С диск система SSD 2.5 1.6TB SAS 12Gb/s
D диск базы NVM-e SSD Intel DC P3605 1.6TB PCI Express
E диск для архивов
F диск логов баз NVM-e SSD Intel DC P3605 1.6TB PCI Express 2 диск
Тест Гилева показывает 30-33 если не нагружен. Если работают пользователи человек 50, то показывает 20-23.
Все работа только через веб сервер
Сервер установлен в дата центре
Проблема следующая:
1. запуск до появление логина очень долгий
2. После ввода пароля тоже долго запускается.
3. В консоле сервера 1с очень долго бывает открывается свойства базы
Потом в течении часа все по этой базе запускается быстро. если в базе работают то тоже быстро.
В самой базе работа комфортная ничего не тормозит.
Это происходит даже в том случае когда с базами никто не работает (после перезагрузки к примеру). т.е. на сервере ты один и запускаешь базу и все долго. После этого если базу запустить через вэбсервер все откроется быстро 5-6 секунд с другой машины которая находится за 1000 км.
Попытки решения:
1. логи сервера даже переносить на диск с базами (NMM-e) на диск с логами (NMM-e)ничего не помогло
2. tempdb.mdf и templog.ldf тоже перемещал по NMM-e
3. Делал Микс между 1 и 2
4. Обновлял платформу на последнию 23 и 24 тоже не помогло
5. Отключение всех регламентных заданий в каждой базе
Если будут идеи которые помогут 100 $ добавится к вознаграждению.
Вот в это время смотреть монитор ресурсов Windows - какой компонент системы загружен по максимуму? Процессор? Память? Диск? Какой? Отсюда и начинать плясать.
После этого если базу запустить через вэбсервер все откроется быстро 5-6 секунд с другой машины которая находится за 1000 км.
А пользователь базы 1С, который "на машине за 1000 км" - тот же самый? Или другой/любой?
Потому что описанная картина сильно смахивает на проблемы с кэшем, вот только каким? Либо системным (кэширование данных диска в ОЗУ), либо 1С - известные папки в %AppData%.
А есть еще и серверный кэш...
Может быть, где-то в планировщике ОС прописана принудительная ошибка кэша чем-то вроде моей давнишней примочки - вот вам и тормоза при его создании.
Вот и проблема что ничего и не загружено чтобы копать в эту сторону.
пользователь любой может быть главное что хоть кто-то зашел или сидит в базе. и тогда запускается быстро.
с кэшом переносил его на разные пользователей и на разные диски не помогло Система чистая ничего не ставил чтобы было в планировщике.
sel ect program_name, net_transport
fr om sys.dm_exec_sessions as t1
left join sys.dm_exec_connections AS t2
ON t1.session_id=t2.session_id
where not t1.program_name is null
Ответ был shared memory
(1)
Давайте проверим гипотезу, что частично это из-за лицензий 1с.
Нужно установить на компьютер пользователя локальную лицензию 1с.
В первую очередь поиск лицензии идет на локальном компе.
Команда пинг (ping) Команда ping - специальная программа для проверки доступности сетевых ресурсов. Специалисты по сетевым технологиям используют команду ping чаще любой другой команды, хотя действие, выполняемое этой командой - самое элементарное. Команда ping посылает на указанный хост пакет заданного размера, который затем возвращается обратно.
Ниже 10 пакетов для проверки соединения мало, рекомендую отправлять по 100. Обратите внимание, что потери пакетов быть не должно. Допустимый % потерь составляет 1-2 пакета из 100, но и это уже не хорошо. Если потерянных пакетов вы не видите, то просмотрите лог на скачкИ пинга. Т.е. пинг должен быть примерно ровный. А если вы вдруг видите разброс типа этого:
C:\Documents and Settings\PC>ping -n 10 ya.ru
Команда tracert (traceroute) Очень часто пользователи задаются вопросом, с чем связана разница в написании tracert и traceroute? На самом деле, команда tracert применяется в операционных системах Windows, а traceroute - в операционных системах Linux и в операционной системе маршрутизаторов Cisco.
Пример вывода информации командой tracert:
c:\windows\system32>tracert ya.ru
(10)
Если это не локальная сеть, нужно ещё проверять скорость интернета.
Далее, переходим к программе 1с. Запускаем Конфигуратор и на корне переходим в
Модуль управляемого приложения.
Там можно поставить точки остановки, посмотреть как быстро отрабатывает код.
Может у вас есть Расширения на конфигурации, тогда нужно ещё их посмотреть.
(12) скорость интернета 1 Гбит, тут без разницы как запустить базу. если первый раз открылась 240-300 секунд то последующий раз открывается 5 секунд. если несколько часов прошло то до 60 секунд.
Расширений нет базы как во фрэше.
(13)
в современных версиях при запуске программы проводится поиск не только аппаратного, но и программного ключа защиты, что занимает достаточно много времени. Этот процесс поддается оптимизации.
Управляющие файлы находятся в каталоге:
Для 8.1 — C:\Program files\1Cv81\bin\conf\
Для 8.2 — C:\Program files\1Cv82\conf\
Файл управления ключами 1С называется nethasp.ini.
Вам необходимо найти блок, отмеченный строкой [NH_TCPIP]
Там Вы увидите ряд определенных параметров, которые должны быть изначально отключены (строка начинается со знаков «;;»).
Вся Ваша задача сводится к тому, что нужно включить определённые параметры: (просто удалить из начала строки «;;»).
Найдите параметр «NH_USE_BROADCAST» — именно он отвечает за широковещательную рассылку.
Следующий, подлежащий изменению, параметр «NH_SERVER_ADDR» — он отвечает за прямой IP адрес сервера, где находятся ключи 1С. Укажите его для того чтобы 1С сразу обращалась к yepyeve IP, тем самым ускорив свою загрузку.
1. какие флаги прописаны в MSSQL (ну и прописаны ли вообще). Пропиши (если нету) -T1211, -T1224, -T2330, -T2371, -T4199, -T8048
2. Что там с параллелизмом, если не менял, то измени на (в свойствах сервера MSSQL вкладка Дополнительно): Максимальная степень параллелизма = 1, Стоимостный порог для параллелизма = 50
3. Что там с сетевыми пакетами, если не менял, то измени (в свойствах сервера MSSQL вкладка Дополнительно): Размер сетевого пакета = 8192 (по любому сейчас 4096)
4. Что там с TEMPDB (тусования с диска на диск хорошо, но это не всё), нажми Создать запрос и копипасть:
4.1 ALT ER SERVER CONFIGURATION SET MEMORY_OPTIMIZED TEMPDB_METADATA = ON;
4.2
SEL ECT SERVERPROPERTY(‘IsTempdbMetadataMemoryOptimized’);
— set MIN_MEMORY_PERCENT and MAX_MEMORY_PERCENT to the same value
CREATE RESOURCE POOL Pool_TEMPDB
WITH
( MIN_MEMORY_PERCENT = 63,
MAX_MEMORY_PERCENT = 63 );
GO
ALTER RESOURCE GOVERNOR RECONFIGURE;
GO
4.3 ALT ER SERVER CONFIGURATION SET MEMORY_OPTIMIZED TEMPDB_METADATA = ON (RESOURCE_POOL = 'Pool_TEMPDB');
4.4 (тут проверка что tempdb привязался)
SELECT d.database_id, d.name, d.resource_pool_id
FR OM sys.databases d
GO
Рестарть сервер.
Проверяй ещё раз на попугаи на нагруженном сервере, радуйся, удачи.
В базу "Тест Гилева" тоже долго первый раз заходит?
Если да - то возможно проблема в стороне поиска лицензий, если нет - запустите Бухгалтерию или ЗУП в конфигураторе и в режиме отладки сделайте замер производительности при запуске и посмотрите что именно в коде долго происходит.
Гилев - толстый клиент. Проблема походу в тонком, поэтому не совсем понятно, как соотносится "работает все через веб-сервер" и запуск Гилева?
Автор, ты уж тогда четко и конкретно опиши, что запускаешь, как запускаешь (браузер, тонкий клиент через веб-сервер, тонкий клиент "через сеть", толстый клиент - он всегда "через сеть"). Ты ж готов кучу бабла отсыпать, а рассказать, что конкретно делаешь, ленишься.
Копай в сторону сетевого соединения между сервером 1С и SQL. Как прописан путь к СУБД в свойствах базы? Если в виде доменного имени, то вместо этого укажи прямой ip адрес, либо localhost, если сервер 1С и SQL стоят вместе.
(15) Еще что-то подсказывает, что неплохо бы проверить права пользователей, под которыми запускаются MS SQL сервер, 1С-сервер и веб-сервер на папки с базами, кешами и прочим, возможно, какие-то сетевые настройки. Возможно, переиспользование сеансов может дать некий результат. до окна логина долгий запуск - это поиск лицензий, а после, там всякое может быть.
(21) когда заходишь в базу все нормально функционирует ничего не тормозит. проблема в первом запуске в каком-то моменте.
Ощущения что он кэширует это чтобы потом быстро запускать.
А после ввода пароля долгий запуск может быть связан с начавшими выполняться разными фоновыми заданиями. В консоли администрирования сервера 1С их можно увидеть, а вот как их полностью победить - это вопрос.
На выходных проверю как себя будет вести если оставить 5-10 баз все остальные отключить от сервера 1с и посмотреть что будет.
1С Обновлятор очень долго делает операцию
22:13 Путь к базе: localhost
22:18 Подключение к кластеру 1с прошло успешно!
так что проверим может это из-за кол-ва баз
Также сделал еще один кластер и перенес в него пару баз посмотрим как завтра будут запускаться
(34)можете не отключать от сервера 1С, а просто пустить в оффлайн в скуле.
Сколько у вас там реально работающих баз, в которых живут пользователи и крутит рег задания?
Приветик, скорее ты это уже делал, но если нет попробуй. Поменяй dns в сетевых настройках если это возможно, как на пользователях так и на серваке.
Попробуй платформы старых версий
Размер базы какой? Может быть чем то засралась и раздулась, вследствие получились тормоза
Работа по web идет через браузер или через 1с?, попробуй поменять
Что за web сервер? с его настройками могло что то случится
Мда, советчики. Поменяй sql? поменяй платформу, поменяй сеть... Флаги трассировки, о боже! Все равно что "колеса пинал, фары протирал?"
Автор пишет четко: проблемы при первом входе, потом нормально. Значит это не проблема общей производительности / сети / дисков / настроек sql и т.п.
1) Автор, у вас ведь не виртуальная машина?
2) При первом входе в базу происходит чтение метаданных базы в оперативную память службы 1С (упрощенно). Похоже именно здесь проблема, на сервере приложений где служба 1С.
Для решения схожих проблем в 8.3.25 добавлен параметр "Задержка выгрузки конфигурации рабочим процессом без активных пользователей" в настройках ИБ. https://wonderland.v8.1c.ru/blog/razvitie-klastera-serverov-1s-predpriyatiya/?sphrase_id=732725 Попробуйте.
3) Решать проблему надо основываясь на каких-то данных, а не пальцем в небо.
3.1) Смотрим загрузку процессора на сервере в момент первого входа в базу - нет ли скачка до 90-100%.
3.2) Смотрим логи, в данном случае - технологический журнал. Начать можно с клиента, т.к. на нем будет меньше событий. Как уже писали, проверить работу лицензий (маловероятно, уже вроде проверили - но можно посмотреть объективно через ТЖ):
У чела нет проблем в производительностью сервера - вся проблема упирается в старт 1С, при том, как я понял, после первого старта все быстро.
Отсюда вопросы:
1. Как стартуем (браузер, тонкий через веб, тонкий через сеть, толстый - всегда через сеть)?
2. При всех ли вариантах старта так долго?
3. На самом сервере всегда быстро? Тема нифига не раскрыта, в каком конкретно месте при каком запуске и у кого тормозит.
4. Если на самом сервере медленно, то запусти конфигуратор, запусти отладку и жамкни замер производительности, после чего посмотри, на чем конкретно тормозит. Ну и посмотри, когда кнопка появляется замера - на сколько до нее долго.
5. Если до кнопки замера долго, то я бы смотрел в сторону поиска лицензий. Запусти с полным технологическим журналом, посмотри, какие там события при запуске - поймешь, на чем висит.
6. Вариантов много - проще кому-то может быть заплатить за это, раз так мало подробностей в описании проблемы родить смог.
1 - как долго запускается файловая база на сервере
2 - электропитание - стоит ли высокая производительность
3 - пробовал и 23 и 24 - сейчас ушел на 22 - проблем стало меньше
Добрый день ВСЕМ!!!!!!
Выходные прошли не зря.
Если на сервер оставить 10 баз из 50 все летает (запускается все отлично. обновляется быстро).
При 10 базах нагрузка на процессор до 20%. когда добавил остальные базы до 25-30%. сейчас рабочий день загрузка в среднем 30-40 при 46 подключениях всего пользователей и фоновых до 10 шт.
Нагрузки на диски и на память нет и на процессор нет больших. на сервер никто на выходных не работал.
запускал базы хаотично одна могла загрузится быстро вторая нет.
Заметил что проблема еще до в вывода пользователя и пароля. базу запустил, а подключений в консоли сервера по этой базе я не вижу.
тут писали про лицензии что может к ним долго обращается. победить теме ответами что были не получилось.
Лицензии у меня физические USB. на выходных не было программных под рукой. сегодня завел программные на сервер и на пользователей.
и проблема не ушла также долго ищет подключение к серверу. лицензии получает программные физические отключил.
Вот наш путь к логину и паролю
Клиентское приложение устанавливает сетевое соединение с сервером 1С. Это включает в себя определение доступности сервера по указанному адресу и порту.
Отправка запроса на подключение к информационной базе
После установления сетевого соединения, клиент отправляет запрос на сервер с указанием целевой информационной базы. Этот запрос содержит информацию о том, к какой именно базе пользователь желает получить доступ, а также версию клиентского приложения и другие технические данные, необходимые для установления сессии.
Предварительная проверка на сервере
Сервер 1С обрабатывает запрос от клиента, проверяя возможность подключения к указанной информационной базе. Это включает в себя проверку существования базы, доступность её для подключений, а также проверку лицензий и текущей нагрузки на сервер.
Инициализация сессии
Что исключил так это лицензии поменял с аппаратных на программных изменений нет. как проверить остальное не знаю.
После ввода логина и пароля нет проблем запускается нормально не быстро и не медленно. Работает тоже хорошо никто не жалуется. мне нравится как работает т.к. сам работаю с тремя базами с этого сервера. Проблема теперь ясна это долгий запуск до логина и пароля.
(42) Технологический журнал я так понял можно не ждать. Ну тогда дальше протирайте фары и пинайте по колесам: поменять планки памяти, поменять сетевые адаптеры, поменять диски, прописать имя базы капслоком, прописать все возможные флаги sql и т.п.
(43)
Технологический журнал включил не знаю что отправить в логах вот такая ошибка сейчас такая ошибка смотрю
20:37.081005-0,EXCP,0,process=rphost,OSThread=4056,Exception=d294e384-7ea6-49c6-be96-f3a6e3de1242,Descr='LoadComponent(liccspr):
d294e384-7ea6-49c6-be96-f3a6e3de1242: Ошибка загрузки компоненты liccspr: 126(0x0000007E): Не найден указанный модуль. '
(45)
Журнал выкладываю взял вторую настройку запускал базу
Srvr="Srv-1";Ref="At-Group_Buh100901";
Пытался понять что-то в нем. для меня пока это просто символы.
(49) Я писал что нужен клиентский лог. А Вы собрали серверный.
Файл logcfg надо разместить на том компьютере, где запускаете клиента.
Скрытый текст
И всё таки у вас виртуальная машина. И хотя прямых доказательств что причина в настройках Вм нет, рекомендую ознакомиться с http://www.gilev.ru/virtual/ разделом "Лучшие практики"
(45) Еще один лог он меньше чем предыдущий
запускал эту базу долго. после запуска нажал вход он выдал ошибку неправильный пароль и вырубил запись логов Srvr="SRV-2";Ref="OtkrIngin_Buh226490";
Srvr="Srv-2";Ref="DgkGroup_Buh264356"; эта в этот момент запустилась быстро и тоже нажал вход чтобы он выдал ошибку неправильный пароль
(57) В логе много сеансов и баз. Искать сложно. Надо чтобы в логе была только проблемная ситуация.
Разместите logcfg в каталоге своего пользователя C:\Users\username\AppData\Local\1C\1cv8\conf
Замените в logcfg путь на новый (чтобы не писал лог туда же где уже много старых файлов).
Запустите сеанс. Если тормоза воспроизвелись - удалите logcfg, чтобы лишние события больше не писались в лог.
Если запустился быстро - завершите сеанс, очистите каталог с логом и пробуйте другую базу.
(65)
(65)
запускал эту базу долго. после запуска нажал вход он выдал ошибку неправильный пароль и вырубил запись логов Srvr="SRV-2";Ref="OtkrIngin_Buh226490";
Srvr="Srv-2";Ref="DgkGroup_Buh264356"; эта в этот момент запустилась быстро и тоже нажал вход чтобы он выдал ошибку неправильный пароль
1. Сама 1С говорит, что это не баг, а фича - просто сообщение в ТЖ.
2. Вот с одной темы:
Нашел эту статью, потому что решал проблему тупой работы 1С. В моем случае служба лицензирования вынесена на отдельный сервер. В консоли кластера в процессах сервера лицензирования был неактивный процесс. Перезагрузил на сервере лицензирования службу лицензирования, все стало работать хорошо.
(50) Да хоть в конфигуратор хоть режим предприятия. в одну базу заходит быстро в другую нет. потом что быстро заходил опять может заходить долго. тут же проблема до логина и пароля потом все работает отлично
(55) Аутентификация средствами 1с или другие варианты (Операционной системы, OpenID, токенами)? Если не средствами 1с то может проблема в источнике получения списка пользователей - первый раз долго его соответствующий сервис отдает
У меня тоже запуск первой базы долго происходит, затем остальные быстро запускаются. Платформа 8.3.23.2040. При первом запуске сильно грузит ресурсы сервер 1С. Как будто сервер грузить конфигурацию в кэш для дальнейшего использования. Если учитывать что в базе всегда кто-то есть, то приняли для себя что ничего страшного.
(56) Вроде пароль тоже долго запрашивает. Сейчас уже не охота экспериментировать, всех выгонять надо. У вас долго только при первом запуске первого сеанса?
2. tempdb.mdf и templog.ldf тоже перемещал по NMM-e
установи платформу на NVME
1c если серверная очень плотно работает со своей системной папкой
посмотри где работает серверный кеш
постарайся чтоб он крутился на NVME диске
Гилева показывает 30-33
по моему это очень мало, для более менее нормальной работы надо от 50ти
перенеси SWAP на ССД
проверь на скорость свой диск C SAS если меньше 1000 то выкини его и поставь NVME на 3000 -5000 мб/с
(56)
чтоб исключить факт опроса лицух попробуй то, сам догадайся что, но на тестовой базе, а то поставят тебе там будильничек.
лицухи уже программные установлены ошибка не ушла
Гилев 30-33 это отличный результат для SQL в гипервизоре Hiper-V. Если без него то 45. Файловую не рассматривая из-за администрирования баз.
SSD 1600
Еще по лицензиям если бы все базы долго запускались а то хаотично происходит база запустилась долго, а потом быстро. а может и не быстро.
и как понять что это лицензия????
очередь к диску не вырастает во время ожидания окна ввода пароля?
если это не сетевой затуп с ожиданием отклика от несуществующего сетевого ресурса на который где то осталась ссылка, то такие сильные тормоза почти наверняка от дисковой системы.
(74) выше приложены скрины скорости работы дисков.
загрузки нет. никто не работает с сервером отключены фоновые задания. и все равно одна база запустится быстро до логина и пароля, вторая нет.
nomad_irk в логах увидел обращение по сети и ответ по 10 секунд и он не один. и это не запуск по сети, а локальный.
вот кто умеет читать логи и понимает их. и понимает как их исправить в другом направлении.
Не знаю как тут можно давать советы, если автор не до конца описал схему работы, например, как вообще клиенты подключаются к серверу в датацентре: по rdp или vpn поднят. Вот starik-2005 правильные вопросы задает на которые нет ответа. Вообще проблема с помощью на форуме связана, мягко говоря, с неполным описанием исходных данных. Когда появилась проблема? Что менялось перед ее появлением? Был ли поднят второй сервер с такими же настройками для теста?
ых. Когда появилась проблема? Что менялось перед ее появлением? Был ли поднят второй сервер с такими же настройками для теста?
Подключаются через WEB. Проблема подключения и на web и тонкий клиент и толстый.
Дмитрий74Чел вот только этот человек правильно сказал надо смотреть логи т.к. все остальное это гадание на кофейной гущи. до логов пока сам не дошел как что их расшифровывать.
Проблема описана когда добавили еще баз на сервер. а чем по вашему поможет второй сервер в решении проблем на этом сервере?
На другом сервере работает запуск нормально хотя все программы стоят один в один в релиз. разница что там был поднять еще и RDP сервер, тут его нет т.к. работать по рдп тут не будут. Самое главное что и тут запуск работает нормально но через раз как и было описано. и тот сервер по характеристикам чуть хуже. но там 1с стояла 2 года и платформа обновлялась тут только одна платформа и стояла и релизы только подымались для эксперимента. т.к. опустить базы не запустятся.
(77) Логи выложил и пока один только написал что идет опрос долгий по сети
Никто не написал с чем может быть связано. Могу и логи еще выложить и доступ дать если надо. и ответить на все могу.
(80)
Из консоли администрирования баз тоже идет долгое обращение к базам этот как еще объяснить?
выбираешь базу свойства и все зависает от 1 минут и более. приблизительно как при запуске до логина и пароля.
Что еще заметил. Если база открыта то при повторном запуске быстро логин и пароль, если все соединения отсутствуют то долго.
Логи могу еще сделать по вашему запросу.
(81) Ну если вы читали темы по ссылкам выше и скачали бы ProcessMonitor и поигрались с ним, то станет понятно, что процессы, которые происходят как при старте базе из списка так и при попытке открыть свойства из консоли - один и те же. 1С читает свои файлы из папки program files и создает временные файлы в директории где находится учетная запись USR1CV8 и уже только после завершения этого "начального запуска" (который длится у вас долго) обращается к списку баз. Проблема либо физическая, например память или диск, либо программная, например права учетной записи.
Попробуйте в свойствах службы "Агент сервера 1С:Предприятия 8.3 (x86-64)" на вкладке "Вход в систему" установить "Вход в систему: с системной учетной записью" и перезагрузите сервер. Если нет, придется делать замеры по времени процессов при старте 1с и тестировать железо. И не плохо бы посмотреть, при долгом старте 1с, нет ли очереди к диску в "мониторе ресурсов".
Всех приветствую! На днях получил "новый" сервер и сразу туда перекинул копию того что у нас плохо работает в надежде что может быть железо. Но нет все также работает. но тут можно делать что хочешь и когда хочешь он же не боевой. Поставили Server 2016.
Что удалось выяснить медленная скорость запуска только при работе скульных баз.
У меня сейчас два сервера HP 8.3.23.1865 и Dell 8.3.22.2283 одного поколения процессоров V4
Почему так решил.
1. Файловые базы грузятся отлично (до логина с паролем, наша проблема). на двух серверах. на Delle быстрее, но там и платформа 8.3.22.2283
2. Скульные базы на Деле платформе 8.3.22.2283 до 15 секунд в среднем 10 секунд. после установки 8.3.23.1865 начинает работать как HP. начинает грузится от 30 секунд и больше.
3. Если кто помнить на HP сейчас стоят программные ключи, а проблема не ушла. (также ломал 1с для эксперимента не помогло)
8.3.23.2137 8_3_24_1368 8_3_25_1072 везде по логам наблюдается что описал первым nomad_irk 68 07.03.24 10:50
Может кто знает что в логах этот означает и как с этим бороться?
Да можно пока побыть на платформе 8.3.22 но потом все равно переходить 8.3.23 и т.д.
"мониторе ресурсов" продолжим на следующей недели будем добивать вопрос уже из любопытства, пользователи сейчас нормально работают. Везде поднимается вопрос, но до конца не решается.
Что удалось выяснить медленная скорость запуска только при работе скульных баз.
Главное отличие - файловые базы не используют Сервер 1С. Поэтому - читаем дальше.
Может кто знает что в логах этот означает и как с этим бороться?
Если внимательно посмотреть на лог, то можно заметить отличие: в быстром варианте идет обращение к порту 1541, а в медленном - 1569.
Может, тут-то собака и порылась? Тупо в брандмауэре закрыт порт 1569, хотя сказано:
Сервер 1С работает на порте TCP 1541 и диапазоне портов 1560-1591. И опять же, для уверенности и надежности лучше в новое правило добавьте диапазон портов 1540-1591.
(85) Прошу прощение не заметил ваше сообщение. Фаервол отключен полностью, чтобы избегать неприятностей. Если все работает отлично потом приступает к его настройке.
Создавал новые кластера не помогало.
За порт спасибо не обратил внимание если честно.
Просто если запускается быстро нет вообще в логах таких строк
как эта "11:40.637000-0,CONN,0,process=1cv8c,OSThread=3500,Txt='Ping direction statistics: address=192.168.100.103:1567,pingTimeout=15000,pingPeriod=3000,period=10078,packetsSent=3,avgResponseTime=0,maxResponseTime=0,packetsTimedOut=0,packetsLost=0,packetsLostAndFound=0'"
(86) На линуксе поставили летом в июле 23 года платформу 23 тормозить стало все запуск работа сохранение обновление баз. в сентябре поставили более свежую платформу 23 не помогло перешли на 22 все сразу заработало залетало.
тут немного другое, что если есть первый вход даже через консоль кластеров. Потом все работает отлично. тут и не заметишь если у тебя несколько баз(5) и много пользователей (50), а у меня наоборот. несколько пользователей (10) и много баз (50).
(84)
Добавил таблицу сравнения лога при запуске баз.
Разница в этих строках там где долго они присутствуют и чем дольше запускается тем их больше
11:40.637000-0,CONN,0,process=1cv8c,OSThread=3500,Txt='Ping direction statistics: address=192.168.100.103:1567,pingTimeout=15000,pingPeriod=3000,period=10078,packetsSent=3,avgResponseTime=0,maxResponseTime=0,packetsTimedOut=0,packetsLost=0,packetsLostAndFound=0'
все остальное одинаковое насколько это может быть
(84) пока что явно эта проблема решена немного "в обход" в 1С -- будем хранить в сеансе закэшированное подольше, да и всё. И всё будет летать при входе. А чем именно заняты клиент и сервер при "долгом" заходе мы так и не можем понять и не узнаем -- мне вообще неясно как можно так неоптимально что-то делать, чтобы по 2-3 минуты загружать что-то (ну посудите сами, база размером ВСЕГО в 3-4 Гб за это время у нас по 10Гбит сети + NVMe Optatne + Xeon Gold и вот это всё -- она бы успела трижды скопироваться из SQL в сервер приложений, разархивироваться и пересчитаться))))
В одном случае к серверу по имени обращаетесь, в другом по айпи. Ссылку не найду, но по имени обращение предпочтительнее и быстрее работает. Но компьютеры в одной сети должны быть. Что у Вас находится по адресу 192.168.100.103? Может быть роутер, маршрутизатор, что-то еще рубит подключение, или переадресация какая-нибудь там настроена. В брандмаэуре защитника виндоус можно попробовать порт 1567 открыть.
а может быть попробовать сервер 1с перенести на другой диапазон портов ? для эксперимента. По логам как будто периодически недоступен сервер. Если это глюк платформы, возможно на другом диапазоне он не будет проявляться ?
(92) Если вы имеете ввиду создать новый кластер с новым портом, то не помогло.
если не доступен то в чем причина. если взять базу запустить ее до логина и пароля она откроется за 2 минут. оставляем базу в таком состоянии что только открыто ввод пароля и запускаем ее еще раз и ввод логина и пароля открывается 1-3 секунды. т.е. даже не нужно запускать базу.
что отвечает что он начинает искать сервер или почему он не доступен какой-то момент?
На правах эксперимента. Находим базу, в которой сейчас никого нет заходим, все повисло, смотрим в MS SSMS с помощью sp_who2 или запроса посерьезнее, а выполняется ли какой-нибудь запрос к этой базе, что в этом запросе.
Еще можно посмотреть, как база MS SQL добавлена в сервер 1С (параметры инф базы к консоле администрирования сервера 1с): под sa или другим пользователем, нормально ли у него с правами; СУБД по имени или айпи указан. не факт, что поможет, но как еще 1 вариант куда копнуть. В журнале MS SQL ничего интересного не пишет?
Прежде всего -- самое важное -- у нас ровно, абсолютно, до мелочей то же самое. Не буду грузить ни вас ни окружающих деталями. У нас, как и у вас, нет проблем с производительностью.
Проблема локализуется примерно так:
1. Вход в любую базу (если в ней никого нет) -- долго ждём окно логина, потом тоже довольно душно грузится. минуты.
2. После этого словно что-то магически закэшировалось и вуаля -- загрузка базы 3-5 сек.
3. Это счастье длится полчаса, можно заходить в базу и выходить, всё летает.
4. Если ХОТЯ БЫ один пользователь в базе висит (не фоновое задание), то "быстрое" состояние не теряется никогда, всё летает, все заходят мгновенно.
5. После получаса не-использования база грустно куда-то "осыпается", ну то есть снова приходим к п.1
Мы сами очень хорошо знаем все оптимизации и по ключам и по сети и по скулю -- так вот это точно Не поиск лицензий, Не про ipv6, Не про кэш на NVMe. Ключевое здесь то, что как бы медленно и ужасно ни заходило -- работает потом идеально и нагрузки ни на сервере приложений ни в скуле в момент захода нет воообще. Никакой.
И важно то, что именно при актуальном одном хотя бы пользователе в базе всё продолжает работать на ура.
У нас сейчас 8.3.23.1865
Чуется мне, что проблема именно в платформе(версии) ибо раньше так не было, на более старых версиях проблемы этой нет. Доступная стабильная 8.3.24.1467 - будем пробовать.