УТ 10.3 . Периодические тормоза. #765719

Добрый день. Имеется вот такой зверь. Windows Server 2008R2 ОЗУ : 64 Гб. Xeon E5. 2.4 Ггц x 6. Дисковая система. MS SQL 2012. Под него выделено 40 Гб ОЗУ. Протокол связи с сервером 1C - Shared Memory. Раздел C: 2 SATA диска. RAID 1. 1TB Временное хранение бекапов, исполняемые файлы. Раздел E: 2 SSD Intel . RAID 1. 120 Гб Логи SQL баз + tempdb. Раздел F: 4 SAS. RAID 10. 600 Гб. Хранятся файлы БД. На сервере установлен сервер 1С+SQL+Терминалы+WTWare. Большая часть клиентов грузяться с тонких клиентов по RDP. Подключаются под одной учетной записью и каждый дальше уже в самой 1С проходит аутентификацию. Работает порядка 20-25 человек. Основная работа ведется УТ 10.3. Объем базы 26 Гб. Так же имеется БП 3.0 . В ней работают 2 человека. Объем базы 30 Гб. Суть проблемы : время от времени начинают подвисать платформа при работе с формами. Например при открытии/закрытии РТУ и тд.Может занимать 3-6 секунд. Пробовал чистить кэш пользователя, переставил платформу/сервер до версии 8.3.6.2449 - безрезультатно. Свободной оперативной памяти достаточно, процессор не загружен. Дисковой активности не заметил. Вот и возникло несколько вопросов. С чем могут быть связаны такие вот тормоза ? В момент их появления ничего на сервере не менялось и не устанавливалось.

Вчера лично стал свидетелем такого поведения. Подключился к серверу, при попытке открыть документ РТУ наблюдалось провисание на 3-4 секунды, так же они закрывались. Закрыл/открыл новый сенас, под тем же пользователем - работало как нужно.  Ночью запустил реструктуризацию и пересчет итогов. Результат тот же.

Подведу итог. Что может влиять на скорость открытия/закрытия  в 1С ?

в режиме отладки? или в любом режиме?

Сеть какая? Файловая или  Серверная?

А. Вижу,  Серверная

пользователи запускают 1С ку в режиме предприятия. Могут 15 работать нормально, у двоих временное такие фризы. Потом фризы могут начаться у других. Понять в чем беда не могу.  Сегодня хочу для половины сотрудников завести отдельных пользователей для подключения по RDP, чтоб у каждого была своя папка со своим кешем и зодно обновлю 1С ку до версии 8.3.7.1917 .

попробуй также 8.3.8

Выноси пользователей на локальные тонкие клиенты.

смешно:) в операторском зале стоит 1гб коммутатор. Часть клиентов подключены к нему напрямую . Другая часть через мыльницы. Увы досталось в хозяйство в таком виде и успешно работало год.

на полном серьёзе - поиск летает там

Не совсем понял, можно чуть развернуть совет ?

не имею желания тестовую версию ставить на работающий (хоть и с непонятными фризами) сервер :)

[Понять в чем беда не могу.] а ты и не пробывал нет ни счетчиков ни замера в 1С нет даже тех.журнала

у 1С есть чек-лист по тормозам:

спасибо, настрою счетчики и посмотрю . Везде где натыкаюсь на информацию о замере производительности по счетчикам, натыкаюсь на английские названия. Буду сейчас добавлять и замерять.

[Везде где натыкаюсь на информацию о замере производительности по счетчикам, натыкаюсь на английские названия] и чё ?

все хороршо, перевожу и добавляю)

Про режим энергопотребления уже было ? Выставлено в "максимальная производительность" ?

выставлено в максимальную изначально. Сегодня не успеваю уже, попробую завтра днем снять счетчики и с конкретными цифрами вернусь сюда.

может программера допросить с паяльником? Наверняка он каких нибудь тупых запросов понавставлял.

Стесняюсь спросить, регламенты работают на sql?

Настраивал, согласно тех же рекомендаций в сети.   Нигде на накосячил ? тоже не исключал вариант, так как недавно сторонний программист вносил свои коррективы в работу конфигурации. Несколько раз сам оптимизировал код, в итоге отключил процедуру, которая могла в теории влиять на  производительность сервера. Проблема проявляется следующим образом. Пользователь работает и все нормально. Потом внезапно начинают долго открываться/закрываться документы. Решается или простым ожиданием или же закрыть/открыть сессию заново.

