排除CPS的高記憶體利用率問題

簡介

本檔案介紹對思科原則套件(CPS)的高記憶體使用率問題進行疑難排解的程式。

必要條件

需求

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

• Linux
• CPS
• MongoDB

採用元件

本文中的資訊係根據以下軟體和硬體版本：

• CPS 20.2
• 整合運算系統(UCS)-B
• MongoDB v3.6.17

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

背景資訊

Linux擁有廣泛的工具來支援、管理、監控和部署軟體應用程式。

新增到產品應用程式中的服務和功能可能會佔用大量記憶體。針對Linux伺服器的記憶體最佳化不僅使應用程式運行更平穩、速度更快，而且還降低了資料丟失和伺服器崩潰的風險。

要最佳化Linux電腦的記憶體，首先需要瞭解內存在Linux中的工作方式。從記憶體術語開始，討論Linux如何處理記憶體，然後學習如何排除記憶體故障並防止記憶體問題。

一台電腦可以包含的總記憶體量基於作業系統的體系結構。

Linux中的整個記憶體稱為虛擬記憶體 — 它包括實體記憶體（通常稱為RAM — 隨機訪問記憶體）和交換空間。除非新增更多RAM，否則無法增加系統的實體記憶體。但是，可以通過使用硬碟中的交換空間來增加虛擬記憶體。

RAM確定電腦是否可以處理高記憶體消耗過程。

將來自使用者、電腦進程和硬碟驅動器(HDD)的資料傳送到RAM。如果需要，RAM會將其儲存並傳送回使用者或HDD。如果資料需要永續性，RAM會將其傳送到中央處理單元(CPU)。

要檢查電腦中的可用空間，可以使用free命令。

[root@installer ~]# free -h
total used free shared buff/cache available
Mem: 11Gi 1.3Gi 2.9Gi 105Mi 7.4Gi 10Gi
Swap: 0B 0B 0B
[root@installer ~]#

問題

Linux伺服器會由於各種原因而消耗大量的記憶體。為了快速有效地進行故障排除，首先需要排除最可能的原因。

Java進程：

使用Java實現的應用程式有多種，其不正確的實現或配置可能導致伺服器記憶體使用率較高。兩個最常見的原因是快取和會話快取反模式中的配置錯誤。

快取是應用程式實現高效能的常見方法，但是如果應用不正確，最終可能會損害系統效能。錯誤的配置可能會使快取增長過快，並且為系統中運行的其他進程留出更少的記憶體。

當儲存應用程式的中間狀態時，通常使用會話快取。它允許開發人員按會話儲存使用者，並便於儲存或獲取資料對象值。但是，開發人員之後往往忘記清理會話快取資料。

使用Java中的資料庫時，休眠會話通常用於建立連線和管理伺服器與資料庫之間的會話。但是，當開發人員使用休眠會話時，經常會出現一個錯誤。休眠會話不是為了執行緒安全而隔離，而是包含在同一個超文本傳輸協定(HTTP)會話中。這使得應用程式儲存的狀態超過必要的範圍，並且只有少數使用者，記憶體使用率會大幅增加。

資料庫：

在討論高記憶體消耗過程時，必須提到資料庫。由於應用程式在處理使用者請求時會對資料庫進行多次讀取和寫入，因此我們的資料庫可能會佔用相當多的記憶體。

以MongoDB資料庫為例：為了獲得高效能，它採用快取和索引資料的緩衝機制。如果將資料庫配置為在多次請求資料庫時使用最大記憶體，Linux伺服器中的記憶體很快就會被壓垮。

CPS記憶體消耗可以通過在Grafana圖或其他要監控的工具中使用適當的KPI進行監控。如果任何CPS虛擬機器(VM)上的記憶體消耗增加超過預設閾值90%，則CPS可以為該虛擬機器生成低記憶體警報。通過使用free_mem_per設定，可在CPS部署模板中配置此閾值。

確定導致高記憶體使用率的進程/實用程式：

1.登入到已拋出低記憶體警報的VM。

2.導航到/var/log「目錄」並簽入文top_memory_consuming_processes件，以標識記憶體消耗率較高的進程ID(PID)。

 ******************** Date: Tue May 16 05:06:01 UTC 2023 ***************** 
