Table des matières

Introduction

Conditions préalables

Exigences

Que sont les pages énormes ?

Description du problème

Analyse

Dépannage

Introduction

Ce document décrit la procédure à suivre pour analyser le problème lié à l'utilisation élevée de la mémoire dans les noeuds de calcul Cisco Virtualized Infrastructure Manager (CVIM).

Conditions préalables

Exigences

Cisco vous recommande d'avoir des connaissances sur la gestion de la mémoire et les pages énormes sous Linux.

Que sont les pages énormes ?

L'activation de l'option ImmensesPages permet au système d'exploitation de prendre en charge des pages mémoire plus grandes que la taille par défaut (généralement 4 Ko). L'utilisation de très grandes tailles de page peut améliorer les performances du système en réduisant les ressources système nécessaires pour accéder aux entrées de la table des pages. Par conséquent, les pages gigantesques sont généralement utilisées pour réduire la latence de la mémoire.

Description du problème

Alertes d'utilisation élevée de la mémoire sur les noeuds de calcul CVIM alors que CVIM n'a déclenché aucune alerte. Les alertes relatives à l'utilisation de la mémoire peuvent être envoyées via un outil de surveillance ou un tableau de bord tiers.

Analyse

Il est observé que l'utilisation élevée de la mémoire dans le système d'exploitation, conformément à la free et  sar sortie de la commande sous Linux.

[root@cvim-computex ~]# free -m

total    used    free   shared  buff/cache  available

Mem:           385410  365882   7602     3621       11925        8411

Swap:            2047       0   2047

[root@cvim-computex ~]# sar -r

Linux 4.18.0-193.81.1.el8_2.x86_64 (pod1-compute4.mx2) 08/24/2023 _x86_64_ (112 CPU)

12:00:46 AM kbmemfree kbavail kbmemused %memused kbbuffers kbcached kbcommit %commit kbactive kbinact kbdirty

12:10:34 AM   7493576 7871200 387166528    98.10      4240  9334356 12893752    3.25  4891940 6325076      68

12:20:11 AM   7503208 7883396 387156896    98.10      4240  9337364 12872708    3.24  4885008 6328096      16

12:30:34 AM   7485648 7869540 387174456    98.10      4240  9340556 12902748    3.25  4892948 6331276      36

12:40:46 AM   7494396 7880940 387165708    98.10      4240  9343636 12866964    3.24  4886908 6334364      20

12:50:34 AM   7479616 7869772 387180488    98.10      4240  9346720 12905156    3.25  4892408 6337444      56

01:00:46 AM   7490304 7883016 387169800    98.10      4240  9349832 12860152    3.24  4885308 6340500      56

01:10:34 AM   7472248 7868672 387187856    98.11      4240  9352836 12896932    3.25  4892604 6343556      28

01:20:46 AM   7484308 7883276 387175796    98.10      4240  9355948 12867972    3.24  4885172 6346676      16

01:30:34 AM   7475092 7869596 387185012    98.11      4240  9350840 12904328    3.25  4892448 6341556      44

01:40:46 AM   7485436 7882508 387174668    98.10      4240  9353932 12864252    3.24  4885148 6344660      56

01:50:34 AM   7468840 7869520 387191264    98.11      4240  9357036 12907464    3.25  4893552 6347752     164

02:00:46 AM   7479076 7882428 387181028    98.10      4240  9360124 12861892    3.24  4886044 6350844      68

Utilisez  ps  pour identifier les processus qui utilisent le plus de mémoire.

[root@cvim-computex ~]# ps -aux --sort -rss

USER         PID %CPU %MEM VSZ       RSS TTY STAT  START TIME COMMAND

root      328199 1207  0.2 541893584 ?   RLl Mar12 2948779:31 /usr/bin/vpp -c /etc/vpp/vpp.conf

root        1829  0.0  0.0 379024  227692 ?  Ss    Mar12 14:21 /usr/lib/systemd/systemd-journald

Vérifiez l'utilisation de la mémoire du conteneur en consultant les statistiques à l'aide de la  podman  ou  docker  de l'assistant.

[root@cvim-computex ~]# podman stats

ID            NAME                 CPU % MEM USAGE / LIMIT MEM % NET IO  BLOCK IO          PIDS

2f8fdc4b63a4 fluentd_31902         --    301.2MB / 404.1GB 0.07% -- / -- 9.265MB / 89.68GB 75

