Procedimientos recomendados para el rendimiento de la búsqueda (Office SharePoint Server 2007)
En este artículo se describen algunos de los procedimientos recomendados que se pueden usar para mantener un sistema de búsqueda eficaz y con un mantenimiento correcto en Microsoft Office SharePoint Server 2007.
En este artículo:
Razones para iniciar un rastreo completo
Supervisión de servidores web
Supervisión de servidores de bases de datos
Supervisión de servidores de índice
Supervisión de Office SharePoint Server con la herramienta de diagnóstico de SharePoint
Uso de registros del Servicio de creación de registros unificado para diagnosticar cuellos de botella de consultas
Optimización de SQL Server para la búsqueda en Office SharePoint Server 2007
Mantenimiento de bases de datos de SQL Server para la búsqueda
Cómo evitar el colapso del rastreador
Cómo evitar cuellos de botella provocados por listas de control de acceso
Solución de problemas para la falta de elementos web de cuadro de búsqueda
Razones para iniciar un rastreo completo
El rastreo y la indización de grandes volúmenes de información, documentos y páginas web requieren una gran cantidad de procesamiento por parte de los equipos. El proceso de rastreo también consume recursos de red y de otros tipos. Debe configurar un conjunto o granja de servidores de Office SharePoint Server 2007 para garantizar que el proceso de rastreo e indización no afecte de forma negativa al servicio disponible para los usuarios. Por ejemplo, se suele rastrear e indizar el contenido fuera de las horas de mayor actividad (períodos de uso mínimo de los servidores) para mantener los servicios en las horas punta para los usuarios.
Una forma de reducir el impacto del rastreo es programar rastreos incrementales en lugar de rastreos completos. Dado que los rastreos incrementales indizan solo los elementos modificados, el proceso requiere muchos menos recursos de los equipos. Puede programar rastreos completos e incrementales en cada origen de contenido. Por ejemplo, puede considerar la posibilidad de ejecutar rastreos incrementales a medianoche durante los días de la semana y rastreos completos a medianoche los sábados.
Nota
Para obtener más información acerca de cómo planear programaciones de rastreo, vea Planeación del rastreo de contenido (Office SharePoint Server)
Para asegurarse de que el índice se haya completado, debe iniciar manualmente un rastreo completo en los siguientes casos:
Cuando los administradores hayan aplicado una actualización o un Service Pack a los servidores de la granja.
Cuando los administradores hayan agregado una nueva propiedad administrada a la configuración de búsqueda.
Cuando los administradores hayan agregado o modificado una regla de rastreo.
Cuando desee volver a indizar páginas de ASP.NET en sitios de Windows SharePoint Services 3.0, Microsoft Office SharePoint Server 2007 o Search Server 2008. El rastreador no puede detectar cuando se modifican esas páginas web. Por lo tanto, solo se volverán a indizar con un rastreo completo.
Cuando se generen errores consecutivos en los rastreos incrementales. Si un rastreo incremental genera un error cientos de veces seguidas en cualquier nivel de un repositorio, el servidor de índice quita el contenido afectado del índice.
Cuando los administradores hayan reparado un índice dañado.
Cuando un administrador haya creado una asignación de nombre de servidor.
Cuando haya modificado los permisos para determinado contenido y dicho contenido no se haya modificado, y no haya aplicado la revisión posterior a Service Pack 1 (KB941442) o un Service Pack posterior en los servidores. Sin esta revisión, los rastreos incrementales no controlan las listas de control de acceso (ACL). Si no se controlan las ACL, es posible que un usuario vea un elemento en los resultados de la búsqueda aunque un administrador haya eliminado el permiso para dicho usuario desde el último rastreo completo.
En los siguientes casos, Office SharePoint Server 2007 realiza un rastreo completo cuando se haya programado o iniciado manualmente un rastreo incremental:
Cuando un administrador haya detenido manualmente el rastreo anterior.
Cuando un administrador haya restaurado una base de datos de contenido a partir de una copia de seguridad.
Nota
Si se ha instalado la Actualización de infraestructura para servidores de Microsoft Office, puede especificar si una operación de restauración genera un rastreo completo mediante las opciones de la herramienta de línea de comandos Stsadm.
Cuando un administrador de granja de servidores haya separado y vuelto a adjuntar una base de datos de contenido.
Cuando Office SharePoint Server no haya ejecutado nunca un rastreo completo del contenido.
Cuando el registro de cambios no contenga información sobre las direcciones en el rastreo. El registro de cambios se usa para determinar si se ha modificado un elemento desde el último rastreo. Sin la información del registro de cambios, no se pueden realizar rastreos incrementales.
Cuando haya cambiado la cuenta de acceso al contenido. Esta cuenta puede ser la cuenta de acceso predeterminada o una cuenta especificada en una regla de rastreo.
Cuando se haya dañado un índice.
Debe considerar cuidadosamente sus acciones en estas circunstancias. Esto se debe a que si inicia un rastreo manualmente o mediante una programación, el rastreo completo puede requerir muchos más recursos de los que habría requerido el rastreo incremental. Esto podría afectar al servicio que reciben los usuarios.
Supervisión de servidores web
Par maximizar el rendimiento de búsqueda de Office SharePoint Server 2007, analice rigurosamente el sistema. Debe crear una línea de base mediante una investigación exhaustiva de los servidores. Además, periódicamente debe volver a ejecutar pruebas de rendimiento para observar posibles cambios y diagnosticar los problemas oportunamente. Al realizar una optimización, puede utilizar la línea de base para caracterizar las mejoras obtenidas. Las secciones siguientes enumeran los contadores de supervisión del rendimiento y los datos disponibles de otras herramientas que son pertinentes para el rendimiento de Office SharePoint Server 2007.
Nota
Para obtener más información acerca de la supervisión general del sistema, vea el tema sobre la supervisión del rendimiento (https://go.microsoft.com/fwlink/?linkid=105584&clcid=0xC0A).
En Office SharePoint Server 2007, los servidores web hospedan todos los sitios y todas las colecciones de sitios. Obtienen el contenido que se almacena en los servidores de bases de datos y responden a las solicitudes de los usuarios. Debido a que los servidores web envían respuestas a las consultas de búsqueda de los usuarios, su rendimiento tiene un efecto directo en el rendimiento de la búsqueda. Los servidores web también afectan a la indización porque el rastreador indiza el contenido de Office SharePoint Server mediante el envío de solicitudes a los servidores web.
Para supervisar el estado de los servidores web, use los siguientes contadores de supervisión de rendimiento:
Procesador/% de tiempo de procesador/_Total
Este contador es el principal indicador de la actividad de los procesadores. Mide la proporción de tiempo que tardan los procesadores en ejecutar subprocesos activos. Si este contador promedia un valor superior al 80 % durante períodos prolongados, los procesadores pueden ser un cuello de botella y se debe considerar una actualización.
Memoria/Mbytes disponibles
Este contador mide la memoria física disponible de inmediato para procesos o para el sistema. Si el valor del contador es demasiado bajo, el sistema se ralentiza, ya que usa más paginación. Debe considerar la posibilidad de agregar más memoria al servidor.
Servicio web/Conexiones actuales
Este contador mide el número de conexiones al servicio World Wide Web. En los servidores web de Office SharePoint Server 2007, este recuento incluye todos los usuarios simultáneos y, durante la indización, el rastreador. Use este contador para crear perfiles de patrones de uso y determinar las horas de mayor actividad. No hay ningún límite para este contador. Los valores muy altos indican un rendimiento excelente.
Nota
En una granja de servidores de Office SharePoint Server con varios servidores web, este contador mide las conexiones en un solo servidor. Para obtener información acerca de cómo supervisar la actividad de usuario en toda la granja de servidores, vea el tema sobre Supervisión de Office SharePoint Server con la herramienta de diagnóstico de SharePoint.
Supervisión de servidores de bases de datos
Office SharePoint Server 2007 usa Microsoft SQL Server 2005 o Microsoft SQL Server 2008 para almacenar bases de datos de contenido. Aunque el servidor de índice almacena el índice de contenido en el sistema de archivos (no en una base de datos), almacena metadatos de documentos y permisos en la base de datos de búsqueda. Dado que muchas búsquedas comprueban metadatos y todas las búsquedas implican recortes de seguridad, el rendimiento de los servidores de bases de datos afecta directamente al rendimiento de la búsqueda.
Para supervisar el estado de los servidores de bases de datos, use los siguientes contadores de supervisión del rendimiento:
Procesador/% de tiempo de procesador/_Total
Este contador es el indicador principal de la actividad del procesador y, por lo tanto, es importante tanto en los servidores de bases de datos como en los servidores web.
**Disco lógico/% de tiempo de disco/**NombreDeDisco
Este contador mide la proporción de tiempo transcurrido mientras el disco atiende las solicitudes de lectura o escritura. Para la búsqueda, supervise este contador para el disco que contiene la base de datos de búsqueda. Si este contador promedia con frecuencia un valor superior al 90%, el disco puede representar un cuello de botella para la búsqueda.
Sistema: Longitud de cola del procesador
El promedio de este contador debe ser menor que el doble del número de núcleos de CPU del servidor.
Memoria: Mbytes disponibles
Asegúrese de que el promedio de este contador sea como mínimo un 20% del total de la memoria RAM física.
Memoria: Páginas/s
El promedio de este contador debe ser menor que 100.
Disco lógico: Transferencias de disco/s
Este contador mide el rendimiento general de una partición.
Disco lógico: Bytes de lectura de disco/s y Bytes de escritura en disco/s
Este contador mide el ancho de banda total de un disco concreto.
Disco lógico: Promedio de segundos de disco/lectura
Este contador indica el tiempo que tarda el disco en recuperar datos, lo que se llama también latencia de lectura. Es importante que la latencia de lectura sea baja para una respuesta correcta a las consultas de los usuarios.
Disco lógico: Promedio de segundos de disco/escritura
Este contador indica el tiempo que tarda el disco en escribir datos, lo que se llama también latencia de escritura. Una latencia de escritura baja aumenta el rendimiento de la indización.
**Disco lógico/% de tiempo de lectura de disco/**NombreDeDisco
Este contador mide la proporción de tiempo transcurrido mientras el disco atiende las solicitudes de lectura. Una proporción alta de solicitudes de lectura del disco de la base de datos de búsqueda puede indicar que los usuarios ejecutan un número considerable de búsquedas.
**Disco lógico/% de tiempo de escritura en disco/**NombreDeDisco
Este contador mide la proporción de tiempo transcurrido mientras el disco atiende las solicitudes de escritura. Durante el proceso de indización, se espera una proporción alta de solicitudes de escritura para la base de datos de búsqueda.
Nota
Cuando sea posible, coloque la base de datos de búsqueda en un disco independiente de las demás bases de datos para optimizar el rendimiento de la búsqueda. Si se separa la base de datos de búsqueda de esta forma, estos contadores de discos lógicos pueden proporcionar un diagnóstico correcto del rendimiento de la búsqueda porque el disco sólo se dedica a la búsqueda.
SQLServer: Administrador de búfer/Duración prevista de la página
Este contador mide el número de segundos que una página de base de datos permanece en el grupo de búferes sin referencias. Debe mantenerse en un valor superior a 300 segundos. Con valores inferiores a 300 segundos se puede diagnosticar muy probablemente la presencia de un cuello de botella de memoria y, ante esta situación, se debe considerar agregar memoria al servidor..
Nota
Una descripción detallada de la optimización general de SQL Server está fuera del ámbito de este artículo sobre Office SharePoint Server. Para obtener más información, vea los siguientes recursos:
-
Los diez procedimientos recomendados principales para el almacenamiento (en inglés) (https://go.microsoft.com/fwlink/?linkid=148543&clcid=0xC0A) (en inglés)
-
Procedimientos recomendados para E/S previos a la implementación de SQL Server (en inglés) (https://go.microsoft.com/fwlink/?linkid=148544&clcid=0xC0A) (en inglés)
-
Niveles de RAID y SQL Server (https://go.microsoft.com/fwlink/?linkid=105581&clcid=0xC0A)
-
Para obtener más información acerca de los contadores de supervisión del rendimiento de Microsoft SQL Server y Productos y Tecnologías de SharePoint, vea las notas del producto sobre recomendaciones de rendimiento y procedimientos recomendados para la planeación y supervisión de almacenamiento de SQL Server para Office SharePoint Server (https://go.microsoft.com/fwlink/?linkid=119398&clcid=0xC0A).
Supervisión de servidores de índice
En Office SharePoint Server 2007, los servidores de índice rastrean el contenido y crean un archivo de índice. Cuando se completa el proceso de rastreo, el índice se propaga a los servidores de consultas que responden a las solicitudes de búsqueda de los usuarios.
Si el rendimiento del servidor de índice es bajo, es posible que esto no afecte directamente a los usuarios. Sin embargo, en ocasiones se prolonga el proceso de rastreo hasta un punto en el que no se puede limitar el rastreo fuera de las horas de mayor actividad ni separar el rastreo de otras actividades realizadas en las horas de menor actividad, como las copias de seguridad.
Nota
Es posible que el servidor de índice no pueda incluirse en un servidor independiente según el número de servidores disponibles.
Para supervisar el estado del servidor de índice, use los siguientes contadores de supervisión del rendimiento durante el rastreo:
Complemento de archivado de Office Server Search/Total de documentos en la primera cola/Contenido_del_portal
Este contador mide el número de documentos de la primera cola del complemento de archivado. Debe ser menor que 500 durante un rastreo y muy bajo en otros momentos. Si el contador es superior a 500, es probable que se produzca un cuello de botella en la unidad de la base de datos de búsqueda del servidor de bases de datos.
Complemento de archivado de Office Server Search/Total de documentos en la segunda cola/Contenido_del_portal
Este contador mide el número de documentos de la segunda cola del complemento de archivado. Al igual que en el contador anterior, debe ser menor que 500 durante un rastreo.
Recopilador de Office Server Search/Subprocesos inactivos
Este contador mide el número de subprocesos en el proceso del recopilador que esperan documentos. Si el contador es 0, se colapsan los recursos del recopilador. Considere la posibilidad de reducir el número de rastreos simultáneos.
Recopilador de Office Server Search/Subprocesos con acceso a la red
Este contador mide el número de subprocesos del proceso del recopilador que enviaron solicitudes a un almacén de datos remoto y esperan la respuesta o la están procesando. Si este contador tiene normalmente un valor alto, se puede producir un cuello de botella en el ancho de banda de red o el servidor de índice puede estar conectado a uno o más hosts lentos para indizar el contenido.
Recopilador de Office Server Search/Subprocesos de filtrado
Este contador mide el número de subprocesos que han recuperado contenido y lo están filtrando. Si este número es alto, puede indicar que los recursos del servidor de índice actúan como cuellos de botella.
Recopilador de Office Server Search/Subprocesos en complementos
Este contador mide el número de subprocesos que han recuperado contenido y lo están procesando mediante complementos como IFilters. Es la etapa del proceso de rastreo en la que se rellenan la base de datos de búsqueda y el índice.
Proyectos del recopilador de Office Server Search/Rastreos en curso
Este contador mide el número de rastreos en curso. Este valor debe coincidir con el número de orígenes de contenido que tienen rastreos programados excepto si un administrador ha iniciado un rastreo de forma manual.
Supervisión de Office SharePoint Server con la herramienta de diagnóstico de SharePoint
La herramienta de diagnóstico de SharePoint (v1.0) (llamada también SPDiag) es una herramienta avanzada de diagnóstico y análisis que presenta una amplia variedad de información sobre cualquier servidor o granja de servidores que ejecute Productos y Tecnologías de SharePoint. Puede usar SPDiag para ver instantáneas detalladas de las configuraciones del servidor y la granja. Además, permite combinar y ver información de Internet Information Services (IIS), registros del Servicio de creación de registros unificado (ULS) y registros de eventos, así como investigar problemas de rendimiento, como las solicitudes lentas.
Nota
SPDiag forma parte del Kit de herramientas administrativas de SharePoint de Microsoft v3.0 (en inglés) (https://go.microsoft.com/fwlink/?linkid=141504&clcid=0xC0A) (en inglés).
SPDiag puede generar gráficos de contadores de rendimiento de cualquier servidor de la granja. Sin embargo, también incluye varios contadores que miden datos de toda la granja según los registros de IIS. No es posible realizar un análisis tan completo de toda la granja solo con el monitor de rendimiento.
Nota
Para usar SPDiag de forma eficaz, debe leer la guía del usuario de la herramienta de diagnósticos de SharePoint (SPDiag) (en inglés) (https://go.microsoft.com/fwlink/?linkid=141204&clcid=0xC0A) (en inglés).
Use los siguientes contadores en toda la granja para investigar la capacidad de respuesta de la granja de Office SharePoint Server 2007:
Solicitudes de SharePoint/Número de IP de cliente única
Este contador mide el número de clientes únicos que realizaron solicitudes en el período especificado. Tenga en cuenta que los clientes que obtienen acceso a la granja mediante un servidor proxy aparecen como una dirección IP única.
Solicitudes de SharePoint/Número de agentes cliente únicos
Este contador mide el número de agentes de cliente únicos (exploradores) que realizaron solicitudes en el período especificado. Este contador puede diferenciar entre clientes que obtienen acceso a la granja mediante un servidor proxy porque está basado en el agente especificado en las solicitudes HTTP de los exploradores.
Nota
Los siguientes contadores miden el número de solicitudes. Estas solicitudes incluyen solicitudes y consultas de búsqueda de contenido.
Solicitudes de SharePoint/Total de solicitudes
Este contador mide el número total de solicitudes y sus variaciones en el período especificado. Siempre debe supervisar este contador junto con los siguientes contadores para determinar la proporción de solicitudes rápidas y lentas.
Solicitudes de SharePoint/Número de solicitudes con tiempo consumido < 1 segundo
Este contador mide el número de solicitudes respondidas en 1 segundo. En una granja de servidores con buen rendimiento, se aproxima al contador del Total de solicitudes.
Solicitudes de SharePoint/Número de solicitudes con tiempo consumido: 1-5 segundos
Este contador mide el número de solicitudes respondidas en un período de 1 a 5 segundos. Este rendimiento suele ser aceptable para los usuarios, pero una proporción mayor de estas solicitudes con el tiempo puede indicar que se está produciendo un cuello de botella.
Solicitudes de SharePoint/Número de solicitudes con tiempo consumido: 5-10 segundos
Este contador mide el número de solicitudes respondidas en un período de 5 a 10 segundos. Es posible que los usuarios abandonen la página antes de que se muestren los resultados.
Solicitudes de SharePoint/Número de solicitudes con tiempo consumido > 10 segundos
Este contador mide el número de solicitudes respondidas en más de 10 segundos. Si estas solicitudes son una proporción significativa del Total de solicitudes, la granja de servidores no responde y debe investigar si hay cuellos de botella y considerar la la posibilidad de actualizar el hardware.
Uso de registros del Servicio de creación de registros unificado para diagnosticar cuellos de botella de consultas
Puede usar el Servicio de creación de registros unificado (ULS) para supervisar y optimizar el rendimiento del sistema Office SharePoint Server 2007. Debe usar ULS como un método para optimizar el sistema. Otro método es el uso del monitor de rendimiento, registros de eventos y registros web.
En esta sección, verá cómo utilizar los registros de ULS para diagnosticar retrasos en el rendimiento de las búsquedas. Mediante los registros de ULS, puede diagnosticar las etapas del proceso de búsqueda que consumen más tiempo y retrasan la devolución de resultados a los usuarios. También debe utilizar los registros de ULS para evaluar las mejoras de rendimiento realizadas por pequeños cambios en la configuración del sistema.
Nota
No use el registro de ULS con frecuencia para evitar efectos negativos en el rendimiento y el uso del espacio en disco. Después de diagnosticar problemas de rendimiento con ULS, puede maximizar el rendimiento si deshabilita los registros de ULS. Procure almacenar los registros de ULS en un disco que tenga mucho espacio.
Nota
Para obtener más información y ejemplos adicionales de las consultas que puede usar en Log Parser 2.2, vea el artículo sobre la identificación de la latencia de consulta en los registros de ULS (en inglés) (https://go.microsoft.com/fwlink/?linkid=148540&clcid=0xC0A) (en inglés) en el blog sobre Microsoft Enterprise Search.
Configuración del Servicio de creación de registros unificado
Empiece por la configuración de ULS en el sitio web de Administración central de Office SharePoint Server 2007.
Importante
Para completar este procedimiento, es necesario pertenecer al grupo Administradores de la granja.
Para configurar el Servicio de creación de registros unificado para diagnosticar problemas de rendimiento de búsqueda
Haga clic en Inicio, seleccione Todos los programas, elija Microsoft Office Server y, a continuación, haga clic en Administración central de SharePoint 3.0.
Haga clic en la ficha Operaciones.
En la sección Crear registros e informes, haga clic en Registro de diagnóstico.
En la lista Seleccionar una categoría de la sección Límite de eventos, haga clic en Procesador de consultas de búsqueda de MS.
En Evento menos crítico que desea incorporar al registro de seguimiento, haga clic en Alto.
En la parte inferior de la página, haga clic en Aceptar.
Uso de la herramienta Log Parser
Al igual que los registros de Internet Information Services (IIS), los registros de ULS de Office SharePoint Server 2007 son archivos de texto de gran tamaño. Para analizar el contenido de estos archivos, use una utilidad de análisis de registros para centrarse en los seguimientos interesantes y aplicar formato a los datos. La herramienta Microsoft Log Parser 2.2 (en inglés) (https://go.microsoft.com/fwlink/?linkid=148542&clcid=0xC0A) (en inglés) es gratuita y la solución ideal para este fin.
La herramienta Log Parser es un programa de línea de comandos. Debe usar los siguientes parámetros para indicar que los registros de ULS son archivos de texto separados por tabulaciones con codificación Unicode:
logparser -i:TSV -iCodepage:-1 -fixedSep:ON
Además de estos parámetros, debe proporcionar una consulta de tipo Transact-SQL que indique a Log Parser cómo analizar el archivo de registro. Por ejemplo, para concentrarse en los mensajes del temporizador del procesador de consultas, use la siguiente cláusula WHERE:
WHERE Category = 'MS Search Query Processor' AND Message LIKE '%Completed query execution with timings:%'
Nota
Puede escribir el texto de una consulta SQL directamente en el símbolo de sistema de Log Parser. Además, puede guardar la consulta en un archivo de texto y usar el parámetro file: para indicar su ubicación a Log Parser. Esto resulta útil para consultas largas o complejas y para consultas que se usarán con frecuencia.
Búsqueda de mensajes en los registros de ULS
Cuando ULS está configurado como se describió anteriormente, aparecen los mensajes siguientes en los archivos de registro cuando los usuarios ejecutan consultas:
Se completó la ejecución de consultas con control de tiempos
Este mensaje indica que se ha completado una consulta e incluye seis controles de tiempo que describen la consulta en milisegundos. Los seis controles de tiempo son los siguientes:
v1. El tiempo total que tarda en procesarse la consulta.
v2. La latencia de la consulta medida después de la detección de un duplicado.
v3. La latencia de la consulta medida después de un recorte de seguridad.
v4. La latencia de la consulta medida después de combinar resultados del índice con resultados de la base de datos de búsqueda.
v5. El tiempo durante el que se esperan resultados del servidor de índice.
v6. El tiempo que se destina a llamadas a la base de datos con exclusión de la captura de las propiedades de la base de datos de búsqueda.
Con estos seis controles de tiempo, puede calcular la siguiente información:
v1 - v2. El tiempo que se tarda en recuperar propiedades y resaltar las referencias.
v2 - v3. El tiempo que se tarda en detectar duplicados.
v3 - v4. El tiempo que tardan los recortes de seguridad.
v4 - v5. El tiempo que se tarda en la combinación de resultados del índice con resultados de la base de datos de búsqueda.
Reintento de combinación
Este mensaje indica que se realizó un reintento porque los resultados que se obtuvieron de la base de datos de búsqueda no coincidieron con los resultados del índice de texto completo y, por lo tanto, no se pudieron combinar.
Reintento de recorte de seguridad
Este mensaje indica que un usuario ejecutó una consulta que devolvió resultados que el usuario no tiene permiso para leer. Se vuelve a intentar la consulta, con una solicitud de un número mayor de resultados hasta que se devuelvan resultados suficientes.
Reintento de eliminación de duplicados aproximados
Este mensaje indica que varios documentos prácticamente idénticos se quitaron de los resultados y el procesador de consultas no obtuvo suficientes resultados para mostrar. Se vuelve a intentar la consulta, con una solicitud de un número mayor de resultados hasta que se devuelvan resultados suficientes.
Análisis de controles de tiempo de consultas
De los mensajes descritos antes en esta sección, el mensaje Se completó la ejecución de consultas con control de tiempos es el que se usa con mayor frecuencia para diagnosticar retrasos en el procesamiento de las consultas. Por ejemplo, si los recortes de seguridad son lentos, el cálculo v3 – v4 será una gran proporción del tiempo de procesamiento total v1.
Para analizar los controles de tiempo, pase la siguiente consulta SQL a la herramienta Log Parser. La herramienta creará un archivo separado por comas con los controles de tiempo de v1 a v6 y sus diferencias.
Select Timestamp,
TO_INT(Extract_token(Message,7, ' ')) as TotalQPTime,
TO_INT(Extract_token(Message,8, ' ')) as v2,
TO_INT(Extract_token(Message,9, ' ')) as v3,
TO_INT(Extract_token(Message,10, ' ')) as v4,
TO_INT(Extract_token(Message,11, ' ')) as TimeSpentInIndex,
TO_INT(Extract_token(Message,12, ' ')) as v6,
SUB(v4, TimeSpentInIndex) as JoinTime,
SUB(v3, v4) as SecurityTrimmingTime,
CASE v2
WHEN 0 THEN 0
ELSE SUB(v2, v3)
End as DuplicateDetectionTime,
SUB(TotalQPTime, v2) as FetchTime
INTO QTiming
FROM 'C:\Program Files\Common Files\microsoft shared\Web Server Extensions\12\LOGS\MOSSServer1*.log'
WHERE Category = 'MS Search Query Processor'
AND Message LIKE '%Completed query execution with timings:%'
Puede importar el archivo CSV resultante en Microsoft Office Excel u otra herramienta de análisis para crear gráficos e informes. Tenga en cuenta que en un sistema ocupado tienen lugar muchas consultas y es posible que tenga que recopilar promedios de muchos resultados para generar un análisis significativo.
Análisis de reintentos
Los datos de tiempo disponibles en el mensaje Se completó la ejecución de consultas con control de tiempos no incluyen ninguna información acerca de reintentos, por ejemplo, reintentos causados por recortes de seguridad. Para analizar cuánto tiempo dedica el procesador de consultas a los reintentos, debe comparar el número total de consultas con el número de reintentos de diferentes tipos.
La siguiente consulta cuenta el número total de consultas ejecutadas:
SELECT count (Message)
FROM 'C:\Program Files\Common Files\microsoft shared\Web Server Extensions\12\LOGS\MOSSServer1*.log'
WHERE Category = 'MS Search Query Processor'
AND Message LIKE '%Completed query execution%'
La siguiente consulta cuenta el número total de reintentos que provocaron los recortes de seguridad:
SELECT count (Message)
FROM 'C:\Program Files\Common Files\microsoft shared\Web Server Extensions\12\LOGS\MOSSServer1*.log'
WHERE Category = 'MS Search Query Processor'
AND Message LIKE '%Security trimming retry%'
La siguiente consulta cuenta el número total de reintentos que provocó la eliminación de un resultado duplicado:
SELECT count (Message)
FROM 'C:\Program Files\Common Files\microsoft shared\Web Server Extensions\12\LOGS\MOSSServer1*.log'
WHERE Category = 'MS Search Query Processor'
AND Message LIKE '%Near duplicate removal retry%'
Use estas consultas para diagnosticar la forma en que los reintentos retrasan los resultados de las consultas. Cuando el número de reintentos es una proporción significativa del número total de consultas, considere la posibilidad de revisar la configuración. Por ejemplo, si solo unos pocos usuarios pueden tener acceso a los documentos de uno de los orígenes de contenido, esto puede aumentar el número de reintentos de recorte de seguridad. Considere la posibilidad de quitar este origen del índice.
Optimización de SQL Server para búsqueda en Office SharePoint Server 2007
Microsoft Office SharePoint Server 2007 usa Microsoft SQL Server para almacenar contenido, información de configuración y propiedades de contenido indizado. Debe optimizar SQL Server para garantizar el rendimiento óptimo de Office SharePoint Server.
Nota
Office SharePoint Server 2007 puede usar bases de datos almacenadas en SQL Server 2008 o SQL Server 2005.
Optimización general de los servidores de SQL Server
Algunas optimizaciones aumentan el rendimiento de SQL Server con independencia del propósito del servidor. Debe asegurarse de disponer de estas optimizaciones para una base de datos de Office SharePoint Server.
Cuando planee e implemente el servidor de bases de datos, tenga en cuenta las siguientes recomendaciones:
Cuando sea posible, ejecute SQL Server en un servidor dedicado o en una granja de servidores.
Escale a varios servidores de bases de datos en una granja de servidores. Generalmente, se recomienda instalar un servidor de bases de datos por cada cuatro servidores web en ejecución a su capacidad máxima.
Use una versión de SQL Server de 64 bits en los equipos junto con sistemas operativos de 64 bits.
Use la cantidad máxima de ejes de discos físicos que el presupuesto de hardware permita.
Use discos de alta velocidad.
Coloque las bases de datos en matrices de discos RAID 1+0 o RAID 1.
Coloque los archivos de registro por separado en un disco físico en el que no se almacenen archivos de datos primarios ni secundarios.
Nota
Una descripción detallada de la optimización general de SQL Server está fuera del ámbito de este artículo sobre Office SharePoint Server. Para obtener más información, vea los siguientes recursos:
-
Los diez procedimientos recomendados principales para el almacenamiento (en inglés) (https://go.microsoft.com/fwlink/?linkid=148543&clcid=0xC0A) (en inglés)
-
Procedimientos recomendados para SQL Server (en inglés) (https://go.microsoft.com/fwlink/?linkid=148544&clcid=0xC0A) (en inglés)
-
Niveles de RAID y SQL Server (https://go.microsoft.com/fwlink/?linkid=105581&clcid=0xC0A)
Optimización de SQL Server para consultas de búsqueda e indización
Una prioridad alta para muchos administradores de Office SharePoint Server 2007 es la optimización de la funcionalidad de rastreo, indización y consultas. El índice de contenido de Office SharePoint Server se almacena en el sistema de archivos fuera de cualquier base de datos de SQL Server. Sin embargo, la base de datos de búsqueda almacena los metadatos de los archivos indizados y de ACL. Como consecuencia, el rendimiento de SQL Server afecta directamente a las dos siguientes operaciones de búsqueda:
Indización. Esto ocurre si Office SharePoint Server almacena metadatos y ACL.
Consultas. Todas las consultas de Office SharePoint Server implican un recorte de seguridad durante el cual Office SharePoint Server comprueba las ACL de la base de datos de búsqueda y quita los resultados que el usuario no tiene permiso para ver. Además, si el usuario ha realizado una búsqueda de propiedades, los metadatos se deben recuperar de la base de datos de búsqueda.
En primer lugar, debe seguir las recomendaciones generales de optimización de SQL Server indicadas anteriormente. Asimismo, las optimizaciones que se enumeran en las siguientes secciones benefician específicamente la funcionalidad de indización y consultas.
Optimización del rendimiento de la base de datos tempdb
Cada consulta de usuario implica actividad en la base de datos tempdb de SQL Server. Por lo tanto, la configuración de esta base de datos afecta directamente a la velocidad con la que se muestran las respuestas a las consultas a los usuarios.
Siga estos pasos para optimizar tempdb:
Establezca el modelo de recuperación en
SIMPLE
.Permita que el tamaño de los archivos de tempdb se incremente automáticamente según sea necesario.
Establezca el incremento del tamaño de los archivos en un valor razonable. Por regla general, el incremento debe ser aproximadamente del 10 por ciento del tamaño de archivo de tempdb.
Asigne espacio previamente para los archivos de tempdb. Para ello, establezca el tamaño de archivo en un valor que pueda incluir toda la actividad durante los rastreos y las consultas.
Use varios archivos de datos para maximizar el ancho de banda del disco. Por regla general, use un archivo de datos por cada núcleo de CPU del equipo que ejecuta SQL Server.
Establezca el mismo tamaño para todos los archivos de datos.
Incluya la base de datos tempdb en un disco físico independiente de los discos en los que se almacenan las bases de datos de contenido, la base de datos de configuración y la base de datos de búsqueda.
Nota
Para obtener más información acerca de la optimización de tempdb, vea el tema sobre la optimización del rendimiento de tempdb (https://go.microsoft.com/fwlink/?linkid=148537&clcid=0xC0A).
Uso de grupos de archivos para aumentar el rendimiento
El proceso de rastreo e indización de Office SharePoint Server 2007 hace un uso intensivo de E/S y escribe un gran volumen de datos en la base de datos de búsqueda. Si el sistema experimenta períodos prolongados de horas de baja actividad, debe programar la indización para que se ejecute durante esas horas a fin de asegurarse de que la indización no compita con las consultas de usuario por los recursos. Sin embargo, en algunas organizaciones con actividades globales o continuas, no hay reducciones significativas en la demanda. Si el servidor de base de datos que hospeda la base de datos de búsqueda está cerca de su limite de capacidad de E/S, considere otros métodos para separar las operaciones de E/S de indización de aquellas asociadas con las consultas de usuario.
La base de datos de búsqueda se puede dividir en tablas implicadas en la indización y tablas implicadas principalmente en las consultas de los usuarios. Al separar estos grupos de tablas en dos discos físicos, se garantiza que la indización tenga el menor efecto posible en el rendimiento de las consultas. Aunque las tablas de indización y consultas se encuentran en una misma base de datos, puede usar la característica de grupos de archivos de Microsoft SQL Server para realizar esta separación.
Para ello, cree un grupo de archivos de usuario con un archivo de datos secundario en él. Este archivo de datos debe estar en un disco físico dedicado para lograr una mejora en el rendimiento. Luego, mueva las tablas que participan en la indización a ese grupo de archivos mediante el procedimiento siguiente. Este procedimiento puede tardar un tiempo considerable, según el tamaño de la base de datos de búsqueda. Por tanto, debe realizar el procedimiento cuando la demanda sea baja.
Nota
Para obtener más información acerca de cómo usar grupos de archivos para la base de datos de búsqueda, incluidas las secuencias de comandos o scripts Transact-SQL para mover tablas, vea el tema sobre grupos de archivos y búsqueda de SQL (en inglés) (https://go.microsoft.com/fwlink/?linkid=132066&clcid=0xC0A) (en inglés).
Para separar las tablas de indización en un grupo de archivos dedicado
En SQL Server Management Studio, haga clic con el botón secundario en la base de datos de búsqueda y, a continuación, haga clic en Propiedades.
En la lista Seleccionar una página, haga clic en Grupos de archivos.
Haga clic en Agregar y asigne el nombre “CrawlFileGroup” al grupo de archivos nuevo.
En la lista Seleccionar una página, haga clic en Archivos.
Haga clic en Agregar y asígnele un nombre al nuevo archivo.
En la celda Grupos de archivos, seleccione CrawlFileGroup.
En la celda Ruta de acceso, seleccione una ruta de acceso de un disco físico independiente del grupo de archivos PRINCIPAL.
Haga clic en Aceptar.
En SQL Server Management Studio, haga clic en Nueva consulta.
Copie la siguiente consulta en la ventana de consulta y, a continuación, haga clic en Ejecutar. Este código Transact-SQL crea un nuevo procedimiento almacenado que mueve las tablas al nuevo grupo de archivos.
IF EXISTS (SELECT * FROM sysobjects WHERE type = 'P' AND name = 'proc_MoveTableToFileGroup') BEGIN DROP Procedure dbo.proc_MoveTableToFileGroup END GO CREATE PROCEDURE [dbo].[proc_MoveTableToFileGroup] ( @fileGroup sysname, @tableName sysname ) as begin declare @data_space_id int declare @object_id int declare @index_id int declare @index_name sysname declare @object_name sysname declare @fileGroupName sysname declare @index_cols nvarchar(4000) declare @sql nvarchar(4000) declare @key_ordinal int set @index_id = 0 set @key_ordinal = 0 select @data_space_id = data_space_id, @fileGroupName = name from sys.filegroups where name = @fileGroup if @data_space_id is null begin raiserror ('The specified filegroup does not exist.', 16, 1) return end while 1=1 begin select top 1 @object_id = i.object_id, @index_id = i.index_id, @index_name = i.name, @object_name = o.name from sys.indexes AS i inner join sys.objects AS o ON i.object_id = o.object_id where i.index_id > 0 and o.type = 'U' and o.name = @tableName and i.index_id > @index_id and i.data_space_id <> @data_space_id order by i.index_id if @@rowcount = 0 begin if @index_id = 0 print 'There are no indexes to move to filegroup ' + @fileGroupName + ' for table ' + @tableName break end set @index_cols = null set @key_ordinal = 0 while 1=1 begin select top 1 @index_cols = case when @index_cols is null then '[' + c.name + ']' else @index_cols + ', [' + c.name + ']' end + case when i.is_descending_key = 0 then ' asc' else 'desc' end, @key_ordinal = i.key_ordinal from sys.index_columns i inner join sys.columns as c on i.object_id = c.object_id and i.column_id = c.column_id where i.object_id = @object_id and i.index_id = @index_id and i.key_ordinal > @key_ordinal order by i.key_ordinal if @@rowcount = 0 break end select @sql = case when i.is_primary_key = 1 then N'begin try ' + N'begin tran ' + N'alter table [' + @object_name + '] drop constraint [' + i.name + '] ' + N'alter table [' + @object_name + '] add constraint [' + i.name + '] ' + 'primary key ' + case when i.type = 1 then 'clustered ' else 'nonclustered ' end + ' (' + @index_cols + ') ' + 'with (' + 'IGNORE_DUP_KEY = ' + case when i.ignore_dup_key = 1 then 'ON ' else 'OFF ' end + ', PAD_INDEX = ' + case when i.is_padded = 1 then 'ON ' else 'OFF ' end + case when i.fill_factor = 0 then '' else ', FILLFACTOR = ' + CONVERT(nvarchar(10),i.fill_factor) end + ') ' + 'ON [' + @fileGroupName + ']' + N' commit ' + N'end try ' + N'begin catch ' + N'rollback ' + N'end catch ' else N'create ' + case when i.is_unique = 1 then 'unique ' else '' end + case when i.type = 1 then 'clustered ' else 'nonclustered ' end + 'index [' + i.name + '] on [' + @object_name + '] (' + @index_cols + ') ' + 'with (' + 'IGNORE_DUP_KEY = ' + case when i.ignore_dup_key = 1 then 'ON ' else 'OFF ' end + ', PAD_INDEX = ' + case when i.is_padded = 1 then 'ON ' else 'OFF ' end + case when i.fill_factor = 0 then '' else ', FILLFACTOR = ' + CONVERT(nvarchar(10),i.fill_factor) end + ', DROP_EXISTING = ON ) ' + 'ON [' + @fileGroupName + ']' end from sys.indexes AS i where i.object_id = @object_id and i.index_id = @index_id print 'Moving index ' + @index_name + ' to filegroup ' + @fileGroupName print @sql print '' exec sp_executesql @sql end end
En SQL Server Management Studio, haga clic en Nueva consulta.
Copie la siguiente consulta en la ventana de consulta y, a continuación, haga clic en Ejecutar. Este código Transact-SQL ejecuta el nuevo procedimiento almacenado para cada tabla de indización.
declare @fileGroup sysname set @fileGroup = 'CrawlFileGroup' if not exists (select 1 from sys.filegroups where name = @fileGroup) begin raiserror ('The specified filegroup does not exist.', 16, 1) return end exec proc_MoveTableToFileGroup @fileGroup, 'MSSAnchorChangeLog' exec proc_MoveTableToFileGroup @fileGroup, 'MSSAnchorPendingChangeLog' exec proc_MoveTableToFileGroup @fileGroup, 'MSSAnchorText' exec proc_MoveTableToFileGroup @fileGroup, 'MSSAnchorTransactions' exec proc_MoveTableToFileGroup @fileGroup, 'MSSCrawlChangedSourceDocs' exec proc_MoveTableToFileGroup @fileGroup, 'MSSCrawlChangedTargetDocs' exec proc_MoveTableToFileGroup @fileGroup, 'MSSCrawlContent' exec proc_MoveTableToFileGroup @fileGroup, 'MSSCrawlDeletedErrorList' exec proc_MoveTableToFileGroup @fileGroup, 'MSSCrawlDeletedURL' exec proc_MoveTableToFileGroup @fileGroup, 'MSSCrawlErrorList' begin try begin tran IF EXISTS (SELECT * FROM sys.foreign_keys WHERE object_id = OBJECT_ID(N'[dbo].[FK_MSSCrawlContent_MSSCrawlHistory]') AND parent_object_id = OBJECT_ID(N'[dbo].[MSSCrawlContent]')) ALTER TABLE [dbo].[MSSCrawlContent] DROP CONSTRAINT [FK_MSSCrawlContent_MSSCrawlHistory] exec proc_MoveTableToFileGroup @fileGroup, 'MSSCrawlHistory' ALTER TABLE [dbo].[MSSCrawlContent] WITH CHECK ADD CONSTRAINT [FK_MSSCrawlContent_MSSCrawlHistory] FOREIGN KEY([CrawlID]) REFERENCES [dbo].[MSSCrawlHistory] ([CrawlID]) commit end try begin catch rollback end catch exec proc_MoveTableToFileGroup @fileGroup, 'MSSCrawlHostList' exec proc_MoveTableToFileGroup @fileGroup, 'MSSCrawlQueue' exec proc_MoveTableToFileGroup @fileGroup, 'MSSCrawlURL' exec proc_MoveTableToFileGroup @fileGroup, 'MSSCrawlURLLog' exec proc_MoveTableToFileGroup @fileGroup, 'MSSTranTempTable0'
Mantenimiento de bases de datos de SQL Server para la búsqueda
Al igual que cualquier sistema complejo, las bases de datos de SQL Server requieren mantenimiento regular para mantener el rendimiento en el nivel más alto. En esta sección se describen algunos procedimientos recomendados para mantener el máximo rendimiento.
Los siguientes procedimientos de mantenimiento de disco pueden aumentar el rendimiento de los servidores de bases de datos:
Mantenga como mínimo un 25 por ciento de espacio libre en disco para permitir el incremento del tamaño de las bases de datos. Supervise regularmente el tamaño del disco y el espacio libre para evitar que este porcentaje disminuya. Si los administradores agregan nuevos orígenes de contenido, es posible que el tamaño de la base de datos de búsqueda aumente considerablemente de forma muy rápida.
Si la controladora de disco usa una memoria caché de escritura en disco, asegúrese de que tenga una batería de reserva para evitar que se interrumpa el servicio debido a un error de alimentación.
Los siguientes procedimientos de mantenimiento de SQL Server pueden aumentar el rendimiento de los servidores de bases de datos:
Ejecute la rutina de Transact-SQL
DBCC CHECKDB
regularmente en todas las bases de datos de Office SharePoint Server. Esta rutina supone una carga significativa para el equipo de SQL Server y puede afectar a la capacidad de respuesta. Por tanto, use la opciónPHYSICAL_ONLY
y programeDBCC CHECKDB
para las horas de poca actividad. No ejecute esta rutina durante un rastreo de Office SharePoint Server.Evite realizar operaciones no admitidas en los equipos de producción que ejecutan SQL Server. Por ejemplo, no cambie la intercalación de la base de datos ni agregue columnas a las tablas de base de datos de Office SharePoint Server. Para obtener más información acerca de las operaciones no admitidas, vea el artículo 841057 de Microsoft Knowledge Base sobre cómo admitir cambios en las bases de datos usadas por productos de servidor de Office y Windows SharePoint Services (https://go.microsoft.com/fwlink/?linkid=105589&clcid=0xC0A).
Con el tiempo, la fragmentación de los índices de SQL Server compatibles con la base de datos de búsqueda puede afectar el rendimiento de la indización y las consultas. En el artículo KB943345 de Microsoft Knowledge Base se incluye un script Transact-SQL que crea un procedimiento almacenado llamado proc_DefragmentIndices
. Puede usar este procedimiento para desfragmentar la base de datos de búsqueda y las bases de datos de contenido de la granja de servidores de Office SharePoint Server. Sin embargo, proc_DefragmentIndices
consume demasiados recursos de servidor, por lo que se debe usar con precaución para evitar que disminuya el rendimiento de la capacidad de respuesta a las consultas.
Nota
Para obtener el script proc_DefragmentIndices
y más información acerca de su uso, vea el tema sobre cómo desfragmentar bases de datos de Windows SharePoint Services 3.0 y de SharePoint Server 2007 (https://go.microsoft.com/fwlink/?linkid=105588&clcid=0xC0A).
Además, hay disponible un procedimiento almacenado de desfragmentación llamado proc_DefragSearchIndexes
, diseñado especialmente para la base de datos de búsqueda de Office SharePoint Server. Este procedimiento desfragmenta sólo los índices que proporcionan el máximo rendimiento, como IX_MSSDocProps e IX_MSSDocSdids. Esto reduce la demanda de recursos de servidor de bases de datos. Se recomienda programar el procedimiento almacenado para que se ejecute fuera de las horas de mayor actividad y supervisar detenidamente el efecto en los usuarios.
Nota
Para obtener el script proc_DefragSearchIndexes
y más información sobre su uso, vea el tema sobre tareas de desfragmentación y mantenimiento del índice de SQL para búsqueda (en inglés) (https://go.microsoft.com/fwlink/?linkid=158799&clcid=0xC0A) (en inglés) en el blog sobre Microsoft Enterprise Search.
Si detecta un cuello de botella en un disco o una RAID en un servidor de bases de datos de la granja de servidores, realice las siguientes acciones para reducir el efecto del problema:
Reubique los archivos de datos y los registros de transacciones para separar los discos o las matrices RAID. El uso de grupos de archivos, como se describió anteriormente en este artículo, maximiza el rendimiento.
Agregue discos a la matriz RAID.
Reemplace los discos más lentos por discos más rápidos.
Cómo evitar el colapso del rastreador
En una organización grande o compleja, se deben afrontar retos importantes al configurar el sistema de indización de Office SharePoint Server 2007. Es posible que tenga numerosos orígenes de contenido de varios tipos con una gran cantidad de contenido que tarda un tiempo considerable en rastrearse. Se recomienda planear detenidamente los objetivos para la actualización de las entradas del índice para garantizar que los resultados de la búsqueda reflejen el contenido actualizado. Si desea cumplir los objetivos de actualización, debe optimizar el rendimiento del indizador para que rastree todo el contenido regularmente.
Un obstáculo importante para la velocidad de indización es el colapso del rastreador. El rastreador se encuentra en un estado de colapso cuando no puede asignar otro subproceso para recuperar el siguiente documento de la cola. El colapso puede deberse a las siguientes causas:
Contención de recursos en el servidor de bases de datos que hospeda la base de datos de búsqueda.
En el rastreo participan demasiados hosts.
Hosts que no ceden rápidamente un subproceso. (En este artículo, se denominan hosts “acaparadores de recursos”).
Copias de seguridad en ejecución al mismo tiempo que el rastreo.
Los hosts acaparadores de recursos bloquean un subproceso e impiden el paso al siguiente documento. Esto puede ocurrir en los siguientes casos:
Cuando el host funciona con lentitud debido a la falta de CPU, memoria u otros recursos.
Cuando el host debe realizar un trabajo adicional para los rastreos incrementales. Por ejemplo, si el origen es un servidor de Microsoft SharePoint Portal Server 2003, el rastreador debe volver a procesar un documento completo en caso de que hayan cambiado los permisos.
Hosts o documentos con muchas propiedades. Si hay muchas propiedades para cada documento, aumenta la carga de trabajo del servidor de bases de datos que hospeda la base de datos de búsqueda. Los orígenes de contenido del Catálogo de datos profesionales y Mis sitios suelen tener muchas propiedades.
Los rastreos más eficaces se realizan con los siguientes tipos de host:
Servidores de Office SharePoint Server 2007. Estos servidores mantienen un registro de los cambios que puede usar el rastreador.
Recursos compartidos de archivos. El rastreador puede buscar cambios en el nivel de carpeta y no examina cada documento.
Carpetas públicas de Exchange. El rastreador puede buscar cambios en el nivel de carpeta y no examina cada publicación.
Instrucciones para evitar el colapso
Puede minimizar el colapso del rastreador siguiendo los siguientes procedimientos recomendados:
Minimice el número de orígenes de contenido. Al agrupar hosts de tamaño y tipo similar en orígenes de contenido únicos, aumenta la eficacia.
Rastree los hosts de Office SharePoint Server 2007 de gran tamaño antes de agregar otros tipos de host. Estos hosts se pueden rastrear de forma eficaz y los rastreos incrementales liberan los subprocesos rápidamente.
No programe rastreos para más de un host acaparador de recursos al mismo tiempo.
Como punto de partida, programe cuatro rastreos simultáneos. Es posible que pueda aumentar este número para algunos servidores de índices. Para obtener más información, consulte la sección siguiente en este artículo.
Si el rastreador se colapsa, pause el rastreo de los hosts acaparadores de recursos para liberar los subprocesos.
Procedimiento para diagnosticar un colapso
Al instalar un nuevo sistema de búsqueda de Office SharePoint Server 2007, cree la configuración del rastreador mediante la adición de nuevos orígenes de contenido a lo largo de varios días o semanas. Supervise el rendimiento del sistema a medida que agrega cada origen de contenido, a fin de evitar el colapso y facilitar la solución de problemas. De esta manera, puede tener un conocimiento exhaustivo del comportamiento del sistema durante los rastreos.
La cantidad de subprocesos que usa el rastreador se determina mediante la configuración de Rendimiento de indizador. Para cambiar esta configuración, en Administración central, haga clic en la pestaña Operaciones, en Servicios del servidor y, a continuación, en Office SharePoint Server Search. En la siguiente tabla se muestra cómo la configuración de Rendimiento de indizador controla los subprocesos de rastreo.
Configuración Rendimiento de indizador | Número total de subprocesos | Número máximo de subprocesos por cada host |
---|---|---|
Reducido |
Número de procesadores |
Número de procesadores |
Parcialmente reducido |
4 veces el número de procesadores |
Número de procesadores más 4 |
Máximo |
16 veces el número de procesadores |
Número de procesadores más 4 |
En Office SharePoint Server 2007, el número de subprocesos de rastreo nunca es superior a 64.
La causa más común del colapso es la contención de recursos en el servidor de bases de datos. Puede diagnosticar este problema mediante la supervisión del Complemento de archivado. En el monitor de rendimiento, use el objeto del Complemento de archivado de Office y los contadores Total de documentos en la primera cola y Total de documentos en la segunda cola. Si ambos contadores indican un valor de 500 para la instancia de Portal_Content o de 50 para la instancia de ProfileImport, el rastreador está colapsado. Considere la posibilidad de ajustar el servidor de bases de datos como se describió en la sección Optimización de SQL Server para búsqueda en Office SharePoint Server 2007 anteriormente en este artículo.
Los estados de colapso no provocados por el complemento de archivado se pueden diagnosticar con el objeto Recopilador de Office Server Search del monitor de rendimiento. Concéntrese en los contadores de Subprocesos inactivos, Subprocesos con acceso a la red y Subprocesos en complementos, y compárelos con el número total de subprocesos del sistema. Para obtener una descripción detallada de los contadores, vea la sección Supervisión de servidores de índice anteriormente en este artículo.
Cómo evitar cuellos de botella provocados por listas de control de acceso
Cuando Office SharePoint Server 2007 rastrea e indiza un origen de contenido, comprueba las listas de control de acceso (ACL) y las almacena en la base de datos de búsqueda. Cuando los usuarios realizan búsquedas en el índice, se comprueba la base de datos de búsqueda para cada resultado a fin de garantizar que el usuario esté autorizado para tener acceso a ese resultado. Este proceso se llama recorte de seguridad. En consecuencia, las grandes ACL con muchos niveles de anidamiento pueden afectar negativamente al rendimiento del proceso de rastreo y a las búsquedas en Office SharePoint Server. Esta sección describe cómo minimizar tal degradación del rendimiento.
Active Directory proporciona los siguientes tipos de entidades de seguridad que puede usar para proteger los sitios y el contenido indizado de Office SharePoint Server:
Cuentas de usuario
Grupos globales
Grupos locales de dominio
Grupos universales
En Office SharePoint Server 2007, también se incluyen grupos de SharePoint. Este sistema es muy flexible y puede incluir varios niveles de anidamiento. Sin embargo, las entidades de seguridad pueden afectar negativamente al rendimiento de la búsqueda de Office SharePoint Server.
Para garantizar el máximo rendimiento del rastreador y las búsquedas de Office SharePoint Server 2007, aplique las siguientes reglas cuando use entidades de seguridad de Active Directory y grupos de SharePoint:
Incluya las cuentas de usuario en grupos globales y los grupos globales en grupos locales de dominio. Asigne permisos a los grupos locales de dominio. Se trata del procedimiento recomendado para usar entidades de seguridad en Active Directory, ya que garantiza que los controladores de dominio puedan buscar la pertenencia a grupos rápidamente y que los usuarios tengan acceso a los recursos de todo el bosque.
Si son necesarios grupos universales, utilice el mismo sistema, pero coloque los grupos globales en grupos universales y los grupos universales en grupos locales de dominio.
Coloque los grupos locales de dominio en grupos de SharePoint para asignar permisos a los sitios de SharePoint y a otros recursos de SharePoint.
Limite el número de niveles de anidamiento usados en la pertenencia a grupos.
Las siguientes situaciones específicas afectan al rendimiento de búsqueda de Office SharePoint Server 2007 y, por tanto, se deben evitar:
No asigne permisos de sitios de Office SharePoint Server a usuarios individuales.
Los sitios de Office SharePoint Server se ralentizan cuando se enumeran más de 2.000 entidades de seguridad en la DACL de un sitio. Sin embargo, un grupo de Active Directory o SharePoint es una entidad de seguridad única, independientemente del número de usuarios que contenga. Por tanto, use grupos de SharePoint para asignar permisos de sitio y colocar usuarios o grupos de Active Directory en grupos de SharePoint.
No use grupos de seguridad de Active Directory con un nivel profundo de anidamiento.
Cuando un usuario intenta obtener acceso a un sitio de Office SharePoint Server, el servidor debe evaluar la pertenencia a grupos para autorizar al usuario. Si hay grupos con un nivel profundo de anidamiento, es necesario realizar muchas consultas al controlador de dominio. Además, es posible que se deban realizar consultas a dominios remotos del bosque. Estas consultas se deben completar antes de conceder acceso al usuario.
No use listas de distribución o grupos de seguridad que contengan contactos.
Se pueden agregar contactos de Active Directory a grupos para, por ejemplo, distribuir correo electrónico. Sin embargo, los contactos no son entidades de seguridad y no participan en la autorización. Puede reducirse el rendimiento si se asigna un permiso a un grupo que contiene contactos.
En Office SharePoint Server 2007, el propietario de cada sitio puede agregar usuarios y grupos a la DACL del sitio. Es importante educar a los propietarios de sitios en relación con el uso responsable de la pertenencia a grupos, a fin de evitar cuellos de botella.
Solución de problemas para la falta de elementos web de cuadro de búsqueda
El elemento web de cuadro de búsqueda no aparecerá en el Centro de búsqueda ni en otras ubicaciones de la interfaz de usuario de Office SharePoint Server 2007 en los siguientes casos:
Un programador ha modificado la página de contenido del Centro de búsqueda o la página maestra del sitio para ocultar o quitar el elemento web de cuadro de búsqueda.
Un usuario con el permiso Control total o Diseño en el sitio ha quitado u ocultado el elemento web Cuadro de búsqueda.
El servicio de búsqueda no está disponible en la granja de servidores de Office SharePoint Server debido a una interrupción del servicio o a que los administradores lo han desconectado.
Nota
Para obtener más información acerca del elemento web Cuadro de búsqueda, vea Configuración de las propiedades del elemento web de cuadro de búsqueda (Office SharePoint Server 2007).
Vea también
Conceptos
Solución de problemas con Office SharePoint Server 2007
Procedimientos recomendados de búsqueda en Office SharePoint Server