Optimisation des performances de création de cache de carte dans ArcGIS for Server 10.2.1

Je suis relativement nouveau dans ArcGIS for Server, j'espère donc que quelqu'un pourra m'orienter dans la bonne direction au cas où ce que je fais ne serait pas une bonne pratique.

J'ai 2 boîtiers avec ArcGIS for server 10.2.1, tous deux sur le même site. Les deux boîtiers ont 4 processeurs et 16 Go de RAM. Les deux boîtes s'exécutent sur Windows Server 2008.

Le site est utilisé à la fois pour fournir quelques services de carte de base à un petit nombre d'utilisateurs (<5) et pour générer des tuiles de cache pour les services futurs.

Je génère actuellement des tuiles de cache pour un service de cartographie (~ 50 Go). Je m'attendais à voir l'utilisation du processeur sur les 2 boîtiers assez élevée. Mais il a tendance à se situer entre 15% et 30% sur chaque boîte.

Le nombre maximal d'instances pour les outils de mise en cache est défini sur 6.

Le nombre maximal d'instances par machine est défini sur 3.

Ai-je tort de supposer que je devrais voir une utilisation plus élevée du CPU?

N'ai-je pas mis les bons chiffres?

Ou ma configuration n'est-elle pas la meilleure pratique? autrement dit, devrais-je utiliser un site uniquement pour servir des cartes et un autre site uniquement pour la mise en cache?

Je pense que j'ai suivi les directives mentionnées ici et ici . Mais je suis à peu près sûr que la mise en cache s'exécute plus lentement qu'elle ne devrait. Après 19 heures, il n'a mis en cache que 1,17% de toutes mes tuiles.

Toutes les suggestions de bonnes pratiques sont les bienvenues.

MISE À JOUR: Après 21 heures, l'utilisation du processeur sur les deux machines est réduite à rien:

machine 1:

machine 2:

La barre d'état du cache "en cours" sur le serveur est toujours en mouvement, mais le cache% n'a pas augmenté au cours des 2 dernières heures.

Il semble que vous ayez fait du bon travail en suivant les meilleures pratiques pour créer le cache. Vos serveurs ont suffisamment de puissance, mais l'extraction des données cartographiques de votre base de données peut être un problème. Voici un petit résumé de ce site qui contient quelques conseils supplémentaires pour tirer le meilleur parti de votre argent.

1 - Analysez votre carte avant de la publier!

Cela peut être évident, mais j'ai souvent été trop rapide pour publier sur le serveur sans vérifier les résultats de l'analyse. Rendez-vous simplement sur la page File->Analyze Mapet effectuez une vérification rapide pour voir si votre carte présente des problèmes. Plus votre carte peut être rendue rapidement, plus elle peut être mise en cache rapidement.

2 - Gardez les données locales

Si vous avez un déploiement sur une seule machine, conservez les données cartographiques dans un FGDB local sur le serveur. Si vous avez plusieurs machines, laissez chaque machine avoir une copie des données et utilisez l'option "Utiliser le répertoire de cache local lors de la génération de tuiles sur le serveur" lors de la configuration du cache.

Le lien ci-dessus contient quelques conseils pratiques sur la gestion des échecs, ainsi que ce script pratique qui analyse les erreurs de mise en cache dans une empreinte de polygone afin que vous puissiez facilement revenir en arrière et essayer de remettre en cache les zones en échec.

Cette question revient de temps en temps. Peut-être pouvons-nous obtenir plus de réponses et en faire un wiki. :)

Vous pouvez également définir les contrôleurs de mise en cache et les outils de mise en cache sur un cluster différent. Cela devrait isoler le processus de mise en cache du pool régulier de processus. J'ai vu cela donner de meilleures performances en isolant la mise en cache des fonctions arcgisserver normales. J'appelle généralement cette nouvelle mise en cache de cluster. Ensuite, lorsque vous ajoutez de nouvelles machines à votre installation, ajoutez-les simplement au cluster de mise en cache par défaut et cela augmentera votre puissance de traitement. De plus, si vous constatez une faible utilisation, continuez à ajouter de plus en plus de ressources jusqu'à ce que vous atteigniez une utilisation d'environ 70 à 80%, vous voulez toujours laisser un peu de puissance pour copier les fichiers dans les deux sens et réduire les conflits de ressources.

Sur la base de la documentation ESRI ( http://server.arcgis.com/en/server/latest/publish-services/linux/accelerating-map-cache-creation.htm ) la meilleure pratique pour le nombre d'instances à utiliser pour la mise en cache est n + 1 où n est le nombre de cœurs en cours d'exécution sur le serveur. Vos serveurs ont chacun 4 processeurs et chaque processeur X5690 a 6 cœurs selon la documentation:

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

Sur cette base, vous devriez théoriquement être capable de gérer 25 instances de mise en cache par serveur. Maintenant, je sais que le document ESRI est pour 10.3 mais cela a été la pratique recommandée pour les dernières versions.

J'ai une configuration de serveur similaire et je peux vous dire que mon processeur atteindrait 100% avant d'obtenir près de 25 instances, mais je peux utiliser 10-15 assez confortablement.

Donc, si vous avez testé que le disque IO ou la base de données ne sont pas les goulots d'étranglement, je recommanderais d'augmenter le nombre d'instances à 10. Si cela n'augmente pas votre utilisation du processeur, cela signifie que ce n'était pas le facteur limitant. Si cela augmente, mais qu'il est toujours raisonnable, vous pouvez essayer d'augmenter davantage.

Quoi qu'il en soit, la morale de l'histoire est de ne pas hésiter à lancer les instances. Une fois, j'ai également travaillé sur un serveur assez sous-alimenté avec seulement 2 cœurs et 3 instances, je ne suis arrivé nulle part. Cependant, lorsque j'ai augmenté les instances à 5, l'utilisation du processeur était raisonnable. La meilleure pratique n'est qu'un point de départ.