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

Introducción

Este documento ayuda a diagnosticar los problemas de rendimiento en el mucho tráfico y a ajustar los parámetros de la habitación de la directiva de Cisco (CP) para que haya rendimiento óptimo en un Transactions Per Second más alto (TP).

Diagnósticos del problema

1. Analice los registros del consolidar-motor para los códigos de resultado del diámetro con excepción de 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

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

   Usted puede marcar los detalles del código de resultado del diámetro en el RFC 3588.

   Para los CP que no se configura para el rendimiento óptimo, usted encuentra sobre todo el conteo alto para 5012- DIAMETER_UNABLE_TO_COMPLY.

2. Los registros del consolidar-motor del estudio para el acontecimiento cuentan para el código de resultado 5012 del diámetro.

   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 de 5012 diámetros se observa a una alta velocidad en TP más altos, proceda con las verificaciones adicionales del registro en este procedimiento.

3. Verifique en el registro del consolidar-motor que el “tiempo de espera de la conexión después de que observen a 0 ms” error antes de la directiva y la función de carga de las reglas (PCRF) envíe el DiameterResponseMessage con el código de resultado: 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>

Note: Usted puede marcar los TP en el sistema CP en el medio de un rato problemático con el comando de top_qps.sh que está disponible en la versión 5.5 y posterior CP.

Solución

1. Cambie la configuración que rosca en el constructor de la directiva del valor por defecto 20 a 50. Para hacer esto, inicie sesión al constructor de la directiva y elija los datos de referencia > los sistemas > system-1 > las configuraciones plugs-in >Threading las configuraciones.

   

   Por abandono (cuando el campo configuration que rosca es espacio en blanco) el número de hilos para la conexión del mongo es 20 en configuración del constructor de la directiva así que puede manejar esa cantidad de peticiones cuando se ejecuta en los TP bajos. Pues los TP aumentan estos hilos están ocupados y por lo tanto más hilos se requieren para satisfacer las peticiones.

   La cuenta del hilo de 50 es suficiente para dirigir alrededor 5000 TP pues más hilos están disponibles que puede manejar un número más elevado de las peticiones.

   Éstos son hilos del motor de directivas y se definen con el nombre “gobiernan " y se deben configurar con ese nombre solamente.

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

   2000 es el valor recomendado QA y fue probado para los altos TP. Para los TP mayores de 5000 usted puede configurarlo al ms 5000 para optimizar el funcionamiento.

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

   Por abandono el valor es 60000 segundos milliseconds.(60). Por lo tanto tarda un tiempo más largo para estar disponible para otros hilos.

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

4. Cambie las conexiones por el valor del host del valor por defecto 5 a 20 en el constructor de la directiva. En el ot de la orden haga esto, inicie sesión al constructor de la directiva y elija los datos de referencia > los sistemas > system-1 > las configuraciones > configuración > las conexiones plugs-in de USuM por el host.

   

   Éste es por el número de la habitación de la red de Quantum (QNS) de conexiones con el mongo DB. Esto significa que para 4 QNS, 4*20=80 es el número total de conexiones.

   Esto se requiere para las actualizaciones frecuentes en el mongodb. Por lo tanto, se recomienda para ser puesto al día como 20 por la recomendación QA para el rendimiento óptimo.

   También el DB de la configuración leyó la preferencia como SecondaryPreferred que significa que todo el QNS recibe los datos de la base de datos secundaria y recibe solamente los datos de primario cuando el DB secundario está ocupado. Esto ayuda a optimizar el funcionamiento puesto que el DB primario se carga lo más menos posible.

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

   Los registros excesivos pueden bloquear el proceso en el nivel QNS y LB. Por lo tanto se recomienda que usted configura el nivel de registro de la raíz en advierte o niveles más altos en /etc/brodhop/logback.xml y los archivos de /etc/broadhop/controlcenter/logback.xml.

   Ejemplo:

   [root@pcrfclient01 ~]#cat /etc/broadhop/logback.xml
   
   <snip>
   <!-- Configure default Loggers -->
   <root level="warn">
      <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 -->
   <root level="warn">
      <appender-ref ref="FILE" />
   </root>
   
   </configuration>

   Necesidad de estos cambios de ser replicado a través de todas las máquinas virtuales. Realice syncconfig.sh y después realice restartall.sh (o stopall.sh y entonces startall.sh) para aplicar todos los éstos cambia.

Advertencia: Realice estos cambios en una ventana de mantenimiento solamente.