CPSを使用したメモリ高使用率の問題のトラブルシューティング

はじめに

このドキュメントでは、Cisco Policy Suite(CPS)のメモリ高使用率の問題をトラブルシューティングする手順について説明します。

前提条件

要件

次の項目に関する知識があることが推奨されます。

• Linux
• CPS
• MongoDB

使用するコンポーネント

このドキュメントの情報は、次のソフトウェアとハードウェアのバージョンに基づいています。

• CPS 20.2
• ユニファイドコンピューティングシステム(UCS)-B
• MongoDB v3.6.17

このドキュメントの情報は、特定のラボ環境にあるデバイスに基づいて作成されました。このドキュメントで使用するすべてのデバイスは、クリアな（デフォルト）設定で作業を開始しています。本稼働中のネットワークでは、各コマンドによって起こる可能性がある影響を十分確認してください。

背景説明

Linuxには、ソフトウェアアプリケーションをサポート、管理、監視、および導入するための幅広いツールがあります。

製品アプリケーションに追加されたサービスや機能は、大量のメモリを消費する可能性があります。Linuxサーバのメモリ最適化は、アプリケーションの実行をスムーズかつ迅速にするだけでなく、データ損失やサーバのクラッシュのリスクも軽減します。

Linuxマシン用にメモリを最適化するには、まずLinuxでのメモリの動作を理解する必要があります。最初にメモリ用語をいくつか説明し、Linuxがメモリをどのように扱うのかを説明した後、メモリの問題をトラブルシューティングして防止する方法を学びます。

1台のマシンに格納できるメモリの総量は、オペレーティングシステムのアーキテクチャによって異なります。

Linuxのメモリ全体は仮想メモリと呼ばれ、物理メモリ（RAM - Randon Access Memoryとも呼ばれる）とスワップ領域が含まれます。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を使用して実装されたアプリケーションは複数あり、それらの実装や設定が誤っていると、サーバのメモリ使用率が高くなる可能性があります。最も一般的な2つの原因は、キャッシングとセッションキャッシングのアンチパターンの設定が間違っていることです。

キャッシングは、アプリケーションの高パフォーマンスを実現する一般的な方法ですが、誤って適用されると、代わりにシステムパフォーマンスを低下させる可能性があります。設定を誤ると、キャッシュのサイズが急激に大きくなり、システムで実行されている他のプロセスに割り当てるメモリが少なくなる可能性があります。

セッションキャッシングは、アプリケーションの中間状態を保存するときに頻繁に使用されます。開発者はセッションごとにユーザを保存でき、データオブジェクトの値を簡単に保存または取得できます。ただし、開発者は後でセッションキャッシングデータをクリーンアップすることを忘れがちです。

Javaでデータベースを操作する場合、接続を作成し、サーバーとデータベース間のセッションを管理するために、一般的にhibernateセッションが使用されます。しかし、開発者が休止状態のセッションを扱う際に頻繁に発生するエラーがあります。スレッドの安全性のために隔離されるのではなく、休止状態セッションは同じハイパーテキスト転送プロトコル(HTTP)セッションに含まれます。これにより、アプリケーションは必要以上に多くの状態を保存するようになり、少数のユーザではメモリ使用量が大幅に増加します。

データベース:

高いメモリ消費プロセスについて説明する際には、データベースについて言及する必要があります。アプリケーションがユーザ要求を処理する間にデータベースに対して読み取りと書き込みが行われると、データベースは大量のメモリを消費する可能性があります。

参照としてMongoDBデータベースを取る：高いパフォーマンスを実現するために、データのキャッシュとインデックス作成にバッファメカニズムを適用します。データベースに対して複数の要求がある場合に最大メモリを使用するようにデータベースを設定すると、Linuxサーバのメモリがすぐに飽和状態になる可能性があります。

CPSのメモリ消費は、Grafanaグラフの適切なKPIまたは他の監視ツールを使用して監視できます。いずれかのCPS仮想マシン(VM)でメモリ使用量がデフォルトのしきい値である90 %を超えると、CPSはそのVMに対して低メモリアラームを生成できます。このしきい値は、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. 2つ以上のCPS VMでキャッシュされているメモリ量を比較し、各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:

VMの再起動は通常、VM（ディスクメモリCPU）へのリソースを増やすために行われるため、アラームが生成されたVMを再起動します。

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. isprotocolVersion1 writeConcernMajorityJournalDefault およびvalueがtrue(値がある)場合は、それぞれのmongoShellから次のコマンドを実行してwriteConcernMajorityJournalDefault値を  false.

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

5.値がwriteConcernMajorityJournalDefaultfalseに変更されたことを確認します。

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

6.free-mコマンドによるメモリ使用量の削減を確認します。