Кто-нибудь знает, какой максимальный размер индекса службы индексирования в Windows 2008? У нас всякие проблемы с зависанием индекса и отсутствием обработки новых документов.
Я просто удалил каталог и воссоздал его. Я добавил 4 папки, которые должны быть индексами, но нужно добавить еще 8. Индекс увеличился до ~ 3 гигабайт для 4 индексируемых папок.
На данный момент служба индексирования работает уже несколько дней. (Постучите по дереву.) Я теперь думаю, что службе индексирования не нравится, когда общий сетевой ресурс, на который она смотрит, выходит из строя. Файловый сервер является активным пассивным кластером, и все общие сетевые ресурсы являются ресурсом кластера в пределах своей собственной группы кластеров (приложение кластера в терминах Windows 2008). Служба индексации также является кластеризованным ресурсом в собственном приложении, поэтому она может переключаться при отказе независимо от общих файловых ресурсов.
Насколько я могу судить, служба индексирования может вызвать паническую атаку только при отказе одного из узлов (при условии, что это происходит каждый раз, когда Microsoft выпускает исправление при перезагрузке узлов).
Я рассматриваю возможность размещения сценария в каждом кластеризованном приложении, который заставляет службу индексирования отключаться, а затем снова подключаться к сети при отказе любого из контролируемых сетевых ресурсов. Если я пойду по этому пути, мне придется быть осторожным, чтобы при одновременном переключении нескольких сетевых ресурсов при отказе они не начали отказывать, если служба индекса уже находится в процессе аварийного переключения.
Прошло некоторое время с тех пор, как вы разместили этот вопрос. Можете ли вы рассказать обновленную информацию о поведении / производительности, которые вы наблюдаете?
Ненавижу это говорить, но я собираюсь предположить, что вы любите «протестировать сами и увидеть» территорию. Мне не известно о каких-либо опубликованных «ограничениях» службы индексирования. Действительно, был специально упомянут «Microsoft Index Server», который является предком современной «Indexing Service», не имеет встроенных ограничений (см. 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 Option Pack - даже дальше, если учесть, что он был частью инициативы «Каир». путь назад (в то время кодовое название Триполи). Вы заставляете вспомнить «основные слияния» и «теневые слияния» и всевозможные мелкие детали старого «Microsoft Index Server», которые, как я думал, я забыл ...> улыбка <Мне грустно, что Microsoft этого не сделала приложить больше усилий для этого как продукта, потому что он легко мог бы стать основой для распределенной поисковой системы предприятия. О, ну ... я полагаю, что пути не выбраны.
Редактировать:
Вы находитесь на масштабной территории, в которой я никогда раньше не использовал службу индексирования. Множественные каталоги (или даже несколько экземпляров службы индексирования на нескольких ящиках), вероятно, станут вашим следующим местом, куда вы можете обратиться, когда нарушается производительность. Надеюсь, тебе не нужно туда ехать.
Я не уверен, как он «знает», что нужно «паниковать», когда акции выходят из строя, и я полагаю, что потребуется посмотреть на источник, чтобы понять, почему. Это похоже на одно из тех «Доктор, мне больно, когда я это делаю». «Ну, не делай этого». вид вещей. С этой целью ваш план по обработке отказа общих ресурсов, вероятно, является хорошим.
30% или меньше соотношение индекса к корпусу определенно лучше, чем Microsoft всегда планировала в свое время. Похоже, файлы, которые вы индексируете, в основном текстовые, не имеют накладных расходов на свойства OLE, которые нужно кэшировать, как документы Office (что, я считаю, было основой Microsoft для практического правила, равного 40%). (Кроме того, вы можете настроить фильтры кода разработчика для этих различных типов файлов и получить возможность выполнять поиск по конкретному объекту, если вы так склонны. Покажите мне все электронные письма от xxxx и т.д ... хе-хе. Это конечно, увеличит кеш свойств.)
Более 500 файлов в каталоге наконец-то были очищены и объединены, не так ли?
Что он вообще делает, когда «паникует»? Он просто перестает «видеть» новые документы и индексировать их?
Интересно, а все ли (http://www.voidtools.com/) может заменить службу индексирования (которая, как мне кажется, очень часто вызывает проблемы. Всем приятно пользоваться, хотя она и делает нечто иное, чем индексирование.