Pesquisa rápida pelo SharePoint 2010: lotes expirando

Question

Minha organização tem tentado usar pesquisa rápida para o SharePoint 2010 como uma solução de pesquisa para o nosso DMS. Estou atualmente utilizando um conector de indexação .NET para indexar um banco de dados de ~ 8 milhões de registros e seus arquivos de acompanhamento.

Anteriormente, eu estava tendo um problema de memória na caixa de rastreamento, que incluiu os crawls incrementais não conseguirem concluir. Depois de meses de solução de problemas, esse problema parecia ser resolvido com um hotfix ( http://support.microsoft.com/ kb / 2601211 ). Todo o problema é ilustrado em outro segmento ( http://goo.gl/3cuzuy ).

No entanto, no seguinte incremental, comecei a receber novos avisos em relação aos intervalos de lotos nos troncos e uma taxa de rastreamento atroz (0,1 DPS). Isso também fez com que os rastejantes fossem incapazes de concluir, mesmo depois de correr por centenas de horas. Mais uma vez, estou perdida.

Eu tenho trabalhado com um representante de suporte da Microsoft por mais de dois meses, mas eles não conseguiram oferecer assistência para qualquer um dos nossos problemas. Também estive monitorando os contadores de desempenho em ambos os servidores por algum tempo, e (além de um número alto 'lotes prontos' na caixa de rastreamento) Eu ainda tenho que encontrar uma arma fumegante. Assim, qualquer sugestão seria muito apreciada.

Informações ambientais e de log detalhadas abaixo:

ambiente do SharePoint

• 1x wfe
• 1x servidor de banco de dados
• 1x servidor de aplicativos (32GB RAM)
• 1x Index Server (Rápido) (16 GB RAM, 8 núcleos da CPU, 5 processadores de documentos)

logs

====== [Caixa rápida] ======

doclog

• AVISO A conversão do documento falhou: Tempo limite de processo externo (300 segundos) (código de aviso 0)
• info processador "ifilterconverter" correu por 300s

estatísticas psctrl

• ifilterconverter (horário do sistema) 229.6 (tempo do usuário) 2670.5 (Tempo real) 778625.3

====== [Caixa de rastreamento] ======

uls

• tempo limite ao alimentar lote com 1 docs após 60.0s. Tentativa de 2 vezes: não pôde enviar conteúdo: Operação definida no final do tempo [Documentsubmitterworkerthread.cpp: 492] D: \ Office \ Source \ Search \ Native \ Reunir \ Plugins \ ContentPi \ DocumentaBmitterWorkerthread.cpp
• Exceção de conteúdo após 151.8s: não pôde enviar conteúdo: WinhttpreceiverSponse falhou. URL: 'http:// [servidor rápido]: 13391 / processamento :: sessão / 5.2 / 1406916153000000043 / processo' erro: '12002'
• lotes expirou. Esperando 300 segundos antes de tentar novamente [Documentsubmitterworkerthread.cpp: 521] D: \ Office \ Source \ Search \ Native \ Reunir \ Plugins \ ContentPi \ Documentsubmitterworkerthread.cpp

Answer 1

Tivemos um problema semelhante com rápido e abrimos um caso de suporte também.Nós estávamos indexando 7 tb no valor de dados totalizando cerca de 3 milhões de itens.Eles disseram que o disco io era nossa questão importante causando o tempo de saída, então tivemos que pedir novos servidores rápidos.Acabamos indo com:

• 96 GB de RAM
• 2 x 6 Core Xeon CPUs
• 8 x 300 GB HD - 2 espelhado para o OS, e outros 6 em um RAID 50 por um pouco mais de 1 TB de espaço para o índice

Nós temos dois daqueles para construir nossa fazenda rápida e uma vez que os colocamos em vigor, não tivemos nenhum problema de tempo em rápido.

Com os novos servidores aumentamos nossos processadores de documentos para 24 e quando fizemos a nossa indexação completa nos fins de semana, levaria um pouco mais de 24 horas para concluir.

Infelizmente, com rápido, parece que a melhor resposta é jogar mais hardware nisso.