簡介
本文檔介紹如何對處於「警告」或「過於」狀態的sessmgr或aamgr進行故障排除。
概觀
階段作業管理員(Sessmgr) -支援多種階段作業型別的訂戶處理系統,負責處理訂戶交易。Sessmgr通常與AAAManagers配對。
Authorization, Authentication, and Accounting Manager (Aaamgr) -負責執行系統中使用者和管理使用者的所有AAA協定操作和功能。
圖1 :: Staros資源分配
記錄/基本檢查
基本檢查
要收集有關問題的詳細資訊,您需要與使用者驗證以下資訊:
- sessmgr/aaamgr處於「警告」或「過度」狀態的時間有多長?
- 此問題影響多少個會話/聚合?
- 您需要確認sessmgr/aaamgr是否由於記憶體或CPU而處於「警告」或「過度」狀態。
- 您還需要檢查流量是否突然增加,可以透過檢查每個sessmgr的會話數來評估這一點。
透過獲取此資訊,您可以更好地瞭解和解決當前問題。
記錄檔
-
獲取顯示支援詳細資訊(SSD)和捕獲有問題的時間戳的syslog。建議至少在問題發生前2小時收集這些日誌,以確定觸發點。
-
捕獲有問題和無問題的sessmgr/aaamgr的核心檔案。您可以在分析段落中找到此專案的詳細資訊。
分析
步驟 1.透過命令檢查受影響的sessmgr/aaamgr的狀態。
show task resources -
--------- to check detail of sessmgr/aamgr into warn/over state and from the same you also get to know current memory/cpu utlization
Output ::
******** show task resources *******
Monday May 29 08:30:54 IST 2023
task cputime memory files sessions
cpu facility inst used alloc used alloc used allc used allc S status
----------------------- ----------- ------------- --------- ------------- ------
2/0 sessmgr 297 6.48% 100% 604.8M 900.0M 210 500 1651 12000 I good
2/0 sessmgr 300 5.66% 100% 603.0M 900.0M 224 500 1652 12000 I good
2/1 aaamgr 155 0.90% 95% 96.39M 260.0M 21 500 -- -- - good
2/1 aaamgr 170 0.89% 95% 96.46M 260.0M 21 500 -- -- - good
注意:此命令可以檢查每個sessmgr的會話數,如命令輸出中所示。
這兩個指令都有助於檢查自節點重新載入後的最大記憶體使用量:
show task resources max
show task memory max
******** show task memory max *******
Monday May 29 08:30:53 IST 2023
task heap physical virtual
cpu facility inst max max alloc max alloc status
----------------------- ------ ------------------ ------------------ ------
2/0 sessmgr 902 548.6M 66% 602.6M 900.0M 29% 1.19G 4.00G good
2/0 aaamgr 913 68.06M 38% 99.11M 260.0M 17% 713.0M 4.00G good
注意: memory max命令提供自節點重新載入後使用的最大記憶體。此命令可幫助我們辨識與問題相關的任何模式,例如,問題是在最近重新載入後開始的,或者如果最近重新載入允許我們檢查最大記憶體值。另一方面,「show task resources」和「show task resources max」提供類似的輸出,不同之處在於max命令顯示了自重新載入後特定sessmgr/aaamgr使用的記憶體、CPU和會話的最大值。
show subscriber summary apn <apn name> smgr-instance <instance ID> | grep Total
-------------- to check no of subscribers for that particular APN in sessmg
行動計畫
案例 1.由於記憶體使用率高
1. 在重新啟動/終止sessmgr例項之前收集SSD。
2. 收集任何受影響的sessmgr的核心傾印。
task core facility sessmgr instance <instance-value>
3. 在隱藏模式下,針對相同受影響的sessmgr和aaamgr使用這些命令收集堆輸出。
show session subsystem facility sessmgr instance <instance-value> debug-info verbose
show task resources facility sessmgr instance <instance-value>
Heap outputs:
show messenger proclet facility sessmgr instance <instance-value> heap depth 9
show messenger proclet facility sessmgr instance <instance-value> system heap depth 9
show messenger proclet facility sessmgr instance <instance-value> heap
show messenger proclet facility sessmgr instance <instance-value> system
show snx sessmgr instance <instance-value> memory ldbuf
show snx sessmgr instance <instance-value> memory mblk
4. 使用以下命令重新啟動sessmgr任務:
task kill facility sessmgr instance <instance-value>
注意:如果多個會話處於「警告」或「過度」狀態,則建議以2到5分鐘的間隔重新啟動這些會話。首先僅重新啟動2到3個會話,然後等待10到15分鐘,以觀察這些會話是否恢復正常。此步驟有助於評估重新啟動的影響並監視恢復進度。
5. 檢查sessmgr的狀態。
show task resources facility sessmgr instance <instance-value> -------- to check if sessmgr is back in good state
6. 收集另一個SSD。
7. 收集步驟3中提及的所有CLI命令的輸出。
8. 使用步驟2中提及的命令收集任何運行正常sessmgr例項的核心轉儲。
註:要獲取有問題和無問題設施的核心檔案,您有兩個選擇。第一,重新啟動後恢復正常後,您可以收集同一sessmgr的核心檔案。或者,您可以從其他正常的sessmgr捕獲核心檔案。這兩種方法都為分析和故障排除提供了有價值的資訊。
收集堆輸出後,請與Cisco TAC聯絡以查詢確切的堆消耗表。
從這些堆積輸出中,您需要檢查使用更多記憶體的函式。基於此,TAC調查功能利用的目標用途,並確定其用途是否與增加的流量/交易量或其他任何有問題的原因一致。
使用透過指定為Memory-CPU-data-sorting-tool的連結訪問的工具可以對堆輸出進行排序。
注意:在此工具中,有多種選項適用於不同的工具。但是,您需要選擇「堆消耗表」,在其中上傳堆輸出並運行該工具以按排序格式獲取輸出。
案例 2.由於CPU使用率較高
1. 在重新啟動或終止sessmgr例項之前收集SSD。
2. 收集任何受影響的sessmgr的核心傾印。
task core facility sessmgr instance <instance-value>
3. 針對相同受影響的sessmgr/aamgr,以隱藏模式收集這些命令的堆輸出。
show session subsystem facility sessmgr instance <instance-value> debug-info verbose
show task resources facility sessmgr instance <instance-value>
show cpu table
show cpu utilization
show cpu info ------ Display detailed info of CPU.
show cpu info verbose ------ More detailed version of the above
Profiler output for CPU
This is the background cpu profiler. This command allows checking which functions consume
the most CPU time. This command requires CLI test command password.
show profile facility <facility instance> instance <instance ID> depth 4
show profile facility <facility instance> active facility <facility instance> depth 8
4. 使用以下命令重新啟動sessmgr任務:
task kill facility sessmgr instance <instance-value>
5. 檢查sessmgr的狀態。
show task resources facility sessmgr instance <instance-value> -------- to check if sessmgr is back in good state
6. 收集另一個SSD。
7. 收集步驟3中提及的所有CLI命令的輸出。
8. 使用步驟2中提及的命令收集任何運行正常sessmgr例項的核心轉儲。
要分析高記憶體和CPU兩種情況,請檢查批次統計資料以確定流量趨勢是否出現合理成長。
此外,驗證卡/CPU級別統計資料的批次統計資料。