當NSO消耗高CPU時收集資料

簡介

本文檔介紹在CPU消耗量增加到100-150%時所需的網路服務協調器(NSO)資料收集。

必要條件

需求

本文件沒有特定需求。

採用元件

本文件所述內容不限於特定軟體和硬體版本。

本文中的資訊是根據特定實驗室環境內的裝置所建立。文中使用到的所有裝置皆從已清除（預設）的組態來啟動。如果您的網路運作中，請確保您瞭解任何指令可能造成的影響。

背景資訊

當從NB處理多個事務時，NSO CPU消耗增加到正常消耗的約100-150%。發生這種情況時，您需要找到降低CPU效能的原因。同時，NSO不會正確響應RESTCONF（如果使用）查詢。

本文重點介紹問題過程中需要收集的所有重要資料，以便正確解決問題並提出一些補救步驟。

要收集的資料

從Linux的角度來看：

• lscpu
• 頂端
• free -h
• vmstat
• cat /proc/meminfo
• pstree -c
• ps auxw | 排序

注意：您可以定期捕獲這些詳細資訊（除了「lscpu」），以便瞭解當請求來自NB時系統的行為。

從NSO角度來看：

• ncs — 狀態 | grep lock
• 啟用進度跟蹤：

  admin@ncs(config)# commit dry-run 

  cli {

      local-node {

          資料進度{

               +全部跟蹤{

               +目標{

               + file progress-all.txt;

               +格式日誌；

               + }

               + }

                }

      }

  }

  admin@ncs(config)# commit

• 每「n」秒捕獲一次下一個資訊（它可以作為指令碼運行）：

seq=0
while ncs —status >& /dev/null; do
ncs —debug-dump ncs.dd.$(seq++);
ncs — 狀態> ncs.stat.$(seq++);
睡眠30;#Configured according  給使用者
完成

接下來是一些補救步驟，也可以執行這些步驟來緩解此問題：

1. 按如下方式限制會話數量（目前您尚未設定此設定）：

<session-limit>

  <會話限制>

    <context>rest</context>

    <max-sessions>100</max-sessions>

  </session-limit>

</session-limits>

b.啟用稽核規則，以確定NSO進程是否已被某種東西破壞，並在情況發生時將其記錄在audit.log中：

sudo auditctl -a exit，always -F arch=b64 -S kill -k audit_kill

若要進行故障排除和分析，您需要以前的詳細資訊以及audit.log 、 devel.log（最好設定為level=trace）、 ncs-java-vm.log和NB日誌。

其他資訊

問：NSO實際上如何處理NB應用程式發出的RESTCONF請求？

A.北向應用程式傳送RESTCONF請求時，會將其視為基於NSO的唯一事務。這意味著NSO可以鎖定整個CDB，並且在當前事務完成之前不允許任何其他事務。如果這樣做，將保留NSO的事務性質，並確保在出現任何問題時可以執行回滾。

NSO commit-queue可以在每個後續事務請求完成時對其進行處理，並且可以在事務開始/完成時跟蹤devely.log中的事務鎖。在使用情況下，如果執行大量查詢，這會在NSO中引入大量開銷；而且提交隊列中的事務的時間比預期長。如果對RESTCONF請求進行分組，則吞吐量會增加，因為事務開銷會減少。此外，NSO可以在單個事務內同時執行儘可能多的操作。例如，如果一個事務包含2個裝置配置更改，則NSO可以鎖定CDB，同時聯絡和編輯兩個裝置，然後完成該事務。這與每個包含1個裝置且兩者都更改的2個事務相反；因為NSO可以鎖定第一個事務的CDB，編輯第一個裝置，完成該事務，然後對第二個裝置執行相同的步驟。

相關資訊