Analytics and Automation Software : Cisco Data Virtualization

Foire aux questions de suite de virtualisation de données : Combien de temps est-ce que des demandes sont mises à jour dans le panneau de demandes de gestionnaire de studio ?

18 octobre 2016 - Traduction automatique
Autres versions: PDFpdf | Anglais (22 août 2015) | Commentaires

Introduction

Ce document décrit les paramètres de configuration (CIS) de serveur d'informations de Cisco qui déterminent quand des demandes sont purgées dans le panneau de la demande du gestionnaire CIS de studio.

Contribué par Suresh Venkatesan, ingénieur TAC Cisco.

Combien de temps est-ce que des demandes sont mises à jour dans le panneau de demandes de gestionnaire de studio ?

Afin de vérifier la valeur de ces configurations, choisissez la gestion > la configuration > le serveur > les informations de traitement d'exécution.

  • Nombres maximaux de demandes dépistés - Nombre maximal de demandes dépisté (par exemple, 10000). Une modification à cette valeur n'a aucun effet jusqu'à la prochaine reprise de serveur.
  • Période de purge de demande - Contrôles combien de fois le serveur nettoie les demandes terminées qui sont plus anciennes que la période de purge (par exemple, 5 minutes).
  • Sessions maximum dépistées - Nombre maximal de sessions simultanées (par exemple, 10000). '0' d'utilisation pour aucune limite.
  • Période de purge de session - Contrôles combien de fois le serveur nettoie les sessions fermées qui sont plus anciennes que la période de purge (par exemple, 5 minutes).

Si vous avez ces configurations configurées avec l'exemple numérote :

  • Après la période minute de la purge 5, TOUTES LES demandes terminées qui ont fini plus de 5 minutes il y a et TOUTES LES sessions fermées qui ont fini plus il y a de 5 minutes seront purgées.
  • Si vous ne voyez pas les demandes terminées dans le panneau de demandes dans le gestionnaire de studio, alors très probablement ils ont été purgés après que « la période de purge de demande » expirée.

Il pourrait y avoir des effets secondaires quand ces configurations sont plus élevées. Par exemple, si la période de purge de demande est fixée à 1 semaine et aux nombres maximaux de demandes Tracked est placé à 100000. Vous devrez tester ceci afin de voir si l'empreinte de pas de mémoire pour le processus CIS augmentait trop ou pas. Ces objets de demande sont maintenus dans la mémoire et s'accumulent pendant une semaine. CIS pourrait avoir beaucoup plus de 100,000 objets de demande dans la mémoire puisqu'ils sont seulement purgés vers le bas à 100,000 chaque semaine.

« La période de purge de demande » est le temps entre les purges. Les « nombres maximaux de demandes dépistés » est le nombre de requêtes dans la liste (LRU) moins utilisée récemment qui sont enregistrés quand la liste de demandes est purgée. La force CIS ont beaucoup plus de 100,000 demandes maintenues dans la mémoire avant qu'ils soient purgés, qui manqueraient très probablement le CIS de mémoire avant la période de purge. Si vous avez besoin de beaucoup de mémoire et de beaucoup de petites demandes de manipuler ce chargement, vous devez le tester afin de valider que CIS ne manque pas de mémoire. Les objets de demande sont gardés pendant que les références douces ainsi le nettoyage de la mémoire les donne un coup de pied dedans et collecte si nécessaires, mais d'autre part le graphique CIS de mémoire restera très probablement près de maxed tout le temps. Si CIS a besoin de beaucoup de mémoire soudainement parce que vous avez une vague de demandes à traiter, CIS recevra probablement hors de l'erreur de mémoire.

Une meilleure solution est de questionner la table de demande (table du système éditée de /services/databases/system/sys_requests) et de les maintenir dans une table et une requête qui ajournent à la place.



Document ID: 118608