Ajustar parâmetros para o desempenho ideal do CPS em um TPS mais alto

Introduction

Este documento ajuda a diagnosticar problemas de desempenho em alto tráfego e a ajustar os parâmetros do Cisco Policy Suite (CPS) para obter um desempenho ideal em um TPS (Transactions Per Second, Transações por segundo) mais alto.

Diagnóstico de problemas

1. Analise os registros consolidados do mecanismo para obter códigos de resultado de diâmetro diferentes de 2001-DIAMETER_SUCCESS.

   Exemplo:

   [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 saída mostra 3002-DIAMETER_UNABLE_TO_DELIVER, 5002-DIAMETER_UNKNOWN_SESSION_ID e 5012-DIAMETER_UNABLE_TO_COMPLY.

   Você pode verificar os detalhes do código de resultado do diâmetro no RFC 3588.

   Para o CPS que não está configurado para o desempenho ideal, você encontra a maior contagem para 5012- DIAMETER_UNABLE_TO_COMPLY.

2. Reveja os registros consolidados do mecanismo para a contagem de ocorrências do Diameter Result Code 5012.

   Exemplo:

   [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

   Se o código de resultado do diâmetro de 5012 for observado a uma taxa alta em TPS mais alto, continue com as verificações de log adicionais neste procedimento.

3. Verifique no log consolidado-engine se o erro "connection wait timeout after 0 ms" (tempo de espera da conexão após 0 ms) foi observado antes que a Policy and Charging Rules Function (PCRF) envie o DiameterResponseMessage com Result-Code: 5012.

   Exemplo:

   <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: Você pode verificar o TPS no sistema CPS no meio de um tempo problemático com o comando top_qps.sh disponível no CPS versão 5.5 e posterior.

Solução

1. Altere a configuração de Threading no Policy Builder do padrão 20 para 50. Para fazer isso, faça login no Policy Builder e escolha Reference Data > Systems > system-1 > Plugin Configurations >Threading Configurations.

   

   Por padrão (quando o campo Configuração de threading estiver em branco), o número de threads para conexão mongo é 20 na configuração do Policy Builder para que ele possa lidar com essa quantidade de solicitações quando executado em TPS baixo. À medida que o TPS aumenta, esses processos estão ocupados e, portanto, mais processos são necessários para atender às solicitações.

   A contagem de segmentos de 50 é suficiente para lidar com cerca de 5.000 TPS à medida que mais segmentos estão disponíveis que podem lidar com um número maior de solicitações.

   Esses são segmentos de mecanismo de política e são definidos com o nome "regras" e devem ser configurados somente com esse nome.

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

   Exemplo:

   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 é um tempo em milissegundos que um thread espera que uma conexão se torne disponível. Se esse parâmetro não for especificado, ele considerará o valor padrão, que é 0 ms. Portanto, o erro é observado enquanto os testes estão em um TPS mais alto. A adição desse parâmetro em /etc/broadhop/pcrf/qns.conf aumenta o tempo que os novos segmentos aguardam pela conexão mongo quando os testes estão em um TPS alto.

   2000 é o valor de QA recomendado e foi testado para TPS alto. Para TPS maior que 5000, você pode configurá-lo como 5000 ms para otimizar o desempenho.

3. Adicione Dabrigo.mongo.socket.timeout=5000 a /etc/broadhop/pcrf/qns.conf.

   Por padrão, o valor é 60000 milissegundos.(60 segundos). Portanto, leva mais tempo para se tornar disponível para outros processos.

   A configuração recomendada é de 5000 milissegundos (5 segundos) para facilitar um tempo limite mais rápido e permitir que outros processos sejam processados rapidamente.

4. Altere o valor de Conexões por host do padrão 5 para 20 no Policy Builder. Para fazer isso, faça login no Policy Builder e escolha Reference Data > Systems > system-1 > Plugin Configurations > USuM Configuration > Connections Per Host.

   

   Esse é o número de conexões por Quantum Network Suite (QNS) com o BD mongo. Isso significa que para 4 QNS, 4*20=80 é o número total de conexões.

   Isso é necessário para atualizações frequentes em mongosfera. Portanto, é recomendável atualizar como 20 por recomendação de QA para um desempenho ideal.

   Configure também Db Read Preference como SecondaryPreferred, o que significa que todo o QNS recebe dados do banco de dados Secundário e somente recebe dados do Primary quando o DB Secundário estiver ocupado. Isso ajuda a otimizar o desempenho, já que o BD principal está menos carregado.

5. Configure o nível de registro raiz apropriado para o Sistema.

   Logs excessivos podem bloquear o processamento no QNS e no nível LB. Portanto, é recomendável configurar o nível de log raiz no aviso ou em níveis mais altos nos arquivos /etc/brodhop/logback.xml e /etc/broadhop/controlcenter/logback.xml.

   Exemplo:

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

   Altere também estes níveis de registro:

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

   Exemplo:

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

   Essas alterações precisam ser replicadas em todas as máquinas virtuais. Execute syncconfig.sh e, em seguida, restartall.sh (ou stopall.sh e, em seguida, startall.sh) para aplicar todas essas alterações.

aviso: Execute essas alterações somente em uma janela Manutenção.