Ajuster les paramètres pour des performances CPS optimales à un TPS supérieur

Introduction

Ce document aide à diagnostiquer les problèmes de performances à un trafic élevé et à ajuster les paramètres de Cisco Policy Suite (CPS) pour des performances optimales à des transactions par seconde (TPS) plus élevées.

Diagnostics des problèmes

1. Analyser les journaux consolidés du moteur pour les codes de résultat de diamètre autres que 2001-DIAMETER_SUCCESS.

   Exemple :

   [root@pcrfclient01 broadhop]#zcat consolidated-engine_07Apr15_16_06_37.1.log.gz| grep 
   "Result-Code" | grep -v 2001|cut -c16-19|sort -u
   3002
   5002
   5012

   Note: Ce résultat montre 3002-DIAMETER_UNABLE_TO_DELIVER, 5002-DIAMETER_UNKNOWN_SESSION_ID et 5012-DIAMETER_UNABLE_TO_COMPLY.

   Vous pouvez vérifier les détails du code de résultat de diamètre dans RFC 3588.

   Dans le cas de CPS qui n'est pas configuré pour des performances optimales, vous trouvez généralement un nombre élevé pour 5012- DIAMETER_UNABLE_TO_COMPLY.

2. Examiner les journaux du moteur consolidé pour le nombre d'occurrences du code de résultat de diamètre 5012.

   Exemple :

   [root@pcrfclient01 broadhop]#zcat consolidated-engine_07Apr15_23_16_35.1.log.gz|
   grep "Result-Code" | grep 5012|wc -l
   6643
   [root@pcrfclient01 broadhop]#zcat consolidated-engine_07Apr15_16_06_37.1.log.gz| 
   grep "Result-Code" | grep 5012|wc -l
   627
   [root@pcrfclient01 broadhop]#zcat consolidated-engine_07Apr15_16_26_37.1.log.gz| 
   grep "Result-Code" | grep 5012|wc -l
   2218
   [root@pcrfclient01 broadhop]#zcat consolidated-engine_07Apr15_16_46_35.1.log.gz| 
   grep "Result-Code" | grep 5012|wc -l
   0

   Si le code de résultat de 5012 diamètre est observé à un taux élevé à un TPS supérieur, poursuivez les vérifications de log supplémentaires dans cette procédure.

3. Vérifiez dans le journal du moteur consolidé que l'erreur « délai d'attente de connexion après 0 ms » est observée avant que la fonction de règles de stratégie et de charge (PCRF) envoie le DiameterResponseMessage avec le code de résultat : 5012.

   Exemple :

   <snip>
     	INFO   : (balance) Error found,  rolling back transaction
   	ERROR  : (core) Error processing policy request: com.mongodb.DBPortPool$Connection
      WaitTimeOut: Connection wait timeout after 0 ms
   	com.mongodb.DBPortPool.get(DBPortPool.java:222)
   	com.mongodb.DBTCPConnector$MyPort.get(DBTCPConnector.java:413)
   	com.mongodb.DBTCPConnector.innerCall(DBTCPConnector.java:238)
   	com.mongodb.DBTCPConnector.call(DBTCPConnector.java:216)
   	com.mongodb.DBApiLayer$MyCollection.__find(DBApiLayer.java:288)
   	com.mongodb.DBApiLayer$MyCollection.__find(DBApiLayer.java:273)
   	com.mongodb.DBCollection.findOne(DBCollection.java:728)
   	com.mongodb.DBCollection.findOne(DBCollection.java:708)
   	com.broadhop.balance.impl.dao.impl.MongoBalanceRepository$6.findOne(MongoBalance
   	Repository.java:375)
   	<snip>

Note: Vous pouvez vérifier TPS sur le système CPS au milieu d'une période problématique avec la commande top_qps.sh disponible dans CPS version 5.5 et ultérieure.

Solution

1. Modifiez la configuration de thread dans Policy Builder de 20 à 50 par défaut. Pour ce faire, connectez-vous à Policy Builder et choisissez Référence Data > Systems > system-1 > Plugin Configurations >Threading Configurations.

   

   Par défaut (lorsque le champ Threading Configuration est vide), le nombre de threads pour la connexion mongo est de 20 dans la configuration Policy Builder afin qu'il puisse gérer ce nombre de requêtes lorsqu'il s'exécute avec un TPS faible. Au fur et à mesure que le TPS augmente, ces threads sont occupés et donc plus de threads sont nécessaires pour répondre aux requêtes.

   Le nombre de threads de 50 est suffisant pour gérer environ 5000 TPS, car plus de threads sont disponibles et peuvent traiter un plus grand nombre de requêtes.

   Il s'agit de threads de moteur de stratégie et sont définis avec le nom « rules » et doivent être configurés avec ce nom uniquement.

