Windows server 2016 терминальный сервер тормозит
Обновлено: 06.07.2024
Перешёл на Windows Server 2016 и заметил такую вещь: иногда случаются тормоза 7.7.027 (файловой). Как выражается? Просто медленно начинают экранные формы отрисовываться и перемещение по строкам и реквизитам документа становится невыносимо медленным. После выхода из 1С и повторного входа опять всё летает. В какой момент случается "тормоз" так и не понял.
Думал проблема из за работающей службы Dynamic Fair Share Scheduling (DFSS), которая в стандартном варианте всегда работает на Win2016, отключил. Но проблема всёравно иногда появляется.
(1) Не поверите, но количество 7.7 файловых (пусть и 2020 год) ещё очень великоПричём многие используют их параллельно с 8.3 :D
Выключил вот таким образом:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Quota System
EnableCpuQuota=0
Может ещё где надо? Спасибо!
Сегодня видны опять тормоза
Сегодня целый день работаю на сервере. Один, как Администратор. Других пользователей нет. Все ок, все летает, потом ни с того, ни с сего начинают очень медленно прорисовывается формы документов с табличной частью. Тормоза при этом страшные. Стоит выйти из программы и зайти, сразу все ок. Какие может у кого будут идеи?
Ну из того что выдал Интернет, если DFSS и квоты исключены, то проблема может быть в мощной видеокарте. В идеале - встроенное видео и драйвера от типового видеоадаптера Microsoft.
Подумываю о переезде на новый сервак, так что тема интересна. Держи в курсе.
(8) да кстати очень похоже. сервак считает что нагрузка ноль, и нечего зря жрать ресурсы снижает частоты в 10 раз и ему норм и электричество экономится.
Очень давно такой глюк был. Удалил cfg файлы в папках пользователей и все прошло.
(14) Тут другое судя по всему. Твой случай - это медленная прорисовка ОСВ в бухии или других отчетов и форм, где используется ВосстановитьЗначение(). Там у любителей нажимать кнопку "Сохранить список отчетов" в "Регламентированной отчетности" файл cfg раздувается до мегабайтов, а вкупе с антивирусом обращение к нему занимает несколько секунд, подтормаживает прорисовка. Выглядит как будто появляется форма окна, потом замирает серой и пустой на несколько секунд, а потом появляется целиком отрисованная.
Хотя. Ждем что скажет ТС.
есть обработки, которыми можно посмотреть эти кфг и повычеркивать ненеужное
(16) Во всех бухгалтерских конфах убираю из Отчеты.РегламентированнаяОтчетность возможность сохранять список отчетов - и живу-не тужу, за cfg не слежу.
(8) Попробовал изменить схему электропитания на "Высокая производительность", субъективно вроде стало лучше. Вроде даже день ничего было. Но потом опять начались такие же проблемы. Открывается документ и вместо табличной части серой поле, а потом прорисовывается табличная часть и начинаются тормоза. Закрыл-открыл программу, всё опять летает.
Визуальные эффекты отключены. Видеокарта стандартная.
Заметил новую особенность - возможно, это связано с "бездействием", например удалённый рабочий стол или свёрнут или на том компьютере, на котором открыт удалённый рабочий стол, включается заставка или отключение экрана, то возможно, это после "Пробуждения", провоцируется такой глюк с тормозами. Но пока на 100% не уверен. Буду наблюдать дальше!
(21) так заставка же не на сервере, не локальном компьютере ;)
Делюсь новыми наблюдениями: тормоза могут наблюдаться и сразу после запуска 1с:7.7. При закрытие и повторном запуске — всё ок.
Визуально хорошо тормоза проявляются при открытии документа, на форме вместо табличной части "серое поле", после чего начинает прорисовываться табличная часть.
Но чаще всего они случаются именно в процессе работы. Опять же внезапно.
ВосстановитьЗначение в модуле формы документа не используются.
То что файловая папка на диске сервера - об этом со слов топикстартера можно догадаться.
А что с запуском клиента программы? Его как запускаешь : это запуск на клиентской машине? А может это запуск в терминальной сессии на сервере?
Если проблема именно в настройках сервера - ну забери все себе на локальную машину для тестирования и каталог с базой и папку с бинарниками и смотри, что там будет с тормозами или нет.
Я бы в такой ситуации поискал самый самый последний пропатченный дистриб с 7.7
Почему тестировать на локальной машине - потому что станет понятна локализация причины тормозов. Если это на локальной машине тоже будет торомозить, то тогда надо копаться в состоянии базы, конфиг-файликов в базе и т.п. А если это тормозить не будет, то смотреть, что же там при установке дистрибутива на сервере не хватает.
Единственно, смущает что это не просто тормоза в работе с документами, а именно отрисовка окон - сами отрисовки окон вроде не тормозили никогда. Но получение данных могло зависать. Это другое.
Конфигурация
------------
По сути дела торговля, но на ТиС типовую уже давно и близко не похожа. Много лет работала на Windows Server 2003, если точно, то с весны 2005 года, всё довольно оптимизировано со стороны программного кода (несмотря на то, что база файловая) тормозов на WinServer2003 никаких никогда не было.
Точно также нет и тормозов, сейчас попробовал в неё работать на локальном компьютере на Windows 8.1, Windows 7, проблем никаких.
Таким образом, проблема не со стороны конфигурации
База данных на сервере на диске D, 1cv7\bin также на диске D
Сервер Windows Server 2016
Подключаюсь к нему по rdp (не интернет, по локальной сети), захожу как из учётной записи администратора, так и пользователей
---------
Windows Server 2016
Отключил Dynamic Fair Share Scheduling (DFSS)
(26) Фрэнки:
>> Единственно, смущает что это не просто тормоза в работе с документами, а именно отрисовка окон - сами отрисовки окон вроде не тормозили никогда. Но получение данных могло зависать. Это другое
вот в этом направлении интересно, может это какие-то тормоза при доступе к файлам dbf на диске, например, табличной части документа. Вот и начинает тупить в тот момент, когда выводит табличную часть.
Но опять же. стоит закрыть-открыть программу и всё сразу работает очень быстро
Сейчас попробую подключаться к серверу по rdp, но с компа с восьмёркой
Хотя вот так разобраться, ведь всёравно все выполняется все на сервере и база на сервере, и на связке Windows Server 2016->клиент Win10 через "Подключение к удалённому рабочему столу" передаётся только сама картинка, фактически по rdp.
offtop: В режиме совместимости с Win7 при открытии docx-файла через "ЗапуститьПриложение(ИмяФайла)" открывается Word и требует Активацию :D При отключении режима совместимости всё ок :)))
В продолжение темы "Перешёл на Windows Server 2016 и заметил такую вещь: иногда случаются тормоза 7.7.027 (файловой). Как выражается? Просто медленно начинают экранные формы отрисовываться и перемещение по строкам и реквизитам документа становится невыносимо медленным. После выхода из 1С и повторного входа опять всё летает. В какой момент случается "тормоз" так и не понял. Думал проблема из за работающей службы Dynamic Fair Share Scheduling (DFSS), которая в стандартном варианте всегда работает на Win2016, отключил. Но проблема всёравно иногда появляется." заметил интересную последовательность действий при которых проявляются эти самые невыносимые тормоза.
Есть документ. В табличной части которого есть реквизиты "ААААА" с типом "Справочник.ХХХХХХХХ". На экраной форме в строках есть эти самые реквизиты "ААААААА", и рядом с ним текстовый реквизит, в формуле которого "ААААААА.НаименованиеРеквизитаСправочникаХХХХХХХХ".
В самом Справочник.ХХХХХХХХ есть процедура, которая при определенных условиях пакетно изменяет этот самый непериодический НаименованиеРеквизитаСправочникаХХХХХХХХ. Эта процедура вызывается редко, раз в месяц (а то и нет). Никаких транзакций там нет. Просто поиск элементов справочника через метод НайтиПоРеквизиту и изменение НаименованиеРеквизитаСправочникаХХХХХХХХ.
Так вот, если выполнить процедуру, а затем открыть документ, в котором есть ссылка на один из измененных элементов справочника.ХХХХХХХ, то тогда в документе и проявляются эти самые жуткие тормоза.
И именно это проявилось в Windows Server 2016. При работе этой же базы в других операционных системах такого нет.
Дополнение. если изменить в справочнике эти же реквизиты, но вручную, то такого глюка нет.
Это именно при замене реквизита обработкой в процедуре:
ВСЁ. ПРИЧИНА НАЙДЕНА. Всё что написано выше - чистое совпадение.
после выполнения этого метода с флагом (1) в обработке - начинаются тормоза описанные выше.
Если не включать — ВСЁ ОК.
Многие уже слышали, что Cloud4Y — это корпоративный облачный провайдер. Поэтому не станем рассказывать о себе, а поделимся небольшой историей о том, как у нас возникли проблемы с доступом к некоторым сайтам и что послужило причиной этого.
Итак, ситуация: интернет-провайдер «Мегафон», серверная ОС Windows, браузер Firefox. Если открыть «ВКонтакте» с обычной Windows 10, то сайт загрузится за 10-100 ms. Если же мы попробуем открыть с Windows Server 2012/16/19, то задержка составляет до 15 секунд, а то и больше.
Взяли пиксель ВК, и через него начали отрабатывать возможные версии происходящего.
Проверка гипотезы №1 — проблема с сервером терминалов.
Не подтвердилась. При тестовом открытии страницы через другой сервер в той же сети проблема сохранилась.
Проверка гипотезы №2 — проблема в шлюзе.
Не подтвердилась. Отмечено, что у локальных ноутбуков всё открывается легко и быстро. Но при этом у терминалов (и внутренних серверов) проблема сохраняется. Поигрались с настройками ICMP на внешнем и внутреннем интерфейсе — не помогло.
Странно как-то получается.
С локального ноутбука сайт не тормозит.
С внутренней Scan-машины (терминал для сканирования) — не тормозит.
А у маркетинга тормозит. Непорядок!
Проверка гипотезы №3 — проблема в DNS.
Не подтвердилась. Запустили пиксель через публичный DNS (8.8.8.8) — та же история. Проблему явно видно, когда первый раз дёргаешь этот пиксель в режиме инкогнито, например.
Возникает подозрение, что проблема сильно от браузера зависит. В FF пиксель тупит всегда, в хроме при первом входе. У маркетинга тупит постоянно и на всех браузерах.
Проверка гипотезы №4 — Что-то с шаблоном ОС.
Не подтвердилась. Развернули чистую Windows Server 2016, запустили тест из сети .0. Получили проблему. Перевели в сеть .200., проблема сохранилась. То есть гейт сети .0. ни при чём. При этом ноутбуки из этой сети не имеют этой проблемы. То есть и гейт сети .200. тоже ни при чём.
То есть дело не в шаблоне ОС получается. Виртуальная машина тормозит с загрузкой пикселя. Но если поднять на ней VPN (отдельная сетевая карта) и трафик пустить через него, то всё отрабатывает очень быстро (как и должно быть). Видим, что есть два варианта, способных вызвать проблему: шлюз в офисе или оператор интернета в офисе.
Но разве может Мегафон специально обрезать доступ к пикселю ВКонтакта? Не, ерунда какая-то. Пробуем покопаться ещё.
Проверка гипотезы №5 — во всём виноваты VMware Tools.
Не подтвердилось. Никаких вредных действий не наблюдается. Попробовали настройки карты менять, тоже нет. TTL поменяли — никакого эффекта. Ну вообще непонятно, в чём разница между Windows 10 и Windows Server. Но разница есть. Как в истории с сусликом.
Проблемой мы занимались довольно много времени. Само собой, гуглили похожие ситуации, но не находили ничего. Так что действовали без подсказок, отрабатывая все возможные версии. Провели тестирование с ноутбука Windows 2016, чтобы убедиться, что в подтормаживании при загрузке пикселя виновата не виртуализация и прочее. Меняли все возможные настройки сетевой карты и IP стека. Перепробовали кучу всего. Но проблема оставалась, а маркетинг бил копытом и требовал всё починить.
Через некоторое время мы всё-таки нашли, где собака зарыта. Всё дело было в опции
netsh interface tcp setglobal ecncapability=disabled
Данная опция по умолчанию отключена на десктопных ОС Windows и по умолчанию включена на серверных. Как только мы отключаем её на серверной, всё открывается моментально, так же, как и на десктопной. Мы смогли подтвердить данную проблему от провайдера, который предоставляет нам интернет в офисе (Мегафон), через мобильный интернет Мегафона (если расшарить его с телефона и подключиться через Windows Server), через Yota, пробовали в некоторых районах Москвы и данная проблема везде присутствовала. При работе на других операторах доступ к сайту был мгновенный.
Вот такая вот загогулина, как выражался один видный политический деятель. В принципе, проблема сейчас решена, но нам очень интересно: она возникала только у нас или это масштабное бедствие, затрагивающее компании из других городов? Если этот случай не единичный, то Мегафону стоит подумать о решении этой проблемы. Ведь опция ECN (ecncapability) по умолчанию включена на серверах, и чтобы разобраться, в чём суть, нужно потратить немало времени.
Что ещё полезного можно почитать в блоге Cloud4Y
Подписывайтесь на наш Telegram-канал, чтобы не пропустить очередную статью! Пишем не чаще двух раз в неделю и только по делу.
Описание проблемы
Не так давно я развернул новую RDS ферму на базе Windows Server 2016 и мигрировал на нее пользователей с RDS фермы 2012 R2. Все было замечательно, пока основная масса людей полностью не перешла на новые сервера, по ситу это все те же виртуальные машины на базе ESXI 6.5. В какой-то момент стали поступать обращения в техническую поддержку, о том что конфигуратор 1С и сама 1Ска долго открывается и подтормаживает. Секунд по 30-40 висело вот такое окно конфигуратора, после чего открывалось и пользователи продолжали работу, кого-то это напрягало, а кого-то нет, в любом случае на прошлой RDS ферме этой проблемы не было. Давайте смотреть причины данной ситуации.
Почему может тормозить 1С на RDSH сервере
Основными причинами, которые могут на прямую или косвенно влиять на производительность приложений 1С можно выделить:
- Нехватка ресурсов у системы (Скорости дисков, процессорных мощностей, памяти и другого)
- Работа механизма распределения ресурсов в Windows под названием Dynamic Fair Share Scheduling (DFSS)
- Влияние антивируса
- У вас установлена устаревшая версия 1С
- Слишком большое количество одновременных подключений
1С и динамическое планирование долевого распределения
Когда я разбирался с медленной работой приложения Directum на терминальном сервере, то выяснил, что в ряде случаев в качестве причины может выступать с виду полезная функция "Динамическое планирование долевого распределения" которая не должна давать одному пользователю выедать все ресурсы, это можно сравнить с умной фильтрацией ALG трафика, которая то же должна улучшать голос, но по факту она же и вызывала проблемы. Поэтому я настоятельно рекомендую, когда вы делаете рабочие места 1С на RDS ферме, то на всех RDSH хостах отключайте Dynamic Fair Share Scheduling (DFSS), как это делать смотрите по ссылке, тут я лишь напомню в общих чертах.
Первое, что вы должны сделать, это открыть PowerShell в режиме администратора и проверить, работает ли DFSS или нет. Если будет стоять 1, то значит работает и вам нужно его менять на 0, при ноле делать больше ничего не нужно.
(gwmi win32_terminalservicesetting -N "root\cimv2\terminalservices").enabledfss
Так как мы получили 1, то вам нужно у двух ключей EnableCpuQuota и EnableFairShare нужно выставить значение "0". Я приводил выше ссылки, где лежат ключи, как вариант вы можете это сделать через групповую политику или скриптом. Если будите делать через GPO, то не забудьте ее потом обновить вручную.
Убедительно вас прошу, когда вы сделаете изменения в реестре, обязательно перезагрузите сервер, если это RDSH хост, то не забываем его перевести в режим стока или просто уведомить пользователей, что будет перезагрузка, дабы они успели сохранить свои документы и данныеПроверка достаточности ресурсов
На терминальных серверах очень часто может не хватать ресурсов, в виду того, что системный администратор не правильно оценил масштабы нагрузки на один хост. Напоминаю, что на одном RDSH сервере могут одновременно спокойно сидеть и по 40 и по 100 человек, тут важна балансировка и понимание, какие данные и ПО создают нагрузку. Первое на что я вам советую обратить внимание, это на загрузку CPU, в идеале у вас должна быть своя система мониторинга, которая следит за всеми показателями и где потом легко понять почему сервер и приложение 1С тормозили. Например у меня на работе используется Zabbix.
Запустите диспетчер задач, сделать это можно через одновременное нажатие CTRL+SHIFT+ESC. Переходим на вкладку производительность и смотрим нагрузку на CPU в реальном времени. Если она высокая, то сразу переходим в мониторинг ресурсов.
В мониторе ресурсов откройте вкладку ЦП и посмотрите самые нагруженные процессы, вы там легко можете увидеть ваш антивирус, который я предложу удалить в следующем пункте. Хочу отметить, что если будет загружен процессор под 100%, то у вас могут теряться сетевые пакеты и сервер может быть не доступен по сети, это особенно чувствуется, когда вы используете виртуальные машины с устаревшими сетевыми интерфейсами E1000.
Так же я вам тут же советую проверить загрузку вашей дисковой подсистемы, так как она может не выдерживать текущие нагрузки. Сделать это можно на вкладке "Диск". Тут нужно обратить внимание на два момента:
- Время ответа у процессов - для SSD этот показатель не более 30-40, для HDD не более 100-120
- Длина очереди к диску - Если она больше 1, например 5, то это плохо и есть проблемы с производительностью
Нагрузку на диски, память и дисковую подсистему вы можете уменьшить или убрать, путем миграции на другой ESXI хост, уменьшить количество одновременно работающих пользователей за RDSH хостом, это делается через оснастку управления RDS. Так же убедитесь, что у вас сам хост гипервизора не нагружен под 100%, такое то же бывает и могут легко быть предупреждения "Host CPU usage и host memory usage". Рассмотрите вариант расширения ресурсов у данного сервера или добавление еще одного и распределение нагрузки пользователей между ними.
Удаление антивируса
Понятно, что не хорошо такое советовать, но в момент поиска причины медленной работы 1С, я советую не отключить, а именно удалить ваше антивирусное решение, чтобы точно удостовериться, что причина не в нем, так как я очень часто с этим сталкивался. Потом если понятно, что дело в нем нужно реализовывать совместную работу. Основная идея в том, что нужно добавить компоненты 1С:Предприятия (например, папку C:\Program Files\1cv8\BIN и C:\Program Files\1cv8\server) и C:\Program Files (x86)\1cv8 в исключения. Также добавить в исключения рабочие (1Cv8*.1C? — маска для (1Cv8.1CD \ 1Cv8tmp.1CD \ 1Cv8.1CL \ 1Cv8tmp.1CL)
Запуск Resource Monitor под Windows Server
Наиболее простой способ запуска это в окне Run (команда Win + R) набрать комманду perfmon /res.
Вкладка Performance дает общую информацию о системе, которая может быть также полезна. Можно понять загрузка какого ресурса близка к 100%: памяти, CPU или локальной сети.
Использование Resource Monitor для поиска причины почему тормозит сервер.
Очень часто поиск причины тормозов сервера начинают с проверки загруженности дисковой системы. Ниже представлено окно Resource Monitor на вкладе Disk.
На вкладке Disk Activity показана загруженность в процентах. Если загрузка, близка к 100%, то скорее всего дисковая система является причиной низкой производительности системы. Щелкая по заголовку Total (B / Sec) можно отсортировать файлы с которыми в данный момент роботает система по объему чтетния и записи на диск. Наиболее загруженный файл и будет причиной тормозов системы. Зная какой файл создает высокую нагрузку гораздо легче понять, какой процесс нагружает систему. Если это какой-то системный файл начинающийся с C:/Windows, то есть смысл воспользоваться поисковой системой, чтобы понять, какой системной службе принадлежит данный файл.
Следущей причиной может стать Сетевая нагрузка. Особенно это актуально для VPS серверов. В случае если вы подключаетесь по RDP то сетевый задержки могут ощущаться как тормоза сервера. Переходим на вкладку Network:
В первую очередь обращаем внимание на общую нагрузку сети. Если она близка к 100% процентам, то скорее всего проблема в сети. На вкладке Processes with Network Activity и TCP Connections мы можем найти название процесса, который нагружает сеть. К сожалению, системные и серверный службы запускаются при помощи системного файла svchost.exe, и часто непонятно какая именно служба загружает сеть. Но если, вы видите, что причина в svchost.exe, то причину нужно искать в службах Windows.
Бывает так, что вы запустили слишком много программ и у вас банально не хватает оперативной памяти. В этом случае нам может помочь вклада Memory. Иформация по процессам аналогична вкладке Network:
Самый простой случаей это загрузка CPU. Ее можно посмотреть на вкладке как на вкладке CPU так и в обычном Task Manager:
Читайте также: