Ajuste de los Parámetros para un Rendimiento Óptimo de CPS en un TPS Superior

Introducción

Este documento ayuda a diagnosticar problemas de rendimiento con tráfico elevado y a ajustar los parámetros de Cisco Policy Suite (CPS) para obtener un rendimiento óptimo en transacciones por segundo (TPS) más altas.

Diagnóstico de problemas

1. Analice los registros consolidados del motor para los códigos de resultado de diámetro que no sean 2001-DIAMETER_SUCCESS.

   Ejemplo:

   [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

   Nota: Esta salida muestra 3002-DIAMETER_UNABLE_TO_DELIVER, 5002-DIAMETER_UNKNOWN_SESSION_ID y 5012-DIAMETER_UNABLE_TO_COMPLY.

   Puede verificar los detalles del código de resultado del diámetro en RFC 3588.

   En el caso de CPS que no se ha configurado para obtener un rendimiento óptimo, encontrará en su mayoría un recuento alto para 5012- DIAMETER_UNABLE_TO_COMPLY.

2. Revise los registros del motor consolidado para ver el recuento de sucesos para el código de resultado de diámetro 5012.

   Ejemplo:

   [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 el código de resultado del diámetro 5012 se observa a una velocidad alta en el TPS más alto, continúe con las verificaciones de registro adicionales en este procedimiento.

3. Verifique en el registro del motor consolidado que se observa el error "connection wait timeout after 0 ms" antes de que la Función de Reglas de Política y Carga (PCRF) envíe DiámetroResponseMessage con Result-Code: 5012.

   Ejemplo:

   <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>

Nota: Puede verificar el TPS en el sistema CPS en medio de un tiempo problemático con el comando top_qps.sh disponible en la versión 5.5 y posteriores de CPS.

Solución

1. Cambie la configuración del subprocesamiento en Policy Builder de la predeterminada 20 a 50. Para hacerlo, inicie sesión en Policy Builder y elija Datos de Referencia > Sistemas > sistema-1 > Configuraciones de Plugin >Configuraciones de Subprocesamiento.

   

   De forma predeterminada (cuando el campo Configuración del subprocesamiento está en blanco), el número de subprocesos para la conexión mongo es 20 en la configuración del creador de políticas, por lo que puede manejar esa cantidad de solicitudes cuando se ejecuta en el TPS bajo. A medida que el TPS aumenta, estos subprocesos están ocupados y, por lo tanto, se requieren más subprocesos para satisfacer las solicitudes.

   El conteo de subprocesos de 50 es suficiente para manejar alrededor de 5000 TPS, ya que hay más subprocesos disponibles que pueden manejar un mayor número de solicitudes.

   Estos son subprocesos del motor de políticas y se definen con el nombre "rules" y se deben configurar sólo con ese nombre.

2. Agregue Dmongo.client.thread.maxWaitTime=5000 a /etc/broadhop/pcrf/qns.conf.

   Ejemplo:

   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 es un tiempo en milisegundos que un subproceso espera a que una conexión esté disponible. Si no se especifica este parámetro, considera el valor predeterminado que es 0 ms. Por lo tanto, se observa el error mientras que las pruebas se encuentran en un TPS más alto. La adición de este parámetro en /etc/broadhop/pcrf/qns.conf aumenta el tiempo que los nuevos subprocesos esperan la conexión mongo cuando las pruebas se encuentran en un TPS alto.

   2000 es el valor recomendado de QA y fue probado para el TPS alto. Para TPS mayor de 5000, puede configurarlo a 5000 ms para optimizar el rendimiento.

3. Agregue -Dspr.mongo.socket.timeout=5000 a /etc/broadhop/pcrf/qns.conf.

   De forma predeterminada, el valor es 60000 milisegundos.(60 segundos). Por lo tanto, lleva más tiempo estar disponible para otros subprocesos.

   La configuración recomendada es de 5000 milisegundos (5 segundos) para facilitar un tiempo de espera más rápido y permitir que otros subprocesos procesen rápidamente.

4. Cambie el valor de Conexiones por host del valor predeterminado 5 a 20 en Policy Builder. Para hacerlo, inicie sesión en Policy Builder y elija Referencia Data > Systems > system-1 > Configuraciones del complemento > Configuración de USuM > Conexiones por Host.

   

   Este es el número por Quantum Network Suite (QNS) de conexiones con mongo DB. Esto significa que para 4 QNS, 4*20=80 es el número total de conexiones.

   Esto es necesario para las actualizaciones frecuentes en mongodb. Por lo tanto, se recomienda actualizarlo como 20 por recomendación de evaluación de la calidad para lograr un rendimiento óptimo.

   También configure Db Read Preference como SecondaryPreferred, lo que significa que todos los QNS reciben datos de la base de datos secundaria y sólo reciben datos de Primary cuando la BD secundaria está ocupada. Esto ayuda a optimizar el rendimiento, ya que la base de datos principal está menos cargada.

5. Configure el nivel de registro raíz adecuado para el sistema.

   Los registros excesivos pueden bloquear el procesamiento en el nivel QNS y LB.Por lo tanto, se recomienda configurar el nivel de registro raíz en los niveles warn o superiores tanto en los archivos /etc/brodhop/logback.xml como /etc/broadhop/controlcenter/logback.xml.

   Ejemplo:

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

   También cambie estos niveles de registro:

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

   Ejemplo:

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

   Estos cambios deben replicarse en todas las máquinas virtuales. Realice syncconfig.sh y luego realice restartall.sh (o stopall.sh y luego startall.sh) para aplicar todos estos cambios.

Advertencia: Realice estos cambios sólo en una ventana Mantenimiento.