Тормозит windows server 2019
Обновлено: 05.07.2024
С этим сервером у меня есть 2 проблемы, обсуждение этих проблем в русскоязычном сегменте я не нашел:
1. Hyper-v, поднятый на 2019 сервере не завершает корректно работу виртуальных машин при своем выключении.
Самое главное, что такая проблема уже возникала после одного из обновлений на 2012 сервере и там достаточно быстро вышел патч с исправлением. А тут прям забили на решение.
2.Eсть ноутбук Dell 5468, под управлением windows server 2019 Datacenter, не подключается к телевизору по miracast (widi).
Для справки: Все это работало в этом же аппаратном наборе, но ноутбуке стоял Server 2016, перестало работать после апгрейда на 2019. Если поставить начисто 2019 тоже не работает, проблема явно в Server 2019. С других двух компьютеров, где Win 10 с этим телевизором все работает, значит он в порядке, если на ноутбук снова поставить начисто server 2016, то тоже работает, значит ноутбук впорядке.
При создании подключения к беспроводному дисплею, панель подключения, где должен появится список беспроводных устройств (дисплеев) просто закрывается.
В логах есть такая ошибка:
Имя сбойного приложения: ShellExperienceHost.exe, версия: 10.0.17763.1, метка времени: 0x5b9c8bd8
Имя сбойного модуля: ntdll.dll, версия: 10.0.17763.348, метка времени: 0xca65c822
Код исключения: 0xc0000005
Смещение ошибки: 0x0000000000033fc8
Идентификатор сбойного процесса: 0xcc4
Время запуска сбойного приложения: 0x01d4d59d7b0e2b2c
Путь сбойного приложения: C:\Windows\SystemApps\ShellExperienceHost_cw5n1h2txyewy\ShellExperienceHost.exe
Путь сбойного модуля: C:\WINDOWS\SYSTEM32\ntdll.dll
Идентификатор отчета: 9dc3dd63-7d96-4ebb-9052-433a5b6cc03c
Полное имя сбойного пакета: Microsoft.Windows.ShellExperienceHost_10.0.17763.1_neutral_neutral_cw5n1h2txyewy
Код приложения, связанного со сбойным пакетом: App
Ну вот собственно все, возможно найдутся люди у которых те же проблемы, ну и может кто-то из Майков обратит внимание на это.
(7)1С предлагает использовать методику Apdex. Если базы на основе БСП, то в них есть подсистема "Оценка производительности". Сама по себе штука требует позаморачиваться в настройке целевого времени ключевых операций, но в последующем предоставляет возможность получать в цифрах прирост (или отрицательный прирост) в производительности. Сравнивать надо до и после. Еще есть "Стандартный нагрузочный тест" , входящий в состав "Корпоративный инструментальный пакет". Тоже можно сравнить две системы.
Помимо вышесказанного замечу, что бюджетом в 370 тысяч вы распорядились неразумно. Перевод баз из файлового режима в клиент-серверный, за исключением редких случаев, дает ощутимый (в разы) прирост производительности. А проблему нехватки памяти надо решать в первую очередь переводом на 64-разрядную платформу. 370 т.р. хватило бы на оба апгрейда.
И последнее. Если вы работаете в режиме удаленного рабочего стола, то падение производительности не может быть связано с клиентскими компами. Это 100% на стороне сервера. Вас пытаются надуть, меняйте провайдера.
(7)выделили 370 тыщ рублей на сервер и работы что бы продолжать работать в файловых бд? Арендодатель говорит, что проблемы в наших компьютерах. Арендодатель предложил обновить ПО до Windows Server 2019, у которого ОЗУ можно было выделить 64 Гб.Можно название компании с такими "эКСПЕРТАМИ"?
Конфигурации УНФ 7Гб и Документооборот 1Гб, пользователей 30.Если конфигурации типовые дешевле было бы во шрэш перейти
виртуалка - не самый лучший выбор (можно работать но только после тонкой настройки)
Intel® Xeon® E5-2603 v2 1,80 ГГц - не самый лучший выбор
Откровенно говоря даже не знаю что Вам посоветовать в данной ситуации.
Правильней всего было бы переезд на SQL и на другой сервер, но это большие финансовые затраты.
Если без финансовых вложений это перенос баз на RamDisk, но это повлечёт риски потери данных при аварийном выключении сервера.
Или попробуйте развернуть вэб-сервер и подключаться к базам тонким клиентом через вэб. Даже на одном компьютере в файловом режиме это может убрать часть проблем с блокировками.
Многие уже слышали, что 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-канал, чтобы не пропустить очередную статью! Пишем не чаще двух раз в неделю и только по делу.
Несколько раз встречался с тем, что скорость копирования файлов по сети с/на виртуальные машины на Hyper-V в Windows Server 2019 намного ниже, чем в ВМ аналогичной конфигурации на хосте с Windows Server 2016. В некоторых тестах скорость записи/чтения данных по сети на ВМ в Windows Server 2019 почти в три раза ниже, чем в WS2016 (тестировалось копирование по SMB, SSH/SCP). Эта статья не претендует на абсолютную истину, но в ней я попытался собрать различные методики улучшения производительности сети в виртуальных машинах Hyper-V на Windows Server 2019 (и последних билдах Windows 10).
Receive Segment Coalescing в Hyper-V 2019
В первую очередь нужно вспомнить про технологии Receive Segment Coalescing (RSC), которая появилась в Hyper-V на Windows Server 2019/2022 (и в Windows 10 начиная с билда 1809). Receive Segment Coalescing используется на уровне виртуального коммутатора (vSwitch), позволяет снизить нагрузку на CPU и увеличить пропускную способность сети за счет объединения нескольких TCP сегментов в меньшее количество более крупных сегментов. Увеличение производительности сети достигается за счет того, что несколько больших сегментов обрабатывают быстрее множества мелких.
В предыдущих версиях Hyper-V на Windows Server 2016/2012R2 поддерживалась только аппаратная версия Receive Segment Coalescing на уровне сетевой карты.Наличие включенной поддержки RSC часто бывает источником дополнительной сетевой задержки в некоторых комбинациях железа.
Проблема проявляется как в полноценной Windows Server 2019 с графическим интерфейсом, так и в бесплатной редакции Windows Hyper-V Server.По умолчанию в Windows Server 2019 RSC включен для всех внешних (External) vSwitches.
Проверить, включен ли RSC для виртуальных коммутаторов можно командой:
Get-VMSwitch | Select-Object *RSC*
Можно запретить использовать RSC для IPv4 трафика на уровне клиентского сетевого адаптера:
Disable-NetAdapterRsc -Name "Ethernet" -IPv4
Проверьте, увеличится ли скорость копирования в ВМ на Hyper-V при отключении RSC. Если скорость сети увеличилась, можно отключить RSC на виртуальном коммутаторе, к которому подключена ВМ.
Пропускную способность сети можно замерить с помощью утилиты iperf.Чтобы отключить программный RSC для определенного виртуального коммутатора, выполните команду:
Set-VMSwitch -Name vSwitchName -EnableSoftwareRsc $false
Либо можно полностью отключить RSC на хосте:
netsh int tcp set global rsc=disabled
Режим VMQ в драйвере сетевого адаптера
В некоторых случаях наличие включенной опции VMQ (Virtual Machine Queue) в драйвере сетевого адаптера физического хоста Hyper-V может привести к плохой производительности сети в виртуальных машинах Hyper-V. Связано это с тем, что VMQ это аппаратная функция, и, если она не поддерживается железом, но включена в драйвере это вызывает потерю пакетов и увеличивает сетевую задержку. Эта проблема характерна для сетевых карточек Broadcom Gigabit и встречается во всех версиях Hyper-V на Windows 2012 R2/2016/2019.
VMQ предназначен для повышения производительности сети за счет передачи пакетов от физического сетевого адаптера напрямую виртуальным машинам.Вы можете отключить VMQ в свойствах драйвера сетевого адаптера.
Либо вы можете вывести список сетевых адаптеров с поддержкой VMQ и их статус с помощью PowerShell:
Чтобы отключить VMQ для определенного адаптера, выполните команду (сетевой адаптер будет недоступен в течении пары секунд):
Set-NetAdapterVmq -Name “NICName” -Enabled $False
После отключения VMQ лучше перезагрузить хост и проверить сетевую производительность.
Оптимизация параметров протокола TCP для Windows Server 2019 Hyper-V
Сохраните текущие настройки TCP на хосте Hyper-V и примените новые настройки, которые сделают настройки протокола TCP в Windows Server 2019 максимально похожими на Windows Server 2016.
Сохраните текущие настройки:
Get-NetTCPSetting -SettingName Datacenter,DatacenterCustom,InternetCustom,Internet|select SettingName,CongestionProvider,CwndRestart,ForceWS|Export-csv c:\ps\nettcp_backup.csv
Примените новые настройка для LAN сети:
Set-NetTCPSetting -SettingName DatacenterCustom,Datacenter -CongestionProvider DCTCP
Set-NetTCPSetting -SettingName DatacenterCustom,Datacenter -CwndRestart True
Set-NetTCPSetting -SettingName DatacenterCustom,Datacenter -ForceWS Disabled
Set-NetTCPSetting -SettingName InternetCustom,Internet -CongestionProvider CTCP
Set-NetTCPSetting -SettingName InternetCustom,Internet -DelayedAckTimeoutMs 50
Set-NetTCPSetting -SettingName InternetCustom,Internet -ForceWS Disabled
Отключите методики оптимизации сетевого RSS и RSC на уровне стека TCP:
netsh int tcp show global
netsh int tcp set global RSS=Disabled
netsh int tcp set global RSC=Disabled
или на уровне сетевых адаптеров:
Get-NetAdapter | Set-NetAdapterAdvancedProperty -DisplayName "Recv Segment Coalescing (IPv4)" -DisplayValue "Disabled" -NoRestart
Get-NetAdapter | Set-NetAdapterAdvancedProperty -DisplayName "Recv Segment Coalescing (IPv6)" -DisplayValue "Disabled" -NoRestart
Get-NetAdapter | Set-NetAdapterAdvancedProperty -DisplayName "Receive Side Scaling" -DisplayValue "Disabled" –NoRestart
Отключите vRSS для всех ВМ:
Get-VM | Set-VMNetworkAdapter -VrssEnabled $FALSE
Отключите функцию Large Send Offload (LSO) на сетевых картах:
Get-NetAdapter | Set-NetAdapterAdvancedProperty -DisplayName "Large Send Offload Version 2 (IPv4)" -DisplayValue "Disabled" -NoRestart
Get-NetAdapter | Set-NetAdapterAdvancedProperty -DisplayName "Large Send Offload Version 2 (IPv6)" -DisplayValue "Disabled" -NoRestart
Get-NetAdapter | Restart-NetAdapter
- Recv Segment Coalescing (IPv4/IPv6) = Disabled
- Large Send Offload V2 (IPv4/IPv6) = Disabled
Данные настройки стека TCP максимально приблизят настройки сетевых протоколов Windows Server 2019 к предыдущим версиям Windows Server.
Читайте также: