Tamanho máximo de um catálogo de serviço de indexação

Question

Alguém sabe qual é o tamanho máximo em um índice de serviço de indexação no Windows 2008? Estamos tendo todos os tipos de problemas com o índice pendurado e não processando novos documentos.

Acabei de eliminar o catálogo e recriá-lo. Eu adicionei em 4 das pastas que devem ser índices, mas tem mais 8 para adicionar. O índice subiu para ~ 3 Gigs para as 4 pastas que estão sendo indexadas.

Até agora, o serviço de indexação já está funcionando há vários dias. (Knock on wood) Agora estou pensando que o serviço de indexação não gosta quando o compartilhamento de rede que está procurando falha. O servidor de arquivos é um cluster passivo ativo e todos os compartilhamentos de rede são um recurso de cluster dentro do próprio grupo de clusters (aplicativo de cluster que usa termos do Windows 2008). O serviço de indexação também é um recurso em cluster dentro de seu próprio aplicativo, para que ele possa executar failover independentemente dos compartilhamentos de arquivos.

Pelo que eu posso dizer, o serviço de indexação apenas parece ter realmente um ataque de pânico quando um dos nós falha (desde que isso aconteça toda vez que a Microsoft libera um patch à medida que os nós são reinicializados).

Estou pensando em colocar um script em cada aplicativo clusterizado que force o serviço de indexação a ficar off-line e, em seguida, a ficar on-line quando qualquer um dos compartilhamentos de rede monitorados falhar. Se eu seguir esse caminho, terei que ter cuidado para que, quando vários compartilhamentos de rede falharem de uma só vez, eles não comecem a falhar se o serviço de indexação já estiver em processo de failover.

    

Answer 1

Faz algum tempo desde que você postou esta pergunta. Você pode fazer uma atualização sobre o comportamento / desempenho que está vendo?

Eu odeio dizer isso, mas eu vou adivinhar que você está em "benchmark e veja" território. Não tenho conhecimento de nenhum "limite" publicado no Serviço de Indexação. Na verdade, o "Microsoft Index Server", que é um ancestral do "Serviço de indexação" moderno, foi especificamente citado por não ter limites embutidos (consulte link para detalhes) para números de documentos ou, presumivelmente, tamanho de catálogo. O comportamento do Serviço de Indexação é altamente dependente do tipo e da composição dos documentos que estão sendo indexados, portanto, não há um número fácil de "tamanho máximo".

Quando você diz "... existem ~ 500 arquivos ...", você está falando de mais de 500 arquivos espalhados pelo diretório do catálogo? Isso faz parecer que o CiSvc não está fazendo fusões, por algum motivo. A grande maioria dos arquivos dispostos deve ser mesclada no arquivo Catalog.WCI principal e ser excluída. Há uma "mesclagem mestra" diária que deve estar ocorrendo, no mínimo, para combinar todos os índices de sombra criados pelos processos do CiDaemon no índice mestre. Perfmon pode mostrar mais sobre o que está acontecendo dentro.

A regra básica para o tamanho do índice que sempre utilizamos nos dias do NT 4.0 foi de aproximadamente 40% do tamanho do corpus de documentos indexados. Isso combina com os arquivos que você está indexando?

Se você não se importa que as pesquisas não abranjam vários catálogos (a menos que você codifique algo para enviar o mesmo serach em vários catálogos e agregue os resultados), pode dividir seu corpus em vários catálogos se começar a bater Problemas de desempenho.

É interessante, para mim, saber que você está usando o Serviço de indexação. É venerável, datando todo o caminho de volta para o Windows NT 4.0 Option Pack - ainda mais se você considerar que era parte da iniciativa "Cairo" caminho de volta (codinome Trípoli, na época). Você está fazendo lembrar "master merges" e "shadow merge" e todos os tipos de pequenos detalhes do antigo "Microsoft Index Server" que eu pensei que tinha esquecido ... > smile < Fico triste com o fato de a Microsoft não ter feito mais esforços como produto, porque poderia facilmente ter sido a base de um sistema de busca distribuída para empresas. Oh, bem ... caminhos não tomados, suponho.

Editar:

Você está em um território de escala em que nunca usei o Serviço de indexação antes. Vários catálogos (ou até mesmo várias instâncias do Serviço de Indexação em várias caixas) são provavelmente o seu próximo local para quando o perf sofre. Espero que você não precise ir até lá.

Não tenho certeza de como "sabe" "entrar em pânico" quando as ações fracassam, e ouso dizer que seria necessário analisar a fonte para descobrir o motivo. Isso soa como um daqueles "Doutor, dói quando eu faço isso". "Bem, não faça isso." tipo de coisas. Para esse fim, seu plano é: lidar com o failover de compartilhamentos é provavelmente um bom exemplo.

30% ou menos da relação entre índice e índice é definitivamente melhor do que a Microsoft sempre disse para planejar, no passado. Parece que os arquivos que você está indexando, sendo principalmente texto, não têm a sobrecarga de propriedades do OLE armazenadas em cache como documentos do Office (que, acredito, são a base da Microsoft para a regra geral de 40%). (Como um aparte, você pode ter seus filtros de código devs para esses vários tipos de arquivos e obter a capacidade de fazer buscas específicas de propriedade, se você estiver inclinado. Mostre-me todos os e-mails de xxxx, etc ... heh heh. irá, naturalmente, aumentar o cache de propriedades.)

Os mais de 500 arquivos do catálogo finalmente foram limpos e mesclados, não foram?

O que faz quando "entra em pânico", afinal? Ele simplesmente para "ver" novos documentos e indexá-los?

    

Answer 2

Gostaria de saber se "tudo" ( link ) poderia substituir o serviço de indexação (que eu encontrei com muita frequência problemática. Tudo é uma delícia de usar, embora faça algo diferente da indexação.