Регламентные задания какие крутятся в базе?

Вот скриншот . Вроде полнотекстовый поиск отключали через Предприятие. Операции - Управление полнотекстовым поиском - Настройка - Разрешить полнотекстовый поиск.   А тут его обновление стартует каждые пять минут.

Даже меньше, каждые 2,5 минуты.

Попробуй на время отключить все активные задания и смотри что будет. Если все ок, то постепенно стартуй по одному, так и найдешь виновника.

спасибо, обновлять платформу+сервер это блажь ? Не нужно ?

Обновлять можно конечно, только всегда есть шанс, что после обновления станет еще хуже)

тогда оставлю это на потом :) Отрубил регламентное задание по обновлению полнотекстового индекса. Завтра посмотрим. Вопрос в догонку по обновлению. Назад переехать на 8.3.6 можно с 8.3.7 ? Нет ли подводных камней ?

Хочу замерить производительность дисковой системы. Кто подскажет,показатели каких счетчиков считаются приемлемыми при работе MS SQL ?

не надо переезжать обратно

Может обмен с сайтом в фоновых висит

понял, спасибо. смотрю в консоли заданий - все пусто. Запустил все счетчики по дисковой системе. Смотрю. Из аномального - кратковременные скачки длинны очереди диска. Запущу  сборщик данных, проверю. Buffer cache hit ratio почти всегда 98-100. Оперативной памяти SQL хватает. Процессор в пике 12-14 процентов. С утра было несколько замечаний и пока тишина. Ждем.

Из настроек сервера. Количество ИБ на рабочий процесс - 8 Количество соединений  на процесс - 8. Настройки кластера : Допустимый объем памяти - 1500000 КБ Интервал допустимого объема памяти - 600 сек

Вот сейчас поймал момент. Долгое открывание документов.По счетчикам , указанным на ИТС все отлично, а пользователи ноют. Снял замер производительности у пользователя. Вот ссылка. МОжет кто нибудь глянуть ? Склоняюсь к мысли апдейта ночью платформы и сервера. Если не спасет, но перетряхнуть весь сервер. Понимаю что не самое элегантное решение, но руки опускаются.

Почему время выполненного задания 20.02.2016? Сегодня только еще 19.02.2016

на сервере стоит +1 день.

это хуже, чем плохо, это катастрофа

Можно подробнее ?

Дополнительная информация о дисковой системе. C: RAID 1 . Страйп - 256 кб . Размер кластера - 4096 байт E: RAID 1 . Страйп - 64 кб. Размер кластера - 64 кб. F: RAID 10. Страйп - 32 кб. Размер кластера - 64 кб. Вот такая солянка.

Да по описанию все норм.. проблема же может быть в конкретном диске. Хотя не похоже - если бы что то с дисками было, то тормоза явно бы чаще проявлялись. P.s. Регламентые задания все поотключали?

