Ricerca veloce per SharePoint 2010: Lotti Tempo

Question

La mia organizzazione è stata tentando di utilizzare rapidamente ricerca di SharePoint 2010 come soluzione di ricerca per il nostro DMS. Attualmente sto utilizzando un connettore di indicizzazione .NET per indicizzare un database di ~ 8 milioni di record e i loro file di accompagnamento.

In precedenza, stavo avendo un problema di memoria sulla scatola di crawl, che includeva i crawl incrementali che non sono in grado di completare. Dopo mesi di risoluzione dei problemi, tale problema sembrava essere risolto con un hotfix ( http://support.microsoft.com/ KB / 2601211 ). L'intero problema è illustrato in un altro thread ( http://goo.gl/3cuzuy ).

Tuttavia, sul seguente incrementale, ho iniziato a ricevere nuovi avvertimenti per quanto riguarda i timeout del lotto nei registri e una porta di crawl atroce (0,1 DPS). Ciò ha anche causato il completamento dei crawls di non essere in grado di completare, anche dopo aver funzionato per centinaia di ore. Ancora una volta, sono in perdita.

Ho lavorato con un rappresentante di supporto Microsoft per oltre due mesi, ma non sono stati in grado di offrire assistenza per nessuno dei nostri problemi. Ho anche monitorato i contatori delle prestazioni su entrambi i server per un po 'di tempo, e (diverso da un numero di alto "lotti pronto" sulla scatola di crawl) Devo ancora trovare una pistola fumante. Quindi, qualsiasi suggerimento sarebbe molto apprezzato.

Informazioni per l'ambiente e il registro dettagliate di seguito:

SharePoint Environment

.
• 1x wfe
• Server database 1x
• Server applicazioni 1x (RAM 32 GB)
• 1X Index Server (Veloce) (RAM 16 GB, 8 CPU Cores, 5 Processori di documenti)

Registri

====== [Fast Box] ======

DocLog

.
• Avvertenza Conversione documento fallita: Timeout del processo esterno raggiunto (300 secondi) (codice di avviso 0)
• Processore informazioni "IFILTERCONVERTER" RAN per 300S

Statistiche PSCTRL

.
• IFILTERCONVERTER (tempo di sistema) 229.6 (tempo utente) 2670.5 (tempo reale) 778625.3

====== [Crawl Box] ======

uls

.
• Timeout mentre si alimenta il lotto con 1 documenti dopo 60.0. Tentativo 2 volte: impossibile inviare il contenuto: il set di funzionamento è scaduto [DOCUSTOSUBMITTIPOWORKERTHREAD.CPP: 492] D: \ Office \ sorgente \ Search \ Native \ Gather \ Plugin \ Contentpi \ DOCUDESUBMITTIPERWORKERHREAD.CPP
• Eccezione del contenuto dopo 151.8s: impossibile inviare il contenuto: WinHttPreceveSponse non è riuscito. URL: 'http:// [server veloce]: 13391 / elaborazione :: sessione / 5.2 / 1406916153000000043 / Processo' ERRORE: '12002'
• lotto è scaduto. Aspettando 300 secondi prima di riprovare [DOCUSTOSUBMitterWorkerThread.cpp: 521] D: \ Office \ sorgente \ Search \ Native \ Gather \ Plugin \ Contentpi \ DOCUDESUBMITTIPERWORKERHREAD.CPP

Answer 1

Abbiamo avuto un problema simile con Veloce e abbiamo aperto anche un caso di supporto.Stavamo indicizzando 7 TB di dati per un totale di circa 3 milioni di articoli.Hanno detto che il disco IO è stato il nostro problema principale che ha causato i tempi, quindi abbiamo dovuto ordinare nuovi server veloci.Abbiamo finito per andare con:

.
• 96 GB di RAM
• 2 x 6 Core Xeon CPU
• 8 x 300 GB HD - 2 mirroring per OS, e altri 6 in un RAID 50 per un po 'di oltre 1 TB di spazio per l'indice

Ne abbiamo ottenuto due di quelli per costruire la nostra Fascia Fattoria e una volta che li abbiamo messa in atto non abbiamo avuto problemi di timeout con velocemente.

Con i nuovi server abbiamo aumentato i nostri processori di documenti a 24 e quando abbiamo fatto il nostro pieno indicizzazione nei fine settimana ci vorrebbe un po 'più di 24 ore per completare.

Sfortunatamente, con veloce, sembra che la risposta migliore sia quella di lanciare più hardware.