PID PPID CMD %MEM %CPU RSS PRI STAT PSR WCHAN NI P
9435 1 /usr/bin/java -XX:OnOutOfMe 26.7 77.9 4353796 5 S<l 2 - -15 *
24139 1 /usr/java/default/bin/java 1.0 0.0 174636 20 Sl 3 - 0 *
2905 2862 /usr/sbin/collectd -C /etc/ 1.0 0.2 169104 20 Sl 1 hrtimer_nanosl 0 *
913 1 /usr/lib/systemd/systemd-jo 0.4 0.1 69364 20 Ss 5 do_epoll_wait 0 *
1513 1 /usr/libexec/platform-pytho 0.1 0.0 27912 20 Ssl 5 - 0 *
3379 2905 /usr/sbin/collectd -C /etc/ 0.1 0.0 23716 20 Sl 3 - 0 *
3377 2905 /usr/sbin/collectd -C /etc/ 0.1 0.0 23712 20 Sl 4 - 0 *
3378 2905 /usr/sbin/collectd -C /etc/ 0.1 0.0 23712 20 Sl 5 - 0 *
3380 2905 /usr/sbin/collectd -C /etc/ 0.1 0.0 23712 20 Sl 5 - 0 *
******************** END *****************

3.使用此命令驗證進程，無論它是應用程式進程還是資料庫進程。

#ps -ef | grep <PID>

使用CPS解決高記憶體利用率問題的過程

在Linux中最佳化記憶體非常複雜，修復超載記憶體需要大量努力。

方針1.


檢測和回收快取記憶體：

在某些情況下，低記憶體警報可能是由於Linux記憶體管理在快取中分配對象所致。

評估VM已快取的記憶體大小，並觸發Linux釋放部分快取記憶體。

1.比較兩個或多個CPS虛擬機器上快取的記憶體量，以便在每個VM上運行命令free -m。

[root@dc1-qns01 ~]# free -m
total used free shared buff/cache available
Mem: 15876 5262 4396 808 6217 9628
Swap: 4095 0 4095
[root@dc1-qns01 ~]#

2.要回收部分非活動的快取記憶體，請運行此命令。

#free && sync && echo 3 > /proc/sys/vm/drop_caches && echo "" && free

[root@dc1-qns01 ~]# free -m
total used free shared buff/cache available
Mem: 15876 5016 8782 872 2076 9809
Swap: 4095 0 4095
[root@dc1-qns01 ~]#

請注意：
1.此命令丟棄可能導致輸入輸出(IO)和中央處理器(CPU)使用率臨時增加的快取對象，因此建議在非高峰時間/維護視窗中運行此命令。
2.這是一個非破壞性命令，並且只有未使用的可用記憶體。

如果記憶體不足警報仍未解決，則繼續方法2。

方針2.

如果高記憶體消耗是由任何應用程式進程（如QNS等）造成的。

 1.重新啟動進程。

Command Syntax:

#monit restart <process name>

 2.通過命令驗證記憶體使用率是否減少free-m。

如果記憶體不足警報仍未解決，則繼續方法3。

方針3.

重新啟動已生成警報的虛擬機器，因為通常要執行虛擬機器重新啟動來增加虛擬機器的資源（磁碟記憶體CPU）。

如果已注意到sessionmgr VM的記憶體利用率較高，則繼續執行方法4。

方針4.

1.登入到已發現高記憶體使用率的VM。

2.導航到目錄/var/log，並簽入檔案mongodb-<xxxx>.log，查詢與記憶體消耗和引數相關的警告/消息writeConcernMajorityJournalDefault。

2022-12-13T00:30:39.012+0200 I REPL [replexec-0] ** WARNING: This replica set node is running without journaling enabled but the
2022-12-13T00:30:39.012+0200 I REPL [replexec-0] ** writeConcernMajorityJournalDefault option to the replica set config
2022-12-13T00:30:39.012+0200 I REPL [replexec-0] ** is set to true. The writeConcernMajorityJournalDefault
2022-12-13T00:30:39.012+0200 I REPL [replexec-0] ** option to the replica set config must be set to false
2022-12-13T00:30:39.012+0200 I REPL [replexec-0] ** or w:majority write concerns will never complete.
2022-12-13T00:30:39.012+0200 I REPL [replexec-0] ** In addition, this node's memory consumption may increase until all
2022-12-13T00:30:39.012+0200 I REPL [replexec-0] ** available free RAM is exhausted.

3.登入各自的mongoShell並驗證mongo protocolVersion和writeConcernMajorityJournalDefault的當前值。

set04:PRIMARY> rs.status().optimes.lastCommittedOpTime.t
NumberLong(0)
set04:PRIMARY>

set04:PRIMARY> rs.conf().writeConcernMajorityJournalDefault
set04:PRIMARY>

註：如果輸出未返回none，則必須考慮在默認情況下將writeConcernMajorityJournalDefault該值設定為true。

4.如果protocolVersion是1,writeConcernMajorityJournalDefaulttrue值為，則從各自的mongoShell運行這些命令，將值修writeConcernMajorityJournalDefault改為  false.

#cfg=rs.conf()
#cfg.writeConcernMajorityJournalDefault=false
#rs.reconfig(cfg)

5.驗證值writeConcernMajorityJournalDefault是否已更改為false。

set03:PRIMARY> rs.conf().writeConcernMajorityJournalDefault
false
set03:PRIMARY>

6.通過命令驗證記憶體使用率的減少free-m。