vkapas
16-03-2023, 15:53
Есть терминальный WS 2019 на 15 пользователей, работающий на ESXi, под который выделены: почти все ресурсы Intel Xeon Silver 4208 (12 vCPUs из 16), 100 ГБ DDR4 ОЗУ и достаточный объём SSD в RAID1 на Smart HBA H240.
Проблема — в службе Windows Search. WSearch — самый тяжёлый процесс в системе, который в простое потребляет 5% ЦП, в рабочее время около 15%, а на пике и вовсе скачет аж до 30-40%. Из-за этого общая нагрузка сервера часто упирается в 80-100%, и начинаются сильные лаги.
Изначально Windows Search индексировал и файловый архив и почтовый, и казалось, что дело в большом массиве писем Outlook (порядка двух-трёх сотен тысяч). Но после отключения индексации Outlook и пересоздания индекса только день-два нагрузка WSearch была в пределах 5%, и затем постепенно вернулась к прежним значениям. Пересоздание индекса и/или его дефрагментация как описано здесь (https://winitpro.ru/index.php/2017/04/05/boremsya-s-rostom-fajla-windows-edb-sluzhby-poiska-windows/) ситуацию также не исправляют.
В параметрах индексирования указаны только те папки, которые необходимы; поиск по содержимому включён — это критически важно для нормальной работы пользователей. Файловый архив относительно небольшой — 90 ГБ и 150 000 документов.
Несмотря на то, что это Windows Server 2019, файл поискового индекса единый, включён через EnablePerUserCatalog = 0, т.к. при настройках по умолчанию, когда файл поискового индекса у каждого пользователя свой, поиск по сути не работает — не находит ничего дальше текущей папки. (Собственно, служба Windows Search даже была отключена по умолчанию начиная с WS 2016, т.к. она can cause problems in certain scenarios (https://learn.microsoft.com/en-US/troubleshoot/windows-server/shell-experience/windows-search-is-disabled-by-default) — как раз с ролью RDSH.)
Что-то можно сделать в данной ситуации, кроме замены процессора?
Проблема — в службе Windows Search. WSearch — самый тяжёлый процесс в системе, который в простое потребляет 5% ЦП, в рабочее время около 15%, а на пике и вовсе скачет аж до 30-40%. Из-за этого общая нагрузка сервера часто упирается в 80-100%, и начинаются сильные лаги.
Изначально Windows Search индексировал и файловый архив и почтовый, и казалось, что дело в большом массиве писем Outlook (порядка двух-трёх сотен тысяч). Но после отключения индексации Outlook и пересоздания индекса только день-два нагрузка WSearch была в пределах 5%, и затем постепенно вернулась к прежним значениям. Пересоздание индекса и/или его дефрагментация как описано здесь (https://winitpro.ru/index.php/2017/04/05/boremsya-s-rostom-fajla-windows-edb-sluzhby-poiska-windows/) ситуацию также не исправляют.
В параметрах индексирования указаны только те папки, которые необходимы; поиск по содержимому включён — это критически важно для нормальной работы пользователей. Файловый архив относительно небольшой — 90 ГБ и 150 000 документов.
Несмотря на то, что это Windows Server 2019, файл поискового индекса единый, включён через EnablePerUserCatalog = 0, т.к. при настройках по умолчанию, когда файл поискового индекса у каждого пользователя свой, поиск по сути не работает — не находит ничего дальше текущей папки. (Собственно, служба Windows Search даже была отключена по умолчанию начиная с WS 2016, т.к. она can cause problems in certain scenarios (https://learn.microsoft.com/en-US/troubleshoot/windows-server/shell-experience/windows-search-is-disabled-by-default) — как раз с ролью RDSH.)
Что-то можно сделать в данной ситуации, кроме замены процессора?