2. Ajoutez Dmongo.client.thread.maxWaitTime=5000 à /etc/broadhop/pcrf/qns.conf.

   Exemple :

   cat /etc/broadhop/pcrf/qns.conf
   	QNS_OPTS="
   	-DbrokerUrl=failover:(tcp://lb01:61616,tcp://lb02:61616)?randomize=false
   	-DjmsFlowControlHost=lb02
   	-DjmsFlowControlPort=9045
   	-Dcc.collectd.ip.primary=pcrfclient01
   	-Dcc.collectd.port.primary=27017
   	-Dcc.collectd.ip.secondary=pcrfclient01
   	-Dcc.collectd.port.secondary=27017
   	-DudpPrefix=lb
   	-DudpStartPort=5001
   	-DudpEndPort=5003
   	-DqueueHeartbeatIntervalMs=25
   	-Dcom.broadhop.memcached.ip.local=lbvip02
   	-Dmongo.client.thread.maxWaitTime=5000
   	?

   Dmongo.client.thread.maxWaitTime est une durée en millisecondes pendant laquelle un thread attend qu'une connexion soit disponible. Si ce paramètre n'est pas spécifié, il prend en compte la valeur par défaut qui est 0 ms. Par conséquent, l'erreur est observée lorsque les tests sont à un TPS supérieur. L'ajout de ce paramètre dans /etc/broadhop/pcrf/qns.conf augmente le temps que les nouveaux threads attendent pour la connexion mongo lorsque les tests sont sur un TPS élevé.

   2000 est la valeur recommandée par QA et a été testée pour un TPS élevé. Pour TPS supérieure à 5000, vous pouvez le configurer à 5000 ms afin d'optimiser les performances.

3. Add-Dsps.mongo.socket.timeout=5000 à /etc/broadhop/pcrf/qns.conf.

   Par défaut, la valeur est de 60 000 millisecondes.(60 secondes). Il faut donc plus de temps pour que d'autres threads soient disponibles.

   La configuration recommandée est de 5 000 millisecondes (5 secondes) afin de faciliter un délai d'attente plus court et permettre à d'autres threads de traiter rapidement.

4. Modifiez la valeur Connexions par hôte de la valeur par défaut 5 à 20 dans Policy Builder. Pour ce faire, connectez-vous à Policy Builder et choisissez Reference Data > Systems > system-1 > Plugin Configurations > USuM Configuration > Connections Per Host.

   

   Il s'agit du nombre de connexions par QNS (Quantum Network Suite) avec la base de données mongo. Cela signifie que pour 4 QNS, 4*20=80 représente le nombre total de connexions.

   Ceci est nécessaire pour les mises à jour fréquentes dans mongodb. Par conséquent, il est recommandé de mettre à jour comme 20 par recommandation d'assurance qualité pour des performances optimales.

   Configurez également la préférence de lecture Db en tant que SecondaryPreferred, ce qui signifie que tous les QNS reçoivent des données de la base de données secondaire et ne reçoivent des données du Primary que lorsque la base de données secondaire est occupée. Cela permet d'optimiser les performances car la base de données principale est la moins chargée.

5. Configurez le niveau de journalisation racine approprié pour le système.

   Un nombre excessif de journaux peut bloquer le traitement au niveau QNS et LB.Il est donc recommandé de configurer le niveau de journalisation racine à des niveaux d'avertissement ou supérieurs à /etc/brodhop/logback.xml et /etc/broadhop/controlcenter/logback.xml fichiers.

   Exemple :

   [root@pcrfclient01 ~]#cat /etc/broadhop/logback.xml
   
   <snip>
   <!-- Configure default Loggers -->
   
            
            
      <appender-ref ref="FILE" />
      <appender-ref ref="SOCKET" />
   </root>
   
   </configuration>

   Modifiez également ces niveaux de journalisation :

   <logger name="org.jdiameter" level="info"/>  ---> Change to WARN
   
   <logger name="com.broadhop" level="info"/> --->Change to WARN

   Exemple :

   [root@pcrfclient01 ~]# cat /etc/broadhop/controlcenter/logback.xml
   
   <snip>
   
   <!-- Configure default Loggers -->
   
            
            
      <appender-ref ref="FILE" />
   </root>
   
   </configuration>

   Ces modifications doivent être répliquées sur toutes les machines virtuelles. Effectuez syncconfig.sh, puis exécutez restartall.sh (ou stopall.sh et startall.sh) afin d'appliquer toutes ces modifications.

Avertissement : Effectuez ces modifications dans une fenêtre Maintenance uniquement.