簡介
本檔案介紹高負載警報調查以及思科原則套件(CPS)中的建議解決方法。
必要條件
需求
思科建議您瞭解以下主題：
思科還建議您對CPS CLI擁有超級使用者許可權。
採用元件
本檔案中的資訊是根據CPS 19.4
本文中的資訊是根據特定實驗室環境內的裝置所建立。文中使用到的所有裝置皆從已清除（預設）的組態來啟動。如果您的網路運作中，請確保您瞭解任何指令可能造成的影響。
背景資訊
負載平均值是Linux伺服器在定義時間段內的平均系統負載。換句話說，它是伺服器的CPU需求，包括活動執行緒和空閒執行緒的總和。
測量平均負載對於瞭解伺服器效能至關重要；如果超載，您必須終止或最佳化消耗大量資源的進程，或者提供更多資源以平衡工作負載。
通常，top或uptime命令會提供伺服器的平均負載輸出，如下所示：
[root@cps-194-aio-mob ~]# uptime
11:41:08 up 6 days, 5:20, 2 users, load average: 0.71, 0.35, 0.24
[root@cps-194-aio-mob ~]#
[root@cps-194-aio-mob ~]# top
top - 12:17:26 up 6 days, 5:56, 2 users, load average: 0.09, 0.12, 0.13
Tasks: 185 total, 1 running, 183 sleeping, 0 stopped, 1 zombie
%Cpu(s): 0.8 us, 0.8 sy, 0.0 ni, 98.4 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st
KiB Mem : 12137348 total, 4128956 free, 5219860 used, 2788532 buff/cache
KiB Swap: 4194300 total, 4194300 free, 0 used. 6586848 avail Mem
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
7070 root 5 -15 8263680 1.3g 21728 S 12.5 11.6 561:38.74 java
1 root 20 0 191384 4320 2620 S 0.0 0.0 3:11.17 systemd
這些數字是系統負載在1、5和15分鐘的平均值。
在進一步操作之前，讓我們瞭解一下所有類Unix系統中的以下兩個重要短語：
系統負載/CPU負載 — 是Linux系統中CPU使用過或使用不足的一種度量；cpu執行或處於空閒狀態的進程數。
平均負載 — 是在給定時間段1、5和15分鐘內計算的平均系統負載。
問題
當CPS VM的負載平均值超出定義的閾值時，將生成HighLoadAlert。HighLoad警報的閾值定義為VM中的1.5*No CPU。/etc/snmp/snmpd.conf中提供了此配置：
load 12 12 12
# 1, 5 and 15 Minute Load Averages (UCD-SNMP-MIB la)
proxy -v 2c -c broadhop localhost .1.3.6.1.4.1.26878.200.3.2.70.1.4 .1.3.6.1.4.1.2021.10.1.5.1
proxy -v 2c -c broadhop localhost .1.3.6.1.4.1.26878.200.3.2.70.1.5 .1.3.6.1.4.1.2021.10.1.5.2
proxy -v 2c -c broadhop localhost .1.3.6.1.4.1.26878.200.3.2.70.1.6 .1.3.6.1.4.1.2021.10.1.5.3
proxy -v 2c -c broadhop localhost .1.3.6.1.4.1.26878.200.3.2.70.1.4.0 .1.3.6.1.4.1.2021.10.1.5.1
proxy -v 2c -c broadhop localhost .1.3.6.1.4.1.26878.200.3.2.70.1.5.0 .1.3.6.1.4.1.2021.10.1.5.2
proxy -v 2c -c broadhop localhost .1.3.6.1.4.1.26878.200.3.2.70.1.6.0 .1.3.6.1.4.1.2021.10.1.5.3
高負載警報示例：
2021-10-31T14:25:36.572711+05:30 XXXXX-lb01 snmptrapd[5717]: 2021-10-31 14:25:36 pcrfclient01 [UDP: [XX.XX.XX.XX]:46046->[XX.XX.XX.XX]:162]:#012DISMAN-EVENT-MIB::sysUpTimeInstance = 99307800#011SNMPv2-MIB::snmpTrapOID.0 = OID: DISMAN-EVENT-MIB::mteTriggerFired#011DISMAN-EVENT-MIB::mteHotTrigger.0 = STRING: HighLoadAlert#011DISMAN-EVENT-MIB::mteHotTargetName.0 = STRING: #011DISMAN-EVENT-MIB::mteHotContextName.0 = STRING: #011DISMAN-EVENT-MIB::mteHotOID.0 = OID: UCD-SNMP-MIB::laErrorFlag.1#011DISMAN-EVENT-MIB::mteHotValue.0 = INTEGER: 1#011UCD-SNMP-MIB::laNames.1 = STRING: Load-1#011UCD-SNMP-MIB::laErrMessage.1 = STRING: 1 min Load Average too high (= 64.84)
高負載故障排除
在進一步調查之前，確保受影響虛擬機器具有符合標準的CPU計數。這可以通過相應的CPS安裝指南完成，其中提到每個VM所需的CPU數量。
只有一個Linux命令組合提供進程平均負載和CPU利用率，該命令是top命令。為了確定導致HighLoad的進程，必須在涵蓋HighLoad例項的特定持續時間內定期在受影響虛擬機器中執行top命令。此命令每3秒提供一次top輸15000（您可以根據您的方案更改次數）：
#top -b -n15000 >> top.txt &
[root@cps-194-aio-mob ~]# top
top - 09:32:11 up 7 days, 3:11, 3 users, load average: 0.13, 0.16, 0.15
Tasks: 184 total, 1 running, 182 sleeping, 0 stopped, 1 zombie
%Cpu(s): 0.8 us, 0.8 sy, 0.0 ni, 98.4 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st
KiB Mem : 12137348 total, 3911352 free, 5262096 used, 2963900 buff/cache
KiB Swap: 4194300 total, 4194300 free, 0 used. 6520076 avail Mem
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
7014 redis 20 0 147356 2372 1184 S 6.7 0.0 48:15.15 redis-server
7070 root 5 -15 8263688 1.4g 21744 S 6.7 11.8 645:12.88 java
1 root 20 0 191384 4320 2620 S 0.0 0.0 3:38.65 systemd
2 root 20 0 0 0 0 S 0.0 0.0 0:00.12 kthreadd
3 root 20 0 0 0 0 S 0.0 0.0 0:04.51 ksoftirqd/0
5 root 0 -20 0 0 0 S 0.0 0.0 0:00.00 kworker/0:0H
7 root rt 0 0 0 0 S 0.0 0.0 0:01.76 migration/0
8 root 20 0 0 0 0 S 0.0 0.0 0:00.00 rcu_bh
9 root 20 0 0 0 0 S 0.0 0.0 11:53.47 rcu_sched
將HighLoadAlert例項與top命令輸出緊密關聯並進行比較，確定警報發生時高利用率CPU的進程。
然後要收集有關該進程的詳細資訊，請運行以下命令：
Command Template:
#ps -ef | grep {PID}
Sample command:
[root@cps-194-aio-mob ~]# ps -ef | grep 7070
root 7070 1 6 Dec02 ? 12:17:06 /usr/bin/java -server -XX:+UnlockDiagnosticVMOptions -XX:+UnsyncloadClass -Xms2048m -Xmx2048m -javaagent:/opt/broadhop/qns-1/bin/jmxagent.jar -Dqns.config.dir=/etc/broadhop/pcrf -Dqns.instancenum=1 -Dlogback.configurationFile=/etc/broadhop/logback.xml -Djmx.port=9045 -Dorg.osgi.service.http.port=8080 -Dsnmp.port=1161 -Dcom.broadhop.run.systemId=lab -Dcom.broadhop.run.clusterId=cluster-1 -Dcom.broadhop.run.instanceId=cps-194-aio-mob-1 -Dcom.broadhop.config.url=http://pcrfclient01/repos/run/ -Dcom.broadhop.repository.credentials.isEncrypted=true -Dcom.broadhop.repository.credentials=qns-svn/3300901EA069E81CE29D4F77DE3C85FA@pcrfclient01 -Dcom.broadhop.referencedata.local.location=/var/broadhop/checkout -DdisableJms -DrefreshOnChange=true -DenableRuntimePolling=true -DdefaultNasIp=127.0.0.1 -Xdebug -Xrunjdwp:transport=dt_socket,server=y,suspend=n,address=1044 -Dua.version.2.0.compatible=true -Denable.compression=true -Denable.dictionary.compression=true -DuseZlibCompression=true -DenableBestCompression=true -DenableQueueSystem=false -Dredis.keystore.connection.string=lb01:lb01:6379:6379 -DbrokerUrl=failover:(tcp://lb01:61616,tcp://lb02:61616)?randomize=false -DjmsFlowControlHost=lb02 -DjmsFlowControlPort=9045 -Dosgi.framework.activeThreadType=normal -jar /opt/broadhop/qns-1/plugins/org.eclipse.equinox.launcher_1.1.0.v20100507.jar -console cps-194-aio-mob:9091 -clean -os linux -ws gtk -arch x86_64
root 7846 7587 0 11:00 pts/0 00:00:00 grep --color=auto 7070
[root@cps-194-aio-mob ~]#
因應措施
確定導致HighLoadAlert的進程後，可以考慮以下解決方法：
步驟1.重新啟動進程。
#monit stop {Process Name}
Wait for 10 secs
#monit start {Process Name}
步驟2.如果流程包括回滾，則驗證任何具有調試日誌級別的記錄器，並將記錄器的日誌級別從調試更改為警告/錯誤。
步驟3.如果步驟1.和步驟2.不起作用，則在開發團隊的幫助下（如果需要）調整相應的配置檔案。
意見