Смущает разница страйпа и размера кластера просто. да, через консоль заданий отрубил обновление полнотекстового индекса. Остальное в течении дня не запускалось. Ночью ставлю 8.3.7 актуальный релиз. Если не спасет , буду перетрухивать сервер. Недельная головоломка выбила из колеи меня :(

Обновление до 8.3.7 не спасло. Еще больше смутило что вчера не было тормозов, сегодня снова жалобы. Снял ряд показаний с счетчиков.В момент сбора данных люди сталкивались с фризами.    Из того что бросилось в глаза, это скачки по очереди диска F: это раздел с данными БД. RAID 10 (4*SAS). Размер сектора 64 кб, размер страйпа 32 кб. Смущает это разница между страйпом и размером сектора. Не может ли это влиять ?

Предполагаю что проблема не носит характера 1С. Перезапуск RDP сеанса кратковременно позволяет работать без фризов. Пора заканчивать эту историю, в выходные переставлю сервер целиком, заодно настрою массивы под SQL c размером страйпа в 64 кб.

настрой технологический журнал 1с на операции больше 5 секунд. проанализируй. если будет пусто, то 2 секунды и т.п.

Подсмотрел в желтой книге образец, не затруднит глянуть ? Прошу прощения что общим текстом, не понял какой тег позволяет выделить код в сообщении. P.S. День когда я решу это проблем я отмечу салютом ! <config xmlns="; <log history="7" location="c:logs">

у меня так для отлова всего, что больше 0.1 секунды. соответственно, duration надо увеличить пропорционально:

для настройки и просмотра пользуюсь

Вот в таком виде выдает пустые файлы. Я так понимаю что при наличии тормозов и пустых файлов журнала по таким параметрам означает что SQL работает корректно ?

ПО лиценщионное? Я про WinSRV SQL

Антивир в реальном времени, поиск рутктов?

Стоп-стоп-стоп.То есть у тебя на одном сервере MS SQL и сервер 1С и терминальный сервер?

стоит с легальным ключем. антивирус не ставил на сервер, есть рекомендации - Касперский ? Да, на текущий момент именно так.А так же еще программа WTWare, которая выдает по DHCP IP тонким клиентам и они по сети загружают в ОЗУ программу, которая подключается по RDP. Всего пользователей порядка 30.

Создают документ РТУ. Фриз. Открывают подбор, начинают бегать по справочнику номенклатура - все отлично, моментально добавляется и тд. Стоит или закрыть документ или начать его проводить. Фриз. Пробовал пересоздание и перерегистрацию базы. Реиндаксацию средствами и 1С и средствами SQL - результат тот же. Как говорится и фары протер и по колесу постучал, а машина не едет.

Нужно поставить туда еще контроллер домена и АТС. Тогда все полетит.

спасибо за совет, обдумаю.

при таких настройках в базе либо не должно быть фризов либо настройка лежит не в том месте (не на сервере)

То есть 64 гб оперативки  - из них 40 сиквелу, а все оставшиеся 24 серверу 1С и 27  пользователям? И оперативки хватает? Как так?

эм, никогда ранее не работал с этим механизмом. Поправьте если заблуждаюсь. Я должен файл настроек тех журнала положить C:Program Files1cv8conf  ? т.е. в папку conf сервера, не в папку conf платформы ? ну вот сейчас в мониторе вижу : Доступно 65430, Кэшировано 7119, доступно 18314, свободно 11281. В среднем 1Сv8.exe отжирает 100-200 мб на пользователя. Тормоза наблюдались даже после ребута (спустя какое-то время), когда SQL не успевал заполнить весь объем отведенный ему ОЗУ. Проверил средствами контроллера диски - жалоб нет. На ночь хочу запустить memTest, может планка какая у меня шалить начала, а я тут всем мозг выношу. Большое спасибо за участие и советы !

по дефолту в C:Program Files1cv8conflogcfg.xml

для толстого клиента на сервере терминалов тоже неплохо бы настроить, там по дефолту в C:Program Files (x86)1cv8conflogcfg.xml

ну и да - очиститьнастройкипользователя

На сервере стоит Windows 2008 R2 Enterprise. Сейчас разместил в два каталога файл по образцу из ЖКК. Пока тишина, в папке пусто. Пробовал запускать 1С с /ClearCache , пробовал создавать им новых отдельных пользователей, для того чтоб не было чужого кэша в профилях, пробовал чистить папку с кэшем руками.

понял что про внутренние настройки, качаю обработку, попробую очистить настройки рядовым сотрудникам.

почистил настройки одному человеку, все тож самое. пол часа работала и начались фрзиы. Нужно на ночь ставить тест ОЗУ думаю.

Это только в одной базе так? В других базах пользователи работают?

А точно сама 1С подвисает? Может терминальные клиенты в смысле сетка в целом?

на сервере две базы, торговля и бухгалтерия. В бухгалтерии работают максимум два человека и то временами. На нее жалоб и не поступало, так как интенсивность ее использования низкая. Так же беда в том, что глюк, который я ловлю, проявляется не у всех сразу. Вот работает вечером 15 операторов, 3-4 жалуются, у других все хорошо. Потом у этих хорошо, другие жалуются. Перезаход в RDP спасает временно. Так же могут работать 3-5 человека и будут ловить поочердено фризы или несколько сразу. На сетку думал, слал пинги разного размера от сервера к терминалу и обратно - все ровно. Сегодня протестировал через Adptec'овскую RAID утилиту целостность массива с данным - все ровно. Проверил диски - все ровно. Перед переездом на этот сервер (пол года назад) гонял тест ОЗУ, проблем не было. Да вот хрен его. Фризит платформу в момент открытия/закрытия любой формы. Создал ты новую РТУ или открываешь ранее созданную - значения не имеет. Так же в момент закрытия. Не важно , проводишь ли ты документ или же закрываешь без сохранения - ловишь фриз.

это фейк. проблемы в rdp были, но не на уровне "поставьте 8800GT" и точно не "Оказывается, странно написанная жёлтая фигня не умела корректно работать с четырёхголовыми мутантами — использовала-то все четыре ядрышка, но почему-то только на 15% мощности. Увидев же могучую 8800 с заветной CUDA, 1С набросилась на неё со всем остервенением."

это не фейк, походу терминал был неправильный (не RDP) и дикие разрешения экранов клиентов в результате затык был на "рисовании графики" на 1 терминальном сервере для около 20 машин логично что воткнув нормальную видеокарту со своей шустрой памятью графика начала на ней рисоваться разгрузив проц (встроенная видяха)

Если фризы есть как в толстом клиенте на локальных ПК пользователей, так и в терминале, то дело скорее всего в канале между клиентом и сервером приложений, либо между сервером приложений и сервером БД. Перенеси базу и лог на общий диск (и отключи шаред мемори) и проверь. И покажи настройку перезапуска РП и памяти в кластере и рабочем сервере.

вопрос вроде решился координально в эти выходные. Перетряхнул к черту весь сервер, заодно переконфигурировал дисковую систему. На массивах под SQL логи и бд выровнял страйп, это положительно сказалось на производительность согласно теста Гилева,максимальная скорость многопоточной записи заметно выросла. Дальше буду наблюдать. Параметры кластера. Допустимый объем памяти - 1572864 KB Интервал превышения допустимого объема памяти - 600 сек Настройки сервера. Количество ИБ на процесс - 8 Количество соединений на процесс - 8

А однопоточный тест тоже заметно увеличился, или так же? Кстати, сколько? Виртуальные машины убрал?

однопоточный незначительно увеличился до  35 до 38. Рекомендованное количество пользователей выросло с 28 до 90. Виртуальных машин и не было на сервере. В момент конфигурирования РАИД массивов установил размер страйпа 64 кб. После установки операционки и установки родной утилиты по управление контроллером увидел, что для одного массива почему-то размер страйпа был выставлен 32 кб, пересоздал его. Надеюсь это точка в моей истории.

Извини, невнимательно посмотрел, обычно если тема про тормоза/виснет и т.д., то как правило стоит ВМ(или несколько), от которых отказаться никак нельзя "по принципиальный соображениям". 38 - это хорошо.

Да ничего страшного. Было вчера несколько жалоб, но не массового характера. Думаю что по причине стандартных настроек, сегодня утром настроил ограничение по памяти и сеансам, как указал выше. Посмотрим. Спасибо большое всем участниками темы.

Сегодня пожаловались трое, симптомы те же. Из общего обнаружил, что все трое получали не программную лицензию, а с сетевого ключа. Вопрос. Платофрма, которая получает лицензию через HASP "нюхает" его только в момент запуска или в ходе работы проверяет его доступность ? Может ли платформа "фризить" в ожидании такого ответа ?

Периодически проверяет. Также попробуй совет номер 9 отсюда:

снес антивирус со своей машины (на ней стоит HASP LM), указал на сервере жестко его IP, отключил BROADCAST.  Если дело окажется в ключах, это будет хохма.

У меня при потере ключа вообще в полный даун впадала. Ключ был сетевой аппаратный.

Подключил анализ технического журнала. Большинство ругани было на это (409 записей) 47:21.417004-0,EXCP,0,process=rphost,Exception=0874860b-2b41-45e1-bc2b-6e186eb37771,Descr='srcLicenseBaseImpl.cpp(4433):0874860b-2b41-45e1-bc2b-6e186eb37771: Ошибка программного лицензирования. Error=10004(0x00002714): Операция блокирования прервана вызовом WSACancelBlockingCall. File=srcLicenseBaseImpl.cpp(4374)' и на это (122 раза) 07:26.801091-0,EXCP,2,process=rphost,p:processName=torg,t:clientID=2584,t:applicationName=1CV8,t:computerName=base-serv2,t:connectID=4610,Exception=dd149677-3d47-4e05-a55f-4e75b13a441f,Descr='srcRHostImpl.cpp(2737):dd149677-3d47-4e05-a55f-4e75b13a441f: Требуется переустановка соединения'

Может кому будет интересно. Дело было в ключах.

Что с аппаратными ключами сделал?

Да банально перенес на соседний сервер, где не стоял чудесный доктор веб. На терминальном сервере указал куда нужно смотреть в поисках сетевых ключей и все "тормоза" ушли.