Optimización del rendimiento de la creación de caché de mapas en ArcGIS for Server 10.2.1


8

Soy relativamente nuevo en ArcGIS for Server, por lo que espero que alguien pueda orientarme en la dirección correcta en caso de que lo que he estado haciendo no sea una buena práctica.

Tengo 2 cajas con ArcGIS para el servidor 10.2.1, ambas en el mismo sitio. Ambas cajas tienen 4 procesadores y 16 gb de RAM. Ambos cuadros se ejecutan en Windows Server 2008.

ingrese la descripción de la imagen aquí

El sitio se utiliza tanto para proporcionar un par de servicios de mapas básicos a una pequeña cantidad de usuarios (<5) como para generar mosaicos de caché para servicios futuros.

Actualmente estoy generando mosaicos de caché para un servicio de mapeo (~ 50GB). Hubiera esperado ver el uso de la CPU en las 2 cajas funcionando bastante alto. Pero tiende a estar entre el 15% y el 30% en cada cuadro.

Las instancias máximas para las herramientas de almacenamiento en caché se establecen en 6.

ingrese la descripción de la imagen aquí

El número máximo de instancias por máquina se establece en 3.

ingrese la descripción de la imagen aquí

¿Me equivoco al suponer que debería ver un mayor uso de la CPU?

¿No he puesto las cifras correctas?

¿O mi configuración no es la mejor práctica? es decir, ¿debería usar un sitio solo para servir mapas y otro sitio solo para almacenar en caché?

Creo que he seguido las pautas mencionadas aquí y aquí . Pero estoy bastante seguro de que el almacenamiento en caché se ejecuta más lento de lo que debería. Después de 19 horas, solo ha almacenado en caché el 1,17% de todas mis fichas.

ingrese la descripción de la imagen aquí

Cualquier sugerencia de mejores prácticas es muy bienvenida.

ACTUALIZACIÓN: después de 21 horas, el uso de la CPU en ambas máquinas no se reduce a nada:

máquina 1: ingrese la descripción de la imagen aquí

máquina 2:

ingrese la descripción de la imagen aquí

La barra de estado del "caché en progreso" en el servidor todavía se está moviendo, pero el% de caché no ha aumentado en las últimas 2 horas.


¿Está su servidor en Linux o Windows?
Mintx

Mintx, he actualizado la pregunta con la información solicitada.
Dan_h_b

no estoy seguro, pero podría deberse al acceso de lectura / escritura más que a la CPU
radouxju

La cuenta de ArcServer tiene acceso completo de lectura / escritura a la carpeta de destino y acceso de lectura a la base de datos donde se almacenan los datos de origen. He almacenado en caché áreas más pequeñas de la misma fuente al mismo destino sin ningún problema.
Dan_h_b

1
Creo que el comentario de radouxju se refería a la contención de E / S del disco más que a los permisos. La velocidad con la que los procesos pueden escribir archivos de imagen podría ser el cuello de botella.
tomfumb

Respuestas:


2

Parece que has hecho un buen trabajo siguiendo las mejores prácticas para crear el caché. Sus servidores tienen suficiente potencia, pero extraer los datos del mapa de su base de datos podría ser un problema. Aquí hay un pequeño resumen de este sitio que tiene algunos consejos adicionales para aprovechar al máximo su inversión.

1 - ¡ Analiza tu mapa antes de publicarlo!

Esto puede ser obvio, pero a menudo he sido demasiado rápido para publicar en el servidor sin verificar los resultados del análisis. Simplemente vaya File->Analyze Mapy haga una comprobación rápida para ver si su mapa tiene algún problema. Cuanto más rápido se puede procesar su mapa, más rápido se puede almacenar en caché.

2 - Mantenga los datos locales

Si tiene una única implementación de máquina, mantenga los datos del mapa en un FGDB local para el servidor. Si tiene varias máquinas, deje que cada máquina tenga una copia de los datos y use la opción "Usar el directorio de caché local al generar mosaicos en el servidor" al configurar la caché.

El enlace de arriba tiene algunos consejos prácticos sobre cómo lidiar con fallas, junto con este útil script que analiza los errores de almacenamiento en caché en una huella de polígono para que pueda regresar fácilmente e intentar volver a almacenar en caché las áreas fallidas.

Esta pregunta surge de vez en cuando. Tal vez podamos obtener algunas respuestas más y convertir esto en un Wiki. :)


1

Otra cosa que podría hacer es configurar los controladores de almacenamiento en caché y las herramientas de almacenamiento en caché en un clúster diferente. Esto debería aislar el proceso de almacenamiento en caché del conjunto regular de procesos. He visto que esto produce un mejor rendimiento al aislar el almacenamiento en caché de las funciones regulares de arcgisserver. Normalmente llamo a este nuevo almacenamiento en caché de clúster. Luego, cuando agregue nuevas máquinas a su instalación, simplemente agréguelas al clúster de almacenamiento en caché en comparación con las predeterminadas y esto aumentará su potencia de procesamiento. Además, si ve una baja utilización, continúe agregando más y más recursos hasta llegar a una utilización de alrededor del 70-80%, aún así desea dejar algunos caballos de fuerza para copiar los archivos de un lado a otro y reducir la contención de recursos.


1

Basado en la documentación de ESRI ( http://server.arcgis.com/en/server/latest/publish-services/linux/accelerating-map-cache-creation.htm ) la mejor práctica para la cantidad de instancias que se utilizarán para el almacenamiento en caché es n + 1 donde n es el número de núcleos que se ejecutan en el servidor. Sus servidores tienen 4 procesadores cada uno y cada procesador X5690 tiene 6 núcleos de acuerdo con la documentación:

http://ark.intel.com/products/52576/Intel-Xeon-Processor-X5690-12M-Cache-3_46-GHz-6_40-GTs-Intel-QPI

En base a esto, en teoría debería poder manejar 25 instancias de almacenamiento en caché por servidor. Ahora sé que el documento ESRI es para 10.3, pero esta ha sido la práctica recomendada para las últimas versiones.

Tengo una configuración de servidor similar y puedo decirle que mi CPU llegaría al 100% antes de llegar a cerca de 25 instancias, pero puedo usar 10-15 con bastante comodidad.

Entonces, si ha probado que la E / S del disco o la base de datos no son cuellos de botella, recomendaría aumentar el número de instancias a 10. Si esto no aumenta el uso de su CPU, significa que no fue el factor limitante. Si lo aumenta, pero sigue siendo razonable, podría intentar aumentar aún más.

De todos modos, la moraleja de la historia es no ser tímido sobre poner en marcha las instancias. Una vez que también trabajé en un servidor bastante poco potente con solo 2 núcleos y 3 instancias no me llevó a ninguna parte. Sin embargo, cuando aumenté las instancias a 5, el uso de la CPU fue razonable. La mejor práctica es solo un punto de partida.

Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.