Влияние Sharepoint Search на производительность

Недавно мы столкнулись с очень серьезными проблемами производительности на одном из наших production серверов. Сайты созданные на Sharepoint очень медленно открывались либо не открывались вовсе с ошибкой “The operation has timed out”. Я перепробовал много решений. Сначала я более тонко настроил ASP.Net, используя это руководство. Это помогло — на некоторое время зависания прекратились, но по прошествии нескольких недель, проблемы с производительностью вернулись. После более детального изучения я обратил внимание на следующие сообщения об ошибках в event log-е:

Application Server Administration job failed for service instance Microsoft.Office.Server.Search.Administration.SearchServiceInstance (0fb6066b-7fd5-4926-a28e-2348c0ae1256).

Reason: Access to the path 'C:\WINDOWS\system32\drivers\etc\HOSTS' is denied.

Techinal Support Details:
System.UnauthorizedAccessException: Access to the path 'C:\WINDOWS\system32\drivers\etc\HOSTS' is denied.
   at System.IO.__Error.WinIOError(Int32 errorCode, String maybeFullPath)
   at System.IO.FileInfo.Delete()
   at Microsoft.Search.Administration.Security.HOSTSFile.CleanupDedicatedGathering(Hashtable HOSTSFileMappings, StringBuilder HOSTSComments, IEnumerable obsoleteHosts, String dedicatedName, Boolean isDirty)
   at Microsoft.Search.Administration.Security.HOSTSFile.ConfigureDedicatedGathering(SearchServiceInstance searchServiceInstance, SPServer dedicatedWebFrontEndServer, IList`1 previousWebApplicationHostNames)
   at Microsoft.Office.Server.Search.Administration.SearchServiceInstance.SynchronizeDefaultContentSource(IDictionary applications)
   at Microsoft.Office.Server.Search.Administration.SearchServiceInstance.Synchronize()
   at Microsoft.Office.Server.Administration.ApplicationServerJob.ProvisionLocalSharedServiceInstances(Boolean isAdministrationServiceJob)

Также я проверил содержимое папки 12/logs на этом WFE и обнаружил, что вместе с обычными лог файлами Sharepoint-а здесь было очень много файлов с именами вида hosts.yyyy.MM.dd.hh.mm.ss.mm (последние mm –означают миллисекунды). Это были копии hosts файла из C:\WINDOWS\system32\drivers\etc. В папке находилось около 60000 подобных файлов (на многих форумах говориться, что для нормальной производительности в папке должно быть не больше 30000 файлов, хотя NTFS и поддерживает миллионы файлов в папке). При открытии папки 12/logs в проводнике Windows он зависал на несколько секунд. У меня появилась следующая идея: т.к. указанные hosts* файлы копировались в ту же папку, что и обычные логи, Sharepoint мог зависать при логировании информации по тем же самым причинам, по которым зависал проводник при открытии папки. Я удалил все hosts* файлы и начал мониторинг.

Моя гипотеза подтвердилась: проблемы с производительностью исчезли, но причины, которые ее вызывали не были устранены. По какой-то причине hosts* файлы продолжали появляться в папке 12/logs каждую минуту (1 файл за минуту). Принимая во внимание ошибку в event log-е, указанную выше, главным подозреваемым стал Office Sharepoint Server Search (не путать с Windows Sharepoint Services Search). Подозрение подтвердилось, т.к. после того, как я выключил этот сервис (вернее установил статус в disabled, т.к. обычным стоп не помогал – Sharepoint упорно перезапускал его каждую минуту), файлы перестали появляться. При этом пользователи получали следующее сообщение об ошибке при нажатии на кнопку Поиск в стандартном search box-е:

The search request was unable to connect to the Search Service

Но по какой причине служба поиска копировала hosts файл каждую минуту? На файл C:\WINDOWS\system32\drivers\etc\hosts  был установлен атрибут “Только для чтения”. Чтобы объяснить, зачем это было сделано, мне нужно сказать пару слов о конфигурации. Это ферма с несколькими WFE серверами. Каждый WFE имеет несколько сетевых карт и как следствие два IP адреса (по одному на каждую сетевую карту). Также веб приложение использует несколько зон аутентификации: NTLM и FBA.  При этом веб приложение для каждой зоны аутентификации использует свой собственный IP адрес (с помощью привязок (bindings) в IIS менеджере). Последнее было сделано для улучшения производительности.

Служба поиска (search service) работал на одном из WFE и использовала его как сервер индексации (именно тот WFE, на котором появились сообщения об ошибках в event log-е и на котором было множество hosts* файлов в папке 12/logs). Также в соответствии с рекомендациями MS, службы поиска была настроена на использование выделенного WFE для поиска (dedicated WFE for crawling): Configure a dedicated front-end Web server for crawling. Это было сделано опять же для улучшения производительности путем уменьшения сетевого трафика (т.к. в этом случае crawler использует тот же сервер, на котором запущен сам). Но в той же статье есть заметка про возможные проблемы с этим подходом:

Possible problems

In some cases, the timer service writes the incorrect IP address to your Hosts file. (For more information, see the blog post at http://go.microsoft.com/fwlink/?LinkId=135698.) This can cause problems ranging from inability to crawl content to inability to view sites, such as the Search Services Provider (SSP) or Central Administration site. The timer service can add an incorrect IP address to the Hosts file in cases such as the following:

  • The server that you specified as your dedicated front-end Web server for crawling has multiple IP addresses assigned to one or more network cards.
  • Your server farm is using network load balancing.

If either of these conditions is true, we recommend that you add the entries to the Hosts file directly instead of using the user interface to specify a dedicated front-end Web server for crawling.

Как я писал выше, каждый WFE имеет несколько сетевых карт. В этом и была проблема. Служба поиска пыталась обновить hosts файл с неправильными IP адресами. Для этого hosts файл был помечен атрибутом “Только для чтения”. Но это имело неприятный side effect: служба поиска начала копировать его в папку 12/logs каждую минуту. И это стало причиной проблем с производительностью, когда в папке накопилось много таких файлов.

Приведенная выше статья содержит также решение проблемы: см. Configure a dedicated front-end Web server for crawling by editing the Hosts file. После того, как я переконфигурировал Search service указанным образом, файлы перестали появляться. Как видите, это достаточно неочевидная причина для падения производительности. Надеюсь эта информация окажется для вас полезной.

Реклама

Об авторе sadomovalex

Старший инженер, team lead, консультант. Работаю в стеке .Net. Последние несколько лет занимаюсь разработкой enterprise приложений под Sharepoint, чему и будет в основном посвящена тематика этого блога. Также активно использую и интересуюсь ASP.Net MVC, DDD, TDD, Agile. Активно участвую в жизни многих профессиональных сообществ, SPb .Net UG, SPb ALT.Net, rsdn, Finland SP UG и др.
Запись опубликована в рубрике Performance, Sharepoint. Добавьте в закладки постоянную ссылку.

Добавить комментарий

Заполните поля или щелкните по значку, чтобы оставить свой комментарий:

Логотип WordPress.com

Для комментария используется ваша учётная запись WordPress.com. Выход / Изменить )

Фотография Twitter

Для комментария используется ваша учётная запись Twitter. Выход / Изменить )

Фотография Facebook

Для комментария используется ваша учётная запись Facebook. Выход / Изменить )

Google+ photo

Для комментария используется ваша учётная запись Google+. Выход / Изменить )

Connecting to %s