Максимальный размер каталога службы индексирования
Кто-нибудь знает, каков максимальный размер индекса службы индексирования в Windows 2008? У нас возникают всевозможные проблемы с зависанием индекса и не обрабатываются новые документы.
Я просто удалил каталог и создал его заново. Я добавил в 4 папки, которые должны быть индексами, но есть еще 8, чтобы добавить. Индекс вырос до ~3 гигабайт для 4 индексируемых папок.
До сих пор служба индексирования работала уже несколько дней. (Постучите по дереву.) Теперь я думаю, что службе индексирования не нравится, когда происходит сбой сетевого ресурса, на который она смотрит. Файловый сервер является активным пассивным кластером, и все сетевые ресурсы являются ресурсом кластера в собственной кластерной группе (приложение кластера с использованием терминов Windows 2008). Служба индексирования также является кластерным ресурсом в своем собственном приложении, поэтому она может переключаться при сбое независимо от общих файловых ресурсов.
Из того, что я могу сказать, служба индексирования может только испытывать паническую атаку при сбое одного из узлов (если это происходит каждый раз, когда Microsoft выпускает исправление при перезагрузке узлов).
Я рассматриваю возможность размещения сценария в каждом кластерном приложении, который заставляет службу индексирования отключаться, а затем возвращаться в оперативный режим при сбое любого из отслеживаемых сетевых ресурсов. Если я пойду по этому пути, я должен быть осторожен, чтобы при одновременном переключении нескольких сетевых ресурсов они не начинали давать сбой, если служба индексирования уже находится в процессе переключения при сбое.
2 ответа
Прошло некоторое время с тех пор, как вы разместили этот вопрос. Можете ли вы добавить обновленную информацию о поведении / производительности, которые вы видите?
Ненавижу это говорить, но я собираюсь догадаться, что вы сами "оцениваете это и видите" территорию. Мне не известны какие-либо опубликованные "ограничения" на службу индексирования. Действительно, "Microsoft Index Server", который является прародителем современной "Службы индексирования", был специально процитирован и не имеет встроенных ограничений (см. http://msdn.microsoft.com/en-us/library/dd582938(office.11).aspx для деталей) к номерам документов или, предположительно, к размеру каталога. Поведение службы индексирования в значительной степени зависит от типа и состава индексируемых документов, поэтому не существует простого числа "максимального размера".
Когда вы говорите "... есть ~500 файлов...", вы говорите о 500+ файлах, лежащих в каталоге? Это звучит так, будто CiSvc по какой-то причине не выполняет слияния. Подавляющее большинство лежащих вокруг файлов должно быть объединено с основным файлом Catalog.WCI и удалено. Существует ежедневное "мастер-слияние", которое должно происходить, как минимум, для объединения всех теневых индексов, созданных процессами CiDaemon, в мастер-индекс. Perfmon может показать вам больше о том, что происходит внутри.
Эмпирическое правило для размера индекса, которое мы всегда использовали в NT 4.0 дней, составляло примерно 40% от размера корпуса индексируемых документов. Это согласуется с файлами, которые вы индексируете?
Если вы не возражаете, что поиск не может охватывать несколько каталогов (если вы не кодируете что-то, чтобы отправить один и тот же поиск по нескольким каталогам и агрегировать результаты самостоятельно), вы можете разбить корпус на несколько каталогов, если начнете сталкиваться с проблемами производительности.
Мне интересно услышать, что вы используете службу индексирования. Это почтительно, начиная еще с пакета опций Windows NT 4.0 - даже дальше, если учесть, что это было частью инициативы "Каир", в то время (под кодовым названием Триполи). Вы вспоминаете "мастер-слияния" и "теневые слияния", а также всевозможные мелкие детали старого "Microsoft Index Server", о котором я думала, что забыли... >smile <Мне грустно, что Microsoft этого не сделала приложите больше усилий к нему, как к продукту, потому что он мог легко стать основой для распределенной поисковой системы предприятия. Ох, ну... пути не пройдены, я полагаю.
Редактировать:
Вы находитесь на масштабной территории, на которой я никогда раньше не пользовался службой индексирования. Несколько каталогов (или даже несколько экземпляров службы индексирования в нескольких блоках), вероятно, - ваше следующее место, когда страдает перфект. Надеюсь, вам не нужно идти туда.
Я не уверен, как он "знает", как "паниковать", когда акции отказывают, и я осмелюсь сказать, что потребуется поискать источник, чтобы выяснить, почему. Это звучит как один из тех, "Доктор, мне больно, когда я это делаю". "Ну, не делай этого". вид вещей. С этой целью ваш план по обработке аварийного переключения акций, вероятно, является хорошим.
Отношение индекса к корпусу 30% или менее определенно лучше, чем Microsoft всегда планировала, когда-то. Похоже, что файлы, которые вы индексируете, в основном текстовые, не имеют накладных расходов на OLE-свойства для кэширования, как документы Office (что, как я полагаю, послужило основой Microsoft для эмпирического правила в 40%). (Кроме того, вы можете иметь свои фильтры кода разработчиков для этих различных типов файлов и получить возможность выполнять поиск по конкретным свойствам, если вы так склонны. Покажите мне все электронные письма из хххх и т. Д. Хе-хе. будет, конечно, расти кеш свойств.)
500+ файлов в каталоге, наконец, очистились и слились, не так ли?
Что он делает, когда все равно "паникует"? Это просто перестает "видеть" новые документы и индексировать их?
Интересно, может ли "все" ( http://www.voidtools.com/) заменить службу индексирования (что, как мне показалось, очень часто проблематично. Использовать все очень приятно, хотя и делает что-то отличное от индексирования).