目錄

簡介

必要條件

需求

採用元件

背景資訊

問題

高負載故障排除

因應措施

簡介

本檔案介紹高負載警報調查以及思科原則套件(CPS)中的建議解決方法。

必要條件

需求

思科建議您瞭解以下主題：

- Linux

- 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.不起作用，則在開發團隊的幫助下（如果需要）調整相應的配置檔案。