Résolution des problèmes d'utilisation mémoire élevée avec CPS

Introduction

Ce document décrit la procédure de dépannage des problèmes d'utilisation élevée de la mémoire avec Cisco Policy Suite (CPS).

Conditions préalables

Exigences

Cisco vous recommande de prendre connaissance des rubriques suivantes :

• Linux
• CPS
• base de données mongole

Composants utilisés

Les informations contenues dans ce document sont basées sur les versions de matériel et de logiciel suivantes :

• CPS 20.2
• Système d'informatique unifiée (UCS)-B
• MongoDB v3.6.17

The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. Si votre réseau est en ligne, assurez-vous de bien comprendre l’incidence possible des commandes.

Informations générales

Linux dispose d'un large éventail d'outils pour prendre en charge, gérer, surveiller et déployer des applications logicielles.

Les services et les fonctionnalités ajoutés à l'application du produit peuvent consommer une quantité de mémoire importante. L'optimisation de la mémoire pour les serveurs Linux permet non seulement de rendre les applications plus fluides et plus rapides, mais elle réduit également le risque de perte de données et de pannes de serveur.

Pour optimiser la mémoire pour les machines Linux, vous devez d'abord comprendre comment la mémoire fonctionne sous Linux. Vous commencez avec quelques termes relatifs à la mémoire, discutez de la façon dont Linux gère la mémoire, puis apprenez à dépanner et à éviter les problèmes de mémoire.

La quantité totale de mémoire qu'une machine peut contenir dépend de l'architecture du système d'exploitation.

La mémoire totale de Linux est appelée mémoire virtuelle ; elle inclut la mémoire physique (souvent appelée RAM - Randon Access Memory) et l'espace de permutation. La mémoire physique d'un système ne peut pas être augmentée si nous n'ajoutons pas de mémoire vive. Cependant, la mémoire virtuelle peut être augmentée par l'utilisation d'espace d'échange à partir du disque dur.

La mémoire vive détermine si votre machine peut gérer des processus à forte consommation de mémoire.

Les données de l'utilisateur, des processus de l'ordinateur et du disque dur sont envoyées à la mémoire vive. Si nécessaire, la mémoire vive la stocke et la renvoie à l'utilisateur ou au disque dur. Si les données doivent être persistantes, la mémoire vive les envoie à l'unité centrale (UC).

Pour vérifier l'espace libre disponible sur votre machine, vous pouvez utiliser la commande 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 ~]#

Problème

Un serveur Linux peut consommer une quantité considérable de mémoire pour diverses raisons. Pour un dépannage rapide et efficace, vous devez d'abord éliminer les raisons les plus probables.

Processus Java :

Il existe plusieurs applications implémentées par l'utilisation de Java, et leur implémentation ou leur configuration incorrecte peut entraîner une utilisation élevée de la mémoire sur le serveur. Les deux causes les plus courantes sont une configuration incorrecte dans la mise en cache et la session caching anti-pattern.

La mise en cache est un moyen courant d'atteindre des performances élevées pour les applications, mais lorsqu'elle est appliquée incorrectement, elle peut finir par nuire aux performances du système. Une configuration incorrecte risque de faire croître le cache trop rapidement et de laisser moins de mémoire pour d'autres processus en cours d'exécution dans le système.

La mise en cache de session est souvent utilisée lors du stockage de l'état intermédiaire de l'application. Il permet aux développeurs de stocker les utilisateurs par session et facilite l'enregistrement ou l'obtention de la valeur de l'objet de données. Cependant, les développeurs ont tendance à oublier de nettoyer les données de mise en cache de session par la suite.

Lors de l'utilisation de bases de données dans Java, une session en veille prolongée est généralement utilisée pour créer des connexions et gérer la session entre le serveur et la base de données. Mais il y a une erreur qui se produit fréquemment quand les développeurs travaillent avec des sessions de veille prolongée. Au lieu d'être isolée pour la sécurité des threads, la session en veille prolongée est incluse dans la même session HTTP (Hypertext Transfer Protocol). Cela rend le magasin d'applications plus d'états que nécessaire, et avec seulement quelques utilisateurs, l'utilisation de la mémoire augmente considérablement.

Base de données :

Lorsque vous parlez de processus à forte consommation de mémoire, vous devez mentionner les bases de données. Avec de nombreuses lectures et écritures dans la base de données pendant que l'application gère les demandes des utilisateurs, notre base de données peut consommer beaucoup de mémoire.

