Estimación de los requisitos de rendimiento y capacidad para Servicios de Access en SharePoint Server 2010
Se aplica a: SharePoint Server 2010 Enterprise
Última modificación del tema: 2016-11-30
En este artículo se proporciona una orientación sobre cómo afecta el uso de Servicios de Access en Microsoft SharePoint Server 2010 a la capacidad en las topologías que ejecutan Microsoft SharePoint Server 2010.
En este artículo:
Prueba de las características de la granja de servidores
Resultados de las pruebas
Recomendaciones
Solución de problemas
Prueba de las características de la granja de servidores
En esta sección se describe el conjunto de datos que se usó durante la prueba, las cargas de trabajo que se aplicaron al producto durante la recopilación de rendimiento, el hardware usado y la topología en que se implementó dicho hardware.
Conjunto de datos
La capacidad y el rendimiento de Servicios de Access dependen en gran medida de la estructura de las aplicaciones hospedadas en el servicio. El tamaño de las tablas y la complejidad de las consultas suelen ser los factores que más afectan a la capacidad y al rendimiento. En la prueba se usaron tamaños y complejidades representativos, pero cada aplicación y conjunto de datos es diferente. La capacidad y el rendimiento dependerán de las aplicaciones que se usen, de su complejidad específica y del tamaño de los datos.
Para evaluar el perfil de capacidad, se simularon aplicaciones de Servicios de Access en un conjunto o granja de servidores dedicada a Servicios de Access (sin otras pruebas de SharePoint en ejecución). En la granja se incluyeron los siguientes sitios representativos:
1.500 aplicaciones de Servicios de Access con un perfil de tamaño "pequeño"; 100 elementos por lista como máximo.
1.500 aplicaciones de Servicios de Access con un perfil de tamaño "mediano"; 2.000 elementos por lista como máximo.
1.500 aplicaciones de Servicios de Access con un perfil de tamaño "grande"; 10.000 elementos por lista como máximo.
Cada aplicación consta de varias listas y el tamaño de las demás listas se adecua a esta lista más grande. Servicios de Access puede administrar más datos que 10.000 elementos. En el perfil "grande" se eligió este número porque se previó que no sería común el uso de aplicaciones de mayor tamaño.
Las aplicaciones se distribuyeron uniformemente entre las siguientes aplicaciones:
Contactos: una aplicación simple de administración de contactos, dominada por una sola lista.
Proyectos: una aplicación simple de seguimiento de proyectos y tareas, dominada por dos listas (proyectos y tareas asociados con cada proyecto).
Pedidos: un sistema simple de entrada de pedidos, similar al ejemplo Northwind Traders de Microsoft Access, pero con un tamaño más reducido y con muchas listas relacionadas entre sí (pedidos, detalles de pedido, facturas, detalles de factura, pedidos de compra, detalles de pedido de compra, etc).
Carga de trabajo
Para simular el uso de las aplicaciones, se crearon cargas de trabajo para llevar a cabo una o varias de las siguientes operaciones:
Abrir formularios
Desplazarse por los formularios
Filtrar y ordenar hojas de datos
Actualizar, eliminar e insertar registros
Publicar aplicaciones
Representar informes
Cada carga de trabajo incluye "tiempo de reflexión" entre las acciones del usuario que varía entre 5 y 20 segundos, lo que difiere de otros documentos de planeación de capacidad de SharePoint. Servicios de Access es una plataforma con estado; los cursores de memoria y los conjuntos de registros se conservaron entre las interacciones del usuario. Era importante simular una sesión de usuario completa en lugar de meramente solicitudes individuales. Para la carga de trabajo de un solo usuario, el promedio es de dos solicitudes por segundo.
La siguiente tabla muestra los porcentajes que se usaron para determinar la aplicación y el tamaño de aplicación que debía usarse.
| Pequeña | Media | Grande | |
|---|---|---|---|
Contactos |
16% |
10% |
9% |
Proyectos |
18% |
12% |
10% |
Pedidos |
11% |
8% |
6% |
Definiciones de las zonas verde y roja
Para cada configuración, se ejecutaron dos pruebas para determinar una "zona verde" y una "zona roja". La zona verde es el rendimiento recomendado que se puede mantener. La zona roja es el rendimiento máximo que puede tolerarse durante un breve período, pero este debe evitarse.
La zona verde se definió como un punto en el que la prueba en ejecución consume a lo sumo la mitad del recurso de cuello de botella. En este caso, el recurso de cuello de botella era el porcentaje de uso de CPU en cualquiera de los tres niveles: servidor front-end web, servidor de aplicaciones (servicios de datos de Access) o servidor de bases de datos (SQL Server). En primer lugar, se identificó el cuello de botella de una configuración en particular. Si el cuello de botella era la CPU de servicios de datos de Access, nos aseguramos de que la prueba de la zona verde consumiera CPU en los equipos de servicios de datos de Access en un intervalo del 40-50%.
Para la zona roja, se seleccionó un punto en el que se alcanzó el rendimiento máximo. Este resultó ser un intervalo de CPU del 80-90%. Al buscar el cuello de botella, analizamos el porcentaje de uso de CPU, el uso de memoria (bytes privados), la longitud de la cola de disco, la E/S de red y otros recursos que podían producir un cuello de botella.
Tanto la prueba de la zona roja como la de la zona verde se ejecutaron durante una hora en una carga de usuarios fija.
Los resultados pueden variar
Las cifras de capacidad y rendimiento específicas presentadas en este artículo difieren de las cifras en un entorno real. Esta simulación es solo una estimación de lo que pueden hacer los usuarios reales. Las cifras que se presentan aquí están diseñadas para proporcionar un punto de partida para el diseño de un entorno de tamaño adecuado. Después de completar el diseño inicial del sistema, debe probar la configuración para determinar si el sistema admitirá los factores del entorno.
Configuración de hardware y topología
Hardware del laboratorio
Para proporcionar un alto nivel de detalle en los resultados de la prueba, se usaron varias configuraciones de granja de servidores en las pruebas. Las configuraciones de granja de servidores variaron entre uno y cuatro servidores front-end web, uno y cuatro servidores de aplicaciones (en función de si se usa Servicios de Access o los servicios de datos de Access) y un solo equipo servidor de bases de datos que ejecuta Microsoft SQL Server 2008. Además, las pruebas se realizaron con cuatro equipos cliente. Todos los equipos servidor eran de 64 bits y todos los equipos cliente eran de 32 bits.
En la tabla siguiente se enumera el hardware específico usado para realizar las pruebas.
| Rol de la máquina | CPU | Memoria | Red | Disco |
|---|---|---|---|---|
Servidor front-end web |
2 procesadores de núcleo cuádruple a 2,33 GHz |
8 Gigabytes (GB) |
1 GB |
RAID 5 de 2 cilindros |
Servidor de aplicaciones (servicios de datos de Access) |
2 procesadores de núcleo cuádruple a 2,33 GHz |
8 Gigabytes (GB) |
1 GB |
RAID 5 de 2 cilindros |
Servidor de bases de datos (SQL Server) |
4 procesadores de núcleo cuádruple a 2,6 GHz |
32 GB |
1 GB |
RAID 0 adjunto de almacenamiento conectado directo (DAS) para cada número de unidad lógica (LUN) |
Topología
La experiencia indica que la CPU en el nivel de servidor de aplicaciones, donde se ejecutan los servicios de datos de Access, es un importante factor restrictivo del rendimiento. Variamos la topología mediante la adición de equipos adicionales de servicios de datos de Access hasta que dejó de ser el cuello de botella y, a continuación, agregamos un servidor front-end web para obtener un rendimiento incluso mayor.
1x1: un equipo servidor front-end web y un equipo de servicios de datos de Access
1x2: un equipo servidor front-end web y dos equipos de servicios de datos de Access
1x3: un equipo servidor front-end web y tres equipos de servicios de datos de Access
1x4: un equipo servidor front-end web y cuatro equipos de servicios de datos de Access
2x1: dos equipos servidor front-end web y un equipo de servicios de datos de Access
2x2: dos equipos servidor front-end web y dos equipos de servicios de datos de Access
2x4: dos equipos servidor front-end web y cuatro equipos de servicios de datos de Access
El equipo que ejecuta SQL Server es un equipo relativamente eficaz y en ningún momento se convirtió en el cuello de botella (aunque comenzó a aproximarse a la saturación de CPU en la prueba 2x4), por lo que no variamos esto en las topologías. Según las consultas que forman parte de una combinación de aplicaciones real, se prevé que el nivel de servidor de bases de datos (SQL Server) podría convertirse en el cuello de botella.
Reporting Services se ejecutó en modo conectado en todas las pruebas en el nivel de servidor de aplicaciones (servicios de datos de Access).
Resultados de las pruebas
En las siguientes tablas se muestran los resultados de las pruebas de Servicios de Access. Para cada grupo de pruebas, solo se cambian ciertas variables específicas para mostrar el impacto progresivo en el rendimiento de la granja de servidores.
Todas las pruebas de este artículo se realizaron con tiempo de reflexión o tiempo de espera, lo que difiere de los resultados de la planeación de capacidad de otras partes de SharePoint.
Para obtener información acerca de los cuellos de botella de Servicios de Access, vea el tema sobre los cuellos de botella comunes y sus causas más adelante en este artículo.
Escala general
La tabla y el gráfico que se muestran a continuación resumen el impacto de la adición de servidores front-end web y equipos de servicios de datos de Access dedicados adicionales en la granja de servidores. Estas cifras de rendimiento se aplican específicamente a los equipos de servicios de datos Access y no reflejan el impacto en la granja global.
| Topología | Máximo de soluciones de línea base (RPS) | Línea base recomendada (RPS) |
|---|---|---|
1x1 |
25 |
15 |
1x2 |
54 |
29 |
1x3 |
82 |
45 |
1x4 |
88 |
48 |
2x1 |
25 |
15 |
2x2 |
55 |
29 |
2x4 |
116 |
58 |
.gif "RPS máximo y recomendado")
Resultados recomendados
El siguiente gráfico muestra los resultados del rendimiento sostenible recomendado.
.gif "Rendimiento frente a ADS")
Como se describió anteriormente en este artículo, la adición del cuarto equipo de servicios de datos de Access cambia el cuello de botella al servidor front-end web, y la adición de un segundo servidor front-end web resuelve la restricción de recursos en el nivel de servidor front-end web. Esto implicaría que 1x1, 1x2 y 1x3 son configuraciones razonables. Sin embargo, cuando se agrega el cuarto equipo de servicios de datos de Access, también se debe agregar un servidor front-end web. Puesto que el escalado se realiza de manera lineal (en línea recta de 1x1 a 1x4), se puede suponer que la adición de un séptimo equipo de servicios de datos de Access también implicaría la adición de un tercer servidor front-end web y así sucesivamente para satisfacer las necesidades de la granja de servidores.
Recuerde que estos resultados solo se basan en una carga de trabajo simulada y que se debe supervisar una implementación real para buscar el punto en el que se necesitan servidores front-end web adicionales para admitir equipos de servicios de datos de Access adicionales. Además, los servidores front-end web están dedicados a Servicios de Access y, en la implementación real, es probable que en su lugar se compartan con otras cargas de trabajo de SharePoint. El siguiente gráfico muestra los resultados.
.gif "Tiempo de respuesta frente a ADS")
El siguiente gráfico muestra el tiempo de respuesta en este nivel de rendimiento. El tiempo de respuesta es muy corto; el promedio es menor a una cuarta parte de un segundo por solicitud.
.gif "SQL %CPU frente a ADS")
Estos resultados muestran que el equipo de SQL Server no era un cuello de botella, ya que la adición de un segundo servidor front-end web resolvió el déficit de recursos, y el uso de CPU de SQL Server fue siempre inferior al 50%. Sin embargo, tenga en cuenta que la instancia de SQL Server se comparte con otros servicios de SharePoint y con SharePoint propiamente dicho, por lo que el efecto acumulativo podría extender las longitudes de la cola de E/S de disco o CPU hasta el punto en que sí se convertirán en un cuello de botella.
Máximo
El siguiente gráfico muestra resultados en los que el rendimiento ha excedido el límite sostenible.
En este gráfico se observa que nuevamente se necesitó un segundo servidor front-end web para maximizar la utilidad del cuarto equipo de servicios de datos de Access. Como se mencionó anteriormente, los resultados pueden variar, ya que dependen en gran medida de las aplicaciones y de sus patrones de uso.
.gif "Rendimiento frente a ADS")
En este caso, el tiempo de respuesta ha aumentado debido al esfuerzo que experimenta el sistema global. Sin embargo, estos niveles aún son de un segundo aproximadamente, lo que es aceptable para la mayoría de los usuarios.
Puede parecer extraño que con cuatro equipos de servicios de datos de Access, dos servidores front-end web tienen un tiempo de respuesta mayor que un solo servidor front-end web. Esto se debe a que el rendimiento general del sistema aumenta con dos servidores front-end web.
Como se mencionó anteriormente, SQL Server no es un factor restrictivo, ya que la adición del segundo servidor front-end web nos vuelve a situar en una línea de escalado linear. No obstante, nos aproximamos al 90% de uso de CPU en la instancia de SQL Server. Por lo tanto, queda muy poca capacidad de aumento. Si agregáramos un quinto equipo de servicios de datos de Access, el equipo de SQL Server probablemente se convertiría en el cuello de botella.
.gif "SQL %CPU frente a ADS")
Resultados detallados
Las siguientes tablas muestran los resultados detallados de las configuraciones recomendadas.
| General | 1x1 | 1x2 | 1x3 | 1x4 | 2x1 | 2x2 | 2x4 |
|---|---|---|---|---|---|---|---|
Solicitudes por segundo |
14,96 |
28,76 |
45,22 |
48,01 |
14,85 |
28,77 |
58,02 |
Pruebas por segundo |
2,00 |
3,81 |
6,11 |
6,42 |
1,99 |
3,81 |
7,80 |
Promedio de latencia |
235,80 |
241,21 |
247,21 |
244,87 |
240,70 |
242,26 |
250,94 |
| Promedio de nivel de servidor front-end web | 1x1 | 1x2 | 1x3 | 1x4 | 2x1 | 2x2 | 2x4 |
|---|---|---|---|---|---|---|---|
% de CPU |
13,82 |
24,40 |
41,02 |
43,62 |
6,31 |
12,48 |
26,18 |
Bytes privados de w3wp máximos |
9,46E+08 |
2,31E+08 |
1,49E+09 |
1,55E+09 |
8,43E+08 |
9,84E+08 |
1,19E+09 |
| Promedio de nivel de servidor de aplicaciones (servicios de datos de Access) | 1x1 | 1x2 | 1x3 | 1x4 | 2x1 | 2x2 | 2x4 |
|---|---|---|---|---|---|---|---|
% de CPU |
46,30 |
42,83 |
43,74 |
34,51 |
46,56 |
43,45 |
42,13 |
% de w3wp de CPU |
33,61 |
31,15 |
30,71 |
24,29 |
33,48 |
31,64 |
29,72 |
% de RS de CPU |
8,62 |
7,94 |
9,17 |
6,84 |
9,03 |
8,02 |
8,71 |
Total de bytes privados máximos |
4,80E+09 |
4,89E+09 |
4,91E+09 |
4,62E+09 |
5,32E+09 |
4,82E+09 |
5,07E+09 |
Bytes privados de w3wp máximos |
2,10E+09 |
1,97E+09 |
2,04E+09 |
1,86E+09 |
2,00E+09 |
2,00E+09 |
2,07E+09 |
Bytes privados de RS máximos |
1,78E+09 |
2,00E+09 |
1,97E+09 |
1,86E+09 |
2,30E+09 |
1,89E+09 |
2,02E+09 |
| Nivel de servidor de bases de datos (SQL Server) (equipo único) | 1x1 | 1x2 | 1x3 | 1x4 | 2x1 | 2x2 | 2x4 |
|---|---|---|---|---|---|---|---|
% de CPU |
12,07 |
18,64 |
32,53 |
36,05 |
9,89 |
21,42 |
47,46 |
Promedio de bytes privados |
2,96E+10 |
3,22E+10 |
3,25E+10 |
3,25E+10 |
2,89E+10 |
3,22E+10 |
3,25E+10 |
Bytes privados máximos |
3,26E+10 |
3,25E+10 |
3,25E+10 |
3,25E+10 |
3,25E+10 |
3,25E+10 |
3,25E+10 |
Total de longitud promedio de la cola de disco |
0,74 |
1,18 |
1,64 |
1,77 |
0,67 |
1,24 |
2,18 |
Las siguientes tablas muestran los resultados detallados de las configuraciones máximas.
| General | 1x1 | 1x2 | 1x3 | 1x4 | 2x1 | 2x2 | 2x4 |
|---|---|---|---|---|---|---|---|
Solicitudes por segundo |
14,96 |
28,76 |
45,22 |
48,01 |
14,85 |
28,77 |
58,02 |
Pruebas por segundo |
2,00 |
3,81 |
6,11 |
6,42 |
1,99 |
3,81 |
7,80 |
Promedio de latencia |
235,80 |
241,21 |
247,21 |
244,87 |
240,70 |
242,26 |
250,94 |
| Promedio de nivel de servidor front-end web | 1x1 | 1x2 | 1x3 | 1x4 | 2x1 | 2x2 | 2x4 |
|---|---|---|---|---|---|---|---|
% de CPU |
13,82 |
24,40 |
41,02 |
43,62 |
6,31 |
12,48 |
26,18 |
Bytes privados de w3wp máximos |
9,46E+08 |
2,31E+08 |
1,49E+09 |
1,55E+09 |
8,43E+08 |
9,84E+08 |
1,19E+09 |
| Promedio de nivel de servidor de aplicaciones (servicios de datos de Access) | 1x1 | 1x2 | 1x3 | 1x4 | 2x1 | 2x2 | 2x4 |
|---|---|---|---|---|---|---|---|
% de CPU |
46,30 |
42,83 |
43,74 |
34,51 |
46,56 |
43,45 |
42,13 |
% de w3wp de CPU |
33,61 |
31,15 |
30,71 |
24,29 |
33,48 |
31,64 |
29,72 |
% de RS de CPU |
8,62 |
7,94 |
9,17 |
6,84 |
9,03 |
8,02 |
8,71 |
Total de bytes privados máximos |
4,80E+09 |
4,89E+09 |
4,91E+09 |
4,62E+09 |
5,32E+09 |
4,82E+09 |
5,07E+09 |
Bytes privados de w3wp máximos |
2,10E+09 |
1,97E+09 |
2,04E+09 |
1,86E+09 |
2,00E+09 |
2,00E+09 |
2,07E+09 |
Bytes privados de RS máximos |
1,78E+09 |
2,00E+09 |
1,97E+09 |
1,86E+09 |
2,30E+09 |
1,89E+09 |
2,02E+09 |
| Nivel de servidor de bases de datos (SQL Server) (equipo único) | 1x1 | 1x2 | 1x3 | 1x4 | 2x1 | 2x2 | 2x4 |
|---|---|---|---|---|---|---|---|
% de CPU |
12,07 |
18,64 |
32,53 |
36,05 |
9,89 |
21,42 |
47,46 |
Promedio de bytes privados |
2,96E+10 |
3,22E+10 |
3,25E+10 |
3,25E+10 |
2,89E+10 |
3,22E+10 |
3,25E+10 |
Bytes privados máximos |
3,26E+10 |
3,25E+10 |
3,25E+10 |
3,25E+10 |
3,25E+10 |
3,25E+10 |
3,25E+10 |
Total de longitud promedio de la cola de disco |
0,74 |
1,18 |
1,64 |
1,77 |
0,67 |
1,24 |
2,18 |
Recomendaciones
En esta sección se proporcionan recomendaciones generales sobre rendimiento y capacidad.
La capacidad y el rendimiento de Servicios de Access dependen en gran medida de la estructura de las aplicaciones hospedadas en el servicio. El tamaño de las tablas y la complejidad de las consultas suelen ser los factores que causan el mayor efecto. En la prueba se usaron tamaños y complejidades representativos, pero cada aplicación y conjunto de datos es diferente. Por lo tanto, la capacidad y el rendimiento dependerán de las aplicaciones que se usen, de su complejidad específica y del tamaño de los datos.
Recomendaciones de hardware
Servicios de Access usa hardware estándar tanto para los servidores front-end web como para los servidores de aplicaciones; no existe ningún requisito especial. Las instrucciones generales de SharePoint Server 2010 en cuanto al número de CPU, la memoria y la velocidad se aplican a los equipos en el nivel de servidor de aplicaciones (servicios de datos de Access).
Topologías con incremento de la escalabilidad vertical y con incremento de la escalabilidad horizontal
Para aumentar la capacidad y el rendimiento de una de las topologías de punto de partida, tiene dos opciones. Puede incrementar la escalabilidad vertical mediante el aumento de la capacidad de los servidores existentes o incrementar la escalabilidad horizontal mediante la adición de servidores adicionales a la topología. En esta sección se describen las características de rendimiento generales de varias topologías cuya escalabilidad horizontal se ha incrementado.
Las topologías de ejemplo representan las siguientes maneras comunes de incrementar la escalabilidad horizontal de una topología para un escenario de Servicios de Access:
Para proporcionar una mayor carga de usuarios, compruebe la CPU de los servidores de aplicaciones de Servicios de Access existentes. Agregue más CPU o núcleos, o ambos, en estos servidores, si es posible. Agregue equipos servidor de Servicios de Access adicionales según sea necesario. Puede hacer esto hasta el punto en que el servidor front-end web se convierta en el cuello de botella y, a continuación, agregue servidores front-end web según sea necesario.
En las pruebas, la memoria en el nivel de servidor front-end web y en el nivel de servidor de aplicaciones (servicios de datos de Access) no se convirtió en un cuello de botella. En función del tamaño de los conjuntos de resultados, la memoria podría convertirse en un problema. Sin embargo, no se prevé que esa sea la norma. Realice un seguimiento de los bytes privados del proceso w3wp de servicios de datos de Access, como se describe aquí.
En las pruebas, SQL Server no se convirtió en un cuello de botella. Sin embargo, estas se ejecutaron de forma aislada de otros servicios de SharePoint Server 2010. Debe supervisarse la E/S de disco y CPU de SQL Server y agregarse servidores o cilindros adicionales según sea necesario.
Configuración de Servicios de Access relacionada con el rendimiento
Una forma de controlar las características de rendimiento de Servicios de Access consiste en limitar el tamaño y la complejidad de las consultas que pueden realizarse. Servicios de Access proporciona un conjunto de limitaciones configurables para controlar las consultas. Cada una de las siguientes consultas se puede configurar mediante Administración central de SharePoint. (En la sección Administración de aplicaciones, haga clic en Administrar aplicaciones de servicio y, a continuación, en Servicios de Access).
En general, la cantidad de datos que debe recuperarse desde SharePoint para realizar una consulta tendrá un efecto significativo en el rendimiento. Esto se puede controlar de diversas maneras. En primer lugar, se pueden limitar las entradas en una consulta:
Número máximo de orígenes por consulta
Número máximo de registros por tabla
En segundo lugar, se puede limitar el tamaño resultante de una consulta:
Número máximo de columnas por consulta
Número máximo de filas por consulta
Permitir combinaciones externas
Además del tamaño de la consulta (tamaño de los datos de entrada y de salida), la complejidad del procesamiento de los datos se puede controlar para reducir la carga de CPU en el nivel de servidor de aplicaciones (servicios de datos de Access):
Número máximo de columnas calculadas por consulta
Número máximo de cláusulas Order By por consulta
Obviamente, la configuración anterior afectará a las aplicaciones que se pueden ejecutar en el servidor. Por ejemplo, si una aplicación se escribe con 40 columnas de resultados de una consulta y la configuración es inferior a este nivel, la aplicación producirá un error en tiempo de ejecución. Se debe conseguir un equilibrio entre las necesidades del usuario y un rendimiento aceptable, el cual dependerá en gran medida del tipo de aplicaciones de Access que se espera que se ejecuten en la granja de servidores.
Se puede tomar una medida adicional más extrema. SharePoint Server 2010 admite un conjunto de operaciones de consulta de forma nativa, que Servicios de Access aumenta para abarcar un conjunto más amplio de escenarios de aplicaciones. Para que Servicios de Access mejore las consultas de SharePoint, es posible que sea necesario recuperar una gran cantidad de datos desde la base de datos de contenido de SharePoint. En su lugar, se puede configurar Servicios de Access para que solo se ocupe de las operaciones de consulta, que pueden admitirse de forma nativa en SharePoint. De este modo, se evita la captura de datos necesaria para las operaciones más complejas:
- Permitir consultas de uso no remoto
Optimizaciones
Cuellos de botella comunes y sus causas
Durante las pruebas de rendimiento, se detectaron distintos cuellos de botella habituales. Un cuello de botella es una situación en la que se alcanza la capacidad máxima de un componente determinado de una granja de servidores. Esto produce un estancamiento o una disminución en el rendimiento de la granja de servidores.
La tabla proporcionada en Solución de problemas más adelante en este artículo enumera algunos cuellos de botella comunes y describe sus causas y posibles soluciones.
Supervisión del rendimiento
Como ayuda para determinar cuándo es necesario incrementar la escalabilidad horizontal o la escalabilidad vertical del sistema, use contadores de rendimiento para supervisar el mantenimiento del sistema. Use la información de las tablas siguientes para determinar los contadores de rendimiento que deben supervisarse, así como el proceso al que deben aplicarse.
Servidores front-end web
En la tabla siguiente, se muestran los contadores de rendimiento y los procesos que deben supervisarse en los servidores web de la granja.
| Contador de rendimiento | Aplicar a objeto | Notas |
|---|---|---|
% de tiempo de procesador |
Processor(_Total) |
Muestra el porcentaje de tiempo transcurrido durante el que este proceso usó el procesador para ejecutar instrucciones. |
Bytes privados |
Process(w3wp) |
Este valor no debe aproximarse a los bytes privados máximos establecidos para los procesos w3wp. Si lo hace, es necesaria una investigación adicional para averiguar qué componente está usando la memoria. |
Servicios de datos de Access
En la tabla siguiente, se muestran los contadores de rendimiento y los procesos que deben supervisarse en los servidores de aplicaciones, o de servicios de datos de Access en este caso, dentro de la granja.
| Contador de rendimiento | Aplicar a objeto | Notas |
|---|---|---|
% de tiempo de procesador |
Processor(_Total) |
Muestra el porcentaje de tiempo transcurrido durante el que este proceso usó el procesador para ejecutar instrucciones. |
% de tiempo de procesador |
Process(w3wp) |
Los servicios de datos de Access se ejecutan dentro de su propio proceso w2wp, y será evidente de qué proceso w2wp se trata puesto que consumirá la mayor parte del tiempo de CPU. |
Longitud promedio de la cola de disco |
PhysicalDisk(_Total) |
Comprueba si el disco contiene demasiadas escrituras por causa de registros. |
% de tiempo de procesador |
Process(ReportingServicesService) |
SQL Server Reporting Services administra los informes. Si se ejecutan demasiados informes o si estos son muy complejos, el uso de CPU y los bytes privados de este proceso serán altos. |
Bytes privados |
Process(w3wp) |
Servicios de Access almacena los resultados de las consultas en la memoria caché hasta que expira la sesión del usuario (cuyo tiempo de espera se puede configurar). Si se procesa una gran cantidad de datos mediante los servicios de datos de Access, aumentará el consumo de memoria del proceso w3wp de los servicios de datos Access. |
Bytes privados |
Process(ReportingSrevicesService) |
SQL Server Reporting Services administra los informes. Si se ejecutan demasiados informes o si estos son muy complejos, el uso de CPU y los bytes privados de este proceso serán altos. |
Servidores de bases de datos
En la siguiente tabla se muestran los procesos y contadores de rendimiento para supervisar los servidores de bases de datos en la granja de servidores.
| Contador de rendimiento | Aplicar a objeto | Notas |
|---|---|---|
% de tiempo de procesador |
Processor(_Total) |
Muestra el porcentaje de tiempo transcurrido durante el que este proceso usó el procesador para ejecutar instrucciones. |
% de tiempo de procesador |
Process(sqlservr) |
Los valores promedio mayores que 80% indican que la capacidad del procesador en el servidor de bases de datos no es suficiente. |
Bytes privados |
Process(sqlservr) |
Muestra la cantidad de memoria promedio consumida por SQL Server. |
Longitud promedio de la cola de disco |
PhysicalDisk(_Total) |
Muestra la longitud de cola de disco promedio; las solicitudes de base de datos que se encuentran en espera para confirmarse en el disco. Esto suele ser un buen indicador de que la instancia de SQL Server se está sobrecargando y de que, posiblemente, la adición de cilindros de disco podría ayudar a distribuir la carga. |
Solución de problemas
En la siguiente tabla se enumeran algunos cuellos de botella comunes y se describen sus causas y soluciones posibles.
| Cuellos de botella | Causa | Resolución |
|---|---|---|
CPU de Servicios de datos de Access |
Servicios de Access depende de una gran cantidad de procesamiento en el nivel de servidor de aplicaciones. Si se usa una configuración 1x1, 1x2 o 1x3, el primer cuello de botella que se encontrará probablemente será la CPU de los servidores de servicios de datos de Access. |
Aumente el número de CPU o núcleos, o ambos, en los equipos de servicios de datos de Access existentes. Agregue equipos de servicios de datos de Access adicionales, si es posible. |
Uso de CPU del servidor web |
Cuando un servidor web está sobrecargado con solicitudes de usuario, el uso de CPU promedio se aproxima al 100%. Esto impide que el servidor web responda a las solicitudes de forma rápida y puede causar tiempos de espera y mensajes de error en los equipos cliente. |
Este problema se puede resolver de una de estas dos formas: se pueden agregar más servidores web a la granja para distribuir la carga de usuarios o se puede incrementar la escalabilidad vertical del servidor o de los servidores web mediante la adición de procesadores de mayor velocidad. |
E/S de disco de servidor de bases de datos |
Cuando el número de solicitudes de E/S de un disco duro supera la capacidad de E/S del disco, las solicitudes se ponen en cola. Como resultado, aumenta el tiempo necesario para completar cada solicitud. |
La distribución de archivos de datos en varias unidades físicas permite E/S en paralelo. El blog sobre E/S en disco y asignación de disco en SharePoint (https://go.microsoft.com/fwlink/?linkid=129557&clcid=0xC0A) contiene información útil sobre cómo resolver problemas de E/S en disco. |
Uso de CPU de Reporting Services |
El proceso de Reporting Services está usando una gran parte de los recursos de CPU. |
Dedique un equipo a Reporting Services mediante el uso de carga del nivel de servidor de aplicaciones (servicios de datos de Access) (modo conectado) o del nivel de servidor front-end web (modo local). |