34d806a30733 novalibvirt_31902     --    42.16MB / 404.1GB 0.01% -- / -- 589.8kB / 22.13MB 44

48292d2fa956 novassh_31902         --    5.882MB / 404.1GB 0.00% -- / -- 475.1kB / 167.3MB 2

7b2ce84e86b3 novacompute_31902     --    231.8MB / 404.1GB 0.06% -- / -- 761.9kB / 2.43GB  49

89c01c14ef3f neutron_vpp_31902     --    1.209GB / 404.1GB 0.30% -- / -- 0B / 7.66MB       35

Sur la base du résultat fourni, il apparaît qu'aucun processus ne présente une utilisation élevée de la mémoire. En outre, les conteneurs semblent utiliser une faible quantité de mémoire.

Les  free  indique toujours une utilisation élevée de la mémoire.

root@cvim-computex ~]# free -m

total     used   free   shared    buff/cache available

Mem:        385410   366751  7310    3496          11348   7696

Swap:         2047        5  2042

[root@cvim-computex ~]#

Dépannage

Pour comprendre cette utilisation de la mémoire, la connaissance de la mémoire HugePage est essentielle.

Si le pod est activé avec HugePages, veillez à utiliser la bonne saveur, afin de vous assurer que la mémoire système n'est pas utilisée pour lancer les machines virtuelles. L'utilisation de la mémoire système pour les machines virtuelles peut entraîner l'instabilité de CVIM, car la charge de travail et l'infrastructure sont en concurrence pour les ressources réservées à l'infrastructure.

Consultez les pages gigantesques :

[root@cvim-computex ~]# tail /sys/devices/system/node/node0/hugepages/hugepages-2048kB/nr_hugepages

90001

[root@cvim-computex ~]# tail /sys/devices/system/node/node0/hugepages/hugepages-1048576kB/nr_hugepages

0

[root@cvim-computex ~]# tail /sys/devices/system/node/node1/hugepages/hugepages-2048kB/nr_hugepages

90000

[root@cvim-computex ~]# tail /sys/devices/system/node/node1/hugepages/hugepages-1048576kB/nr_hugepages

0

[root@cvim-computex ~]#

nr_hugepages  représente le nombre total de pagesEncombrantes.

(90001 + 90000) x 2M = 360 Go est réservé à HugePage.

Notez également que 5 % de la mémoire physique totale est réservée aux pages de mémoire normales (4 Ko) pour l'utilisation du système d'exploitation, même si 100 % de HugePage est configuré.

385 Go (total libre) - 360 Go (réservé pour HugePage) = 25 Go est réservé pour les pages normales.

Donc, une utilisation élevée de la mémoire, comme observé dans la  sar   et  free est attendue.

Utilisez la commande mentionnée pour vérifier l'utilisation réelle de la mémoire.

[root@mgmt-node ~]# ip -br -4 a s br_api

br_api UP 10.x.x.x/24

[root@mgmt-node ~]# curl -sS -g -u admin:password --cacert /var/www/mercury/mercury-ca.crt https://10.x.x.x:9090/api/v1/query --data-urlencode 'query=100 * (mem_free + mem_buffered + mem_cached) / ((mem_total - sum without(NUMAnode, pagename, pagesize) (hugepages_nr)) or mem_total)' | python -mjson.tool

sample output:

{

"status": "success",

"data": {

"resultType": "vector",

"result": [

{

"metric": {

"host": "cvim-computex",

"instance": "10.x.x.x:9273",

"job": "telegraf",

"node_type": "compute"

},

"value": [

1693479719.383,

"76.16486394450624" --> Actual available memory percentage.

]

},

{

"metric": {

"host": "cvim-computey",

"instance": "10.x.x.x:9273",

"job": "telegraf",

"node_type": "compute"

},

"value": [

1693479719.383,

"76.63431887455388"

CVIM déclenche une alerte uniquement lorsque la mémoire disponible est inférieure à 10 %.

Nom d'alerte - mem_available_percent

La mémoire système disponible est inférieure à 10 %. La mémoire de 4000 pages standard est utilisée par le système et les services d'infrastructure OpenStack et n'inclut pas les pages volumineuses. Cette alerte peut indiquer une quantité insuffisante de mémoire vive ou une utilisation anormale de la mémoire par le système ou l'infrastructure.