Prenez une base de données MongoDB comme référence : Pour atteindre des performances élevées, il applique un mécanisme de tampon pour la mise en cache et l'indexation des données. Si vous configurez la base de données pour qu'elle utilise le maximum de mémoire lorsque vous avez plusieurs requêtes, la mémoire de votre serveur Linux peut rapidement être saturée.

La consommation de mémoire CPS peut être surveillée en utilisant les KPI appropriés dans les graphiques Grafana ou d'autres outils de surveillance. Si la consommation de mémoire dépasse le seuil par défaut de 90 % sur une machine virtuelle CPS, CPS peut générer une alarme de mémoire faible pour cette machine virtuelle. Ce seuil peut être configuré dans le modèle de déploiement CPS à l'aide des paramètres free_mem_per.

Identifiez le processus/l'utilitaire qui entraîne une utilisation élevée de la mémoire :

1. Connectez-vous à la machine virtuelle qui a déclenché une alarme de mémoire insuffisante.

2. Accédez au répertoire/var/log et consignez le top_memory_consuming_processesfichier pour identifier l'ID de processus (PID) avec un pourcentage élevé de consommation de mémoire.

 ******************** 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. Validez le processus au moyen de cette commande, qu'il s'agisse d'un processus d'application ou de base de données.

#ps -ef | grep <PID>

Procédure de résolution des problèmes d'utilisation élevée de la mémoire avec CPS

L'optimisation de la mémoire sous Linux est complexe et la correction d'une mémoire surchargée nécessite des efforts importants.

Approche 1.


Détecter et récupérer la mémoire cache :

Dans certains cas, une alarme de mémoire insuffisante peut résulter de la gestion de la mémoire Linux allouant des objets dans le cache.

Évaluer la quantité de mémoire cache d'une machine virtuelle et déclencher Linux pour libérer une partie de la mémoire cache.

1. Comparez la quantité de mémoire cache sur au moins deux machines virtuelles CPS, pour ce faire, exécutez la commande defree -m sur chaque machine virtuelle.

[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. Pour récupérer une partie de la mémoire cache inactive, exécutez cette commande.

#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 ~]#

Remarque :
1. Cette commande rejette les objets cache qui peuvent entraîner une augmentation temporaire de l'utilisation de l'entrée-sortie (E/S) et de l'unité centrale (UC). Il est donc recommandé d'exécuter cette commande aux heures creuses/fenêtre de maintenance.
2. Il s'agit d'une commande non destructive et seule la mémoire libre n'est pas utilisée.

Si l'alarme de mémoire insuffisante n'est toujours pas résolue, passez à l'approche 2.

Approche 2.

Si une consommation de mémoire élevée est due à l'un des processus d'application tels que QNS, etc.

 1. Redémarrez le processus.

Command Syntax:

#monit restart <process name>

 2. Vérifiez la réduction de l'utilisation de la mémoire par free-m commande.

Si l'alarme de mémoire insuffisante n'est toujours pas résolue, passez à l'approche 3.

Approche 3.

Redémarrez la machine virtuelle pour laquelle des alarmes ont été générées, car le redémarrage de la machine virtuelle est généralement effectué pour augmenter les ressources de la machine virtuelle (CPU de mémoire disque).

Si une utilisation élevée de la mémoire a été constatée pour la machine virtuelle sessionmgr, passez à l'approche 4.

Approche 4.

1. Connectez-vous à la machine virtuelle pour laquelle une utilisation élevée de la mémoire a été constatée.

2. Accédez au répertoire/var/log et consignez le fichiermongodb-<xxxx>.log pour les avertissements/messages liés à la consommation de mémoire et aux writeConcernMajorityJournalDefault paramètres.

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. Connectez-vous à mongoShell respectif et vérifiez les valeurs actuelles de mongo protocolVersion et writeConcernMajorityJournalDefault .

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

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

Remarque : si la sortie ne renvoie aucun, vous devez considérer que la valeur parwriteConcernMajorityJournalDefault défaut est true.

4. Si protocolVersion est 1 et que writeConcernMajorityJournalDefault valeur est true , exécutez ces commandes à partir de mongoShell respectif pour modifier writeConcernMajorityJournalDefault la valeur en  false.

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

5. Vérifiez que la valeur estwriteConcernMajorityJournalDefault passée à false .

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

6. Vérifiez la réduction de l'utilisation de la mémoire par free-m commande.