ワイヤレス : モバイル向け Cisco Quantum ポリシー スイート

より高い TPS で最適 CPS パフォーマンスのためにパラメータを調整して下さい

2015 年 11 月 25 日 - 機械翻訳について
その他のバージョン: PDFpdf | 英語版 (2015 年 7 月 17 日) | フィードバック

概要

この資料はパフォーマンス問題を高トラフィックで診断し、より高い Transactions Per Second (TPS)で最適化されたパフォーマンスのために Cisco ポリシー スイート(CPS)パラメータの調整を助けます。

Vinodkumar Tiwari によって貢献される、Cisco TAC エンジニア。

問題の診断

  1. 2001-DIAMETER_SUCCESS 以外直径結果コードのための強化エンジン ログを分析して下さい。

    例:

    [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

    : この出力は 3002-DIAMETER_UNABLE_TO_DELIVER、5002-DIAMETER_UNKNOWN_SESSION_ID および 5012-DIAMETER_UNABLE_TO_COMPLY を示したものです。

    RFC 3588 の直径結果コードの詳細をチェックできます

    最適化されたパフォーマンスのために設定されない CPS に関しては、大抵 5012- DIAMETER_UNABLE_TO_COMPLY のための高い 数 値を見つけます。

  2. 確認強化エンジンは直径結果コード 5012 の発生数のために記録 します。

    例:

    [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

    5012 の直径結果コードがより高い TPS で高いレートで観察される場合、このプロシージャの追加ログ 確認を続行して下さい。

  3. 0 ms」エラーがポリシーの前に観察され、充満ルール機能(PCRF)後「接続 Wait タイムアウトが結果コードの DiameterResponseMessage を送信 することを強化エンジン ログで確認して下さい: 5012。

    例:

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

top_qps.sh コマンドで CPS バージョン 5.5 および それ 以降で利用可能である問題となる時の真中に CPS システムの TPS をチェックできます。

解決策

  1. デフォルト 20 から 50 に Policy Builder のスレッディング 設定を変更して下さい。 これをするために、Policy Builder にログインし、参照データ > システム > system-1 を > コンフィギュレーションを >Threading 差込式コンフィギュレーション選択して下さい。

    デフォルトで(スレッディング 設定フィールドがブランクのとき) mongo 接続のためのスレッドの数は Policy Builder 設定の 20 です従って低い TPS で動作するとき要求のその量を処理できます。 TPS がこれらのスレッドをである使用中および高めるので要求を実行するためにそれ故により多くのスレッドが必要となります。

    50 のスレッド数は高頻度の要求を処理できることより多くのスレッドが利用できるのでおよそ 5000 TPS を処理して十分です。

    これらはポリシー エンジン スレッドで、ネーム「ルール"と定義され、その名前だけで設定する必要があります。

  2. /etc/broadhop/pcrf/qns.conf に Dmongo.client.thread.maxWaitTime=5000 を追加して下さい。

    例:

    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 は利用可能になる接続のためのミリ秒の時間スレッド待機です。 このパラメータが規定 されなければ 0 ms であるデフォルト値を考慮します。 従って、エラーはテストがより高い TPS にある間、観察されます。 /etc/broadhop/pcrf/qns.conf のこのパラメータの付加はテストが高い TPS にあるとき新しいスレッドが mongo 接続を待っている時間を増加します。

    2000 年は QA 推奨 値で、高い TPS のためにテストされました。 大きい TPS の場合より 5000 5000 ms にパフォーマンスを最適化するためにそれを設定できます。

  3. /etc/broadhop/pcrf/qns.conf に -Dspr.mongo.socket.timeout=5000 を追加して下さい。

    デフォルトで値は 60000 の milliseconds.(60 秒です)。 従って他のスレッドのために利用可能になる長い時間かかります。

    推奨されるコンフィギュレーションは 5000 ミリ秒(5 秒)より速いタイムアウトを促進し、他のスレッドが速く処理するようにするためにです。

  4. デフォルト 5 から Policy Builder の 20 へのホスト値ごとの接続を変更して下さい。 順序 ot ではこれをし、Policy Builder にログインし、参照データ > システム > system-1 を > 差込式コンフィギュレーション > ホストごとの USuM 設定 > 接続選択して下さい。

    これは mongo DB が付いている接続のクォンタム ネットワーク スイート(QNS)数ごとにです。 これは 4 QNS のための、4*20=80 が接続の総数であることを意味します。

    mongodb の頻繁な更新にこれが必要となります。 従って、最適化されたパフォーマンスに関する QA 推奨事項ごとに 20 としてアップデートされることを推奨します。

    またセカンダリ DB が使用中のときだけすべての QNS はセカンダリ データベースからデータを受け取り、プライマリから受け取ることをデータを意味する SecondaryPreferredDb によって読まれるプリファレンスを設定して下さい。 これはプライマリ DB が最も少なくロードされるのでパフォーマンスの最適化を助けます。

  5. システムの適切なルート ログ レベルを設定して下さい。

    余分なログは QNS および LB レベルの処理をブロックできます。従って /etc/brodhop/logback.xml および /etc/broadhop/controlcenter/logback.xml ファイルで両方ルート ログ レベルをで警告するまたは上位レベル設定することが推奨されます。

    例:

    [root@pcrfclient01 ~]#cat /etc/broadhop/logback.xml

    <snip>
    <!-- Configure default Loggers -->
    <root level="warn">
    <appender-ref ref="FILE" />
    <appender-ref ref="SOCKET" />
    </root>

    </configuration>

    またこれらのログ レベルを変更して下さい:

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

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

    例:

    [root@pcrfclient01 ~]# cat /etc/broadhop/controlcenter/logback.xml

    <snip>

    <!-- Configure default Loggers -->
    <root level="warn">
    <appender-ref ref="FILE" />
    </root>

    </configuration>

    すべての仮想マシンを渡って複製されるこれらの変更必要。 syncconfig.sh を行い、次にこれらすべてを適用するために restartall.sh (次にか stopall.sh および startall.sh)変更します行って下さい。

警告: Maintenance ウィンドウだけのこれらの変更を行って下さい。


関連するシスコ サポート コミュニティ ディスカッション

シスコ サポート コミュニティは、どなたでも投稿や回答ができる情報交換スペースです。


Document ID: 119184