Búsqueda rápida de SharePoint 2010: Lotes de salida

Question

Mi organización ha estado tratando de usar una búsqueda rápida de SharePoint 2010 como una solución de búsqueda para nuestros DMS. Actualmente estoy utilizando un conector de indexación .NET para indexar una base de datos de ~ 8 millones de registros y sus archivos de acompañamiento.

Anteriormente, estaba teniendo un problema de memoria en la caja de rastreo, que incluía los rastreros incrementales que no podían completar. Después de meses de solución de problemas, ese problema parecía resolverse con un hotfix ( http://support.microsoft.com/ KB / 2601211 ). Todo el problema se ilustra en otro hilo ( http://goo.gl/3cuzuy ).

Sin embargo, en el siguiente incremental, comencé a recibir nuevas advertencias con respecto a los tiempos de tiempo de lotes en los registros y una tarifa de rastreo atroz (0,1 DPS). Esto también ha causado que los rastreros no puedan completar, incluso después de correr durante cientos de horas. Una vez más, estoy en una pérdida.

He estado trabajando con un representante de soporte de Microsoft durante más de dos meses, pero no han podido ofrecer asistencia para ninguno de nuestros problemas. También he estado monitoreando los contadores de rendimiento en ambos servidores durante bastante tiempo, y (además de un número de altos listones 'listo' en la caja de rastreo) Aún no he encontrado una pistola humeante. Por lo tanto, cualquier sugerencia sería muy apreciada.

Información ambiental y de registro detallada a continuación:

entorno de SharePoint

• 1x wfe
• 1x servidor de base de datos
• 1x servidor de aplicaciones (32GB RAM)
• 1x Server (RAM) (RAM de 16 GB, 8 núcleos de CPU, 5 procesadores de documentos)

logs

====== [caja rápida] ======

dclog

• Falló la conversión de documentos de advertencia: Tiempo de espera de proceso externo alcanzado (300 segundos) (código de advertencia 0)
• Procesador de información "IFILTERCONVERTER" RAN para 300S

psctrl estadística

• ifilterconverter (tiempo del sistema) 229.6 (tiempo de usuario) 2670.5 (tiempo real) 778625.3

====== [caja de rastreo] ======

uls

• tiempo de espera mientras alimenta lote con 1 documentos después de 60.0s. Intento 2 veces: No se pudo enviar contenido: Operación se estableció distribuida
  [DocumentSubmitworkErthread.CPP: 492] D: \ Office \ Source \ Search \ nativo \ recopilación \ plugins \ contentpi \ documentsubmittterworkerthread.cpp
• Excepción de contenido después de 151.8s: No se pudo enviar contenido: WinhttPreceiveresponse falló. URL: 'http:// [Fast Server]: 13391 / Procesando :: Sesión / 5.2 / 1406916153000000043 / Proceso' Error: '12002'
• lote cronometrado. Esperando 300 segundos antes de volver a intentarlo [DocumentSubmitworkErthread.CPP: 521] D: \ Office \ Source \ Search \ nativo \ recopilación \ plugins \ contentpi \ documentsubmittterworkerthread.cpp

Answer 1

Tuvimos un problema similar con rápido y también abrimos un caso de soporte.Estábamos indexando 7 tb valor de datos por un total de alrededor de 3 millones de artículos.Dijeron que el disco IO era nuestro principal problema, lo que provocó que el tiempo fuera, así que tuvimos que pedir nuevos servidores rápidos.Terminamos yendo con:

• 96 GB de RAM
• 2 x 6 núcleo Xeon CPUS
• 8 x 300 GB HD - 2 reflejados para OS, y otros 6 en una RAID 50 por un poco más de 1 TB de espacio para el índice

Tenemos dos de aquellos para construir nuestra granja rápida y una vez que los ponemos en su lugar, no hemos tenido problemas de tiempo de espera con ayuno.

Con los nuevos servidores, aumentamos nuestros procesadores de documentos a 24 y cuando hicimos nuestra indexación completa a lo largo de los fines de semana, tomaría un poco más de 24 horas en completarse.

Desafortunadamente, con rápido, parece que la mejor respuesta es lanzar más hardware.