Red Hat Summit Red Hat SummitSupportConsoleDéveloppeursCommencer un essaiContact

15.4. Exécution des tests de latence

Exécutez les tests de latence du cluster pour valider le réglage des nœuds pour votre charge de travail Cloud-native Network Functions (CNF).

Important

Always exécuter les tests de latence avec DISCOVERY_MODE=true. Si vous ne le faites pas, la suite de tests apportera des modifications à la configuration du cluster en cours d'exécution.

Note

Lorsque vous exécutez les commandes podman en tant qu'utilisateur non root ou non privilégié, les chemins de montage peuvent échouer avec des erreurs permission denied. Pour que la commande podman fonctionne, ajoutez :Z à la création des volumes ; par exemple, -v $(pwd)/:/kubeconfig:Z. Cela permet à podman d'effectuer le réétiquetage SELinux approprié.

Procédure

  1. Ouvrez une invite dans le répertoire contenant le fichier kubeconfig.

    Vous fournissez à l'image de test un fichier kubeconfig dans le répertoire courant et la variable d'environnement $KUBECONFIG correspondante, montée par l'intermédiaire d'un volume. Cela permet au conteneur en cours d'exécution d'utiliser le fichier kubeconfig depuis l'intérieur du conteneur.

  2. Exécutez les tests de latence en entrant la commande suivante : 

    $ podman run -v $(pwd)/:/kubeconfig:Z -e KUBECONFIG=/kubeconfig/kubeconfig \
-e LATENCY_TEST_RUN=true -e DISCOVERY_MODE=true -e FEATURES=performance registry.redhat.io/openshift4/cnf-tests-rhel8:v4.12 \
/usr/bin/test-run.sh -ginkgo.focus="\[performance\]\ Latency\ Test"
  3. En option : Ajoutez -ginkgo.dryRun pour exécuter les tests de latence en mode "dry-run". Ceci est utile pour vérifier ce que les tests exécutent.
  4. Facultatif : Ajoutez -ginkgo.v pour exécuter les tests avec une verbosité accrue.

  5. Facultatif : Pour effectuer les tests de latence en fonction d'un profil de performance spécifique, exécutez la commande suivante, en remplaçant les valeurs appropriées : 

    $ podman run -v $(pwd)/:/kubeconfig:Z -e KUBECONFIG=/kubeconfig/kubeconfig \
-e LATENCY_TEST_RUN=true -e FEATURES=performance -e LATENCY_TEST_RUNTIME=600 -e MAXIMUM_LATENCY=20 \
-e PERF_TEST_PROFILE=<performance_profile> registry.redhat.io/openshift4/cnf-tests-rhel8:v4.12 \
/usr/bin/test-run.sh -ginkgo.focus="[performance]\ Latency\ Test"

    où :

    <performance_profile>
    Est le nom du profil de performance sur lequel vous souhaitez effectuer les tests de latence.
    Important

    Pour que les résultats des tests de latence soient valables, les tests doivent être effectués pendant au moins 12 heures.

15.4.1. Exécution de hwlatdetect
Copier lien

L'outil hwlatdetect est disponible dans le paquetage rt-kernel avec un abonnement normal à Red Hat Enterprise Linux (RHEL) 8.x.

Important

Always exécuter les tests de latence avec DISCOVERY_MODE=true. Si vous ne le faites pas, la suite de tests apportera des modifications à la configuration du cluster en cours d'exécution.

Note

Lorsque vous exécutez les commandes podman en tant qu'utilisateur non root ou non privilégié, les chemins de montage peuvent échouer avec des erreurs permission denied. Pour que la commande podman fonctionne, ajoutez :Z à la création des volumes ; par exemple, -v $(pwd)/:/kubeconfig:Z. Cela permet à podman d'effectuer le réétiquetage SELinux approprié.

Conditions préalables

  • Vous avez installé le noyau temps réel dans le cluster.
  • Vous vous êtes connecté à registry.redhat.io avec vos identifiants du portail client.

Procédure

  • Pour exécuter les tests hwlatdetect, lancez la commande suivante, en remplaçant les valeurs des variables par celles qui conviennent : 

    $ podman run -v $(pwd)/:/kubeconfig:Z -e KUBECONFIG=/kubeconfig/kubeconfig \
-e LATENCY_TEST_RUN=true -e DISCOVERY_MODE=true -e FEATURES=performance -e ROLE_WORKER_CNF=worker-cnf \
-e LATENCY_TEST_RUNTIME=600 -e MAXIMUM_LATENCY=20 \
registry.redhat.io/openshift4/cnf-tests-rhel8:v4.12 \
/usr/bin/test-run.sh -ginkgo.v -ginkgo.focus="hwlatdetect"

    Le test hwlatdetect dure 10 minutes (600 secondes). Le test se déroule avec succès lorsque la latence maximale observée est inférieure à MAXIMUM_LATENCY (20 μs).

    Si les résultats dépassent le seuil de latence, le test échoue.

    Important

    Pour obtenir des résultats valables, le test doit durer au moins 12 heures.

    Exemple de sortie de panne

    running /usr/bin/cnftests -ginkgo.v -ginkgo.focus=hwlatdetect
I0908 15:25:20.023712      27 request.go:601] Waited for 1.046586367s due to client-side throttling, not priority and fairness, request: GET:https://api.hlxcl6.lab.eng.tlv2.redhat.com:6443/apis/imageregistry.operator.openshift.io/v1?timeout=32s
Running Suite: CNF Features e2e integration tests
=================================================
Random Seed: 1662650718
Will run 1 of 194 specs

[...]

• Failure [283.574 seconds]
[performance] Latency Test
/remote-source/app/vendor/github.com/openshift/cluster-node-tuning-operator/test/e2e/performanceprofile/functests/4_latency/latency.go:62
  with the hwlatdetect image
  /remote-source/app/vendor/github.com/openshift/cluster-node-tuning-operator/test/e2e/performanceprofile/functests/4_latency/latency.go:228
    should succeed [It]
    /remote-source/app/vendor/github.com/openshift/cluster-node-tuning-operator/test/e2e/performanceprofile/functests/4_latency/latency.go:236

    Log file created at: 2022/09/08 15:25:27
    Running on machine: hwlatdetect-b6n4n
    Binary: Built with gc go1.17.12 for linux/amd64
    Log line format: [IWEF]mmdd hh:mm:ss.uuuuuu threadid file:line] msg
    I0908 15:25:27.160620       1 node.go:39] Environment information: /proc/cmdline: BOOT_IMAGE=(hd1,gpt3)/ostree/rhcos-c6491e1eedf6c1f12ef7b95e14ee720bf48359750ac900b7863c625769ef5fb9/vmlinuz-4.18.0-372.19.1.el8_6.x86_64 random.trust_cpu=on console=tty0 console=ttyS0,115200n8 ignition.platform.id=metal ostree=/ostree/boot.1/rhcos/c6491e1eedf6c1f12ef7b95e14ee720bf48359750ac900b7863c625769ef5fb9/0 ip=dhcp root=UUID=5f80c283-f6e6-4a27-9b47-a287157483b2 rw rootflags=prjquota boot=UUID=773bf59a-bafd-48fc-9a87-f62252d739d3 skew_tick=1 nohz=on rcu_nocbs=0-3 tuned.non_isolcpus=0000ffff,ffffffff,fffffff0 systemd.cpu_affinity=4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43,44,45,46,47,48,49,50,51,52,53,54,55,56,57,58,59,60,61,62,63,64,65,66,67,68,69,70,71,72,73,74,75,76,77,78,79 intel_iommu=on iommu=pt isolcpus=managed_irq,0-3 nohz_full=0-3 tsc=nowatchdog nosoftlockup nmi_watchdog=0 mce=off skew_tick=1 rcutree.kthread_prio=11 + +
    I0908 15:25:27.160830       1 node.go:46] Environment information: kernel version 4.18.0-372.19.1.el8_6.x86_64
    I0908 15:25:27.160857       1 main.go:50] running the hwlatdetect command with arguments [/usr/bin/hwlatdetect --threshold 1 --hardlimit 1 --duration 100 --window 10000000us --width 950000us]
    F0908 15:27:10.603523       1 main.go:53] failed to run hwlatdetect command; out: hwlatdetect:  test duration 100 seconds
       detector: tracer
       parameters:
            Latency threshold: 1us
    1 
    
            Sample window:     10000000us
            Sample width:      950000us
         Non-sampling period:  9050000us
            Output File:       None

    Starting test
    test finished
    Max Latency: 326us
    2 
    
    Samples recorded: 5
    Samples exceeding threshold: 5
    ts: 1662650739.017274507, inner:6, outer:6
    ts: 1662650749.257272414, inner:14, outer:326
    ts: 1662650779.977272835, inner:314, outer:12
    ts: 1662650800.457272384, inner:3, outer:9
    ts: 1662650810.697273520, inner:3, outer:2

[...]

JUnit report was created: /junit.xml/cnftests-junit.xml


Summarizing 1 Failure:

[Fail] [performance] Latency Test with the hwlatdetect image [It] should succeed
/remote-source/app/vendor/github.com/openshift/cluster-node-tuning-operator/test/e2e/performanceprofile/functests/4_latency/latency.go:476

Ran 1 of 194 Specs in 365.797 seconds
FAIL! -- 0 Passed | 1 Failed | 0 Pending | 193 Skipped
--- FAIL: TestTest (366.08s)
FAIL

    1
    Vous pouvez configurer le seuil de latence en utilisant les variables d'environnement MAXIMUM_LATENCY ou HWLATDETECT_MAXIMUM_LATENCY.
    2
    Valeur maximale de la latence mesurée pendant le test.
Exemple de résultats du test hwlatdetect

Vous pouvez capturer les types de résultats suivants :

  • Les résultats bruts qui sont recueillis après chaque exécution pour créer un historique de l'impact de toute modification apportée tout au long de l'essai.
  • L'ensemble combiné des tests bruts avec les meilleurs résultats et paramètres de configuration.

Exemple de bons résultats

hwlatdetect: test duration 3600 seconds
detector: tracer
parameters:
Latency threshold: 10us
Sample window: 1000000us
Sample width: 950000us
Non-sampling period: 50000us
Output File: None

Starting test
test finished
Max Latency: Below threshold
Samples recorded: 0

L'outil hwlatdetect ne fournit un résultat que si l'échantillon dépasse le seuil spécifié.

Exemple de mauvais résultats

hwlatdetect: test duration 3600 seconds
detector: tracer
parameters:Latency threshold: 10usSample window: 1000000us
Sample width: 950000usNon-sampling period: 50000usOutput File: None

Starting tests:1610542421.275784439, inner:78, outer:81
ts: 1610542444.330561619, inner:27, outer:28
ts: 1610542445.332549975, inner:39, outer:38
ts: 1610542541.568546097, inner:47, outer:32
ts: 1610542590.681548531, inner:13, outer:17
ts: 1610543033.818801482, inner:29, outer:30
ts: 1610543080.938801990, inner:90, outer:76
ts: 1610543129.065549639, inner:28, outer:39
ts: 1610543474.859552115, inner:28, outer:35
ts: 1610543523.973856571, inner:52, outer:49
ts: 1610543572.089799738, inner:27, outer:30
ts: 1610543573.091550771, inner:34, outer:28
ts: 1610543574.093555202, inner:116, outer:63

La sortie de hwlatdetect montre que plusieurs échantillons dépassent le seuil. Cependant, la même sortie peut indiquer des résultats différents en fonction des facteurs suivants :

  • La durée du test
  • Le nombre de cœurs de l'unité centrale
  • Paramètres du micrologiciel de l'hôte
Avertissement

Avant de procéder au test de latence suivant, assurez-vous que la latence signalée par hwlatdetect respecte le seuil requis. Pour résoudre les problèmes de latence liés au matériel, vous devrez peut-être contacter le service d'assistance du fournisseur du système.

Les pics de latence ne sont pas tous liés au matériel. Veillez à régler le microprogramme de l'hôte pour répondre aux exigences de votre charge de travail. Pour plus d'informations, voir Définition des paramètres du microprogramme pour l'optimisation du système.

15.4.2. Test cyclique en cours d'exécution
Copier lien

L'outil cyclictest mesure la latence de l'ordonnanceur du noyau en temps réel sur les unités centrales spécifiées.

Important

Always exécuter les tests de latence avec DISCOVERY_MODE=true. Si vous ne le faites pas, la suite de tests apportera des modifications à la configuration du cluster en cours d'exécution.

Note

Lorsque vous exécutez les commandes podman en tant qu'utilisateur non root ou non privilégié, les chemins de montage peuvent échouer avec des erreurs permission denied. Pour que la commande podman fonctionne, ajoutez :Z à la création des volumes ; par exemple, -v $(pwd)/:/kubeconfig:Z. Cela permet à podman d'effectuer le réétiquetage SELinux approprié.

Conditions préalables

  • Vous vous êtes connecté à registry.redhat.io avec vos identifiants du portail client.
  • Vous avez installé le noyau temps réel dans le cluster.
  • Vous avez appliqué un profil de performance de cluster en utilisant Node Tuning Operator.

Procédure

  • Pour effectuer l'opération cyclictest, exécutez la commande suivante, en remplaçant les valeurs des variables par d'autres, le cas échéant : 

    $ podman run -v $(pwd)/:/kubeconfig:Z -e KUBECONFIG=/kubeconfig/kubeconfig \
-e LATENCY_TEST_RUN=true -e DISCOVERY_MODE=true -e FEATURES=performance -e ROLE_WORKER_CNF=worker-cnf \
-e LATENCY_TEST_CPUS=10 -e LATENCY_TEST_RUNTIME=600 -e MAXIMUM_LATENCY=20 \
registry.redhat.io/openshift4/cnf-tests-rhel8:v4.12 \
/usr/bin/test-run.sh -ginkgo.v -ginkgo.focus="cyclictest"

    La commande exécute l'outil cyclictest pendant 10 minutes (600 secondes). Le test s'exécute avec succès lorsque la latence maximale observée est inférieure à MAXIMUM_LATENCY (dans cet exemple, 20 μs). Les pics de latence de 20 μs et plus ne sont généralement pas acceptables pour les charges de travail telco RAN.

    Si les résultats dépassent le seuil de latence, le test échoue.

    Important

    Pour obtenir des résultats valables, le test doit durer au moins 12 heures.

    Exemple de sortie de panne

    running /usr/bin/cnftests -ginkgo.v -ginkgo.focus=cyclictest
I0908 13:01:59.193776      27 request.go:601] Waited for 1.046228824s due to client-side throttling, not priority and fairness, request: GET:https://api.compute-1.example.com:6443/apis/packages.operators.coreos.com/v1?timeout=32s
Running Suite: CNF Features e2e integration tests
=================================================
Random Seed: 1662642118
Will run 1 of 194 specs

[...]

Summarizing 1 Failure:

[Fail] [performance] Latency Test with the cyclictest image [It] should succeed
/remote-source/app/vendor/github.com/openshift/cluster-node-tuning-operator/test/e2e/performanceprofile/functests/4_latency/latency.go:220

Ran 1 of 194 Specs in 161.151 seconds
FAIL! -- 0 Passed | 1 Failed | 0 Pending | 193 Skipped
--- FAIL: TestTest (161.48s)
FAIL

Exemple de résultats d'un test cyclique

La même sortie peut indiquer des résultats différents pour des charges de travail différentes. Par exemple, des pics allant jusqu'à 18μs sont acceptables pour les charges de travail de l'UD 4G, mais pas pour les charges de travail de l'UD 5G.

Exemple de bons résultats

running cmd: cyclictest -q -D 10m -p 1 -t 16 -a 2,4,6,8,10,12,14,16,54,56,58,60,62,64,66,68 -h 30 -i 1000 -m
# Histogram
000000 000000   000000  000000  000000  000000  000000  000000  000000  000000  000000  000000  000000  000000  000000  000000  000000
000001 000000   000000  000000  000000  000000  000000  000000  000000  000000  000000  000000  000000  000000  000000  000000  000000
000002 579506   535967  418614  573648  532870  529897  489306  558076  582350  585188  583793  223781  532480  569130  472250  576043
More histogram entries ...
# Total: 000600000 000600000 000600000 000599999 000599999 000599999 000599998 000599998 000599998 000599997 000599997 000599996 000599996 000599995 000599995 000599995
# Min Latencies: 00002 00002 00002 00002 00002 00002 00002 00002 00002 00002 00002 00002 00002 00002 00002 00002
# Avg Latencies: 00002 00002 00002 00002 00002 00002 00002 00002 00002 00002 00002 00002 00002 00002 00002 00002
# Max Latencies: 00005 00005 00004 00005 00004 00004 00005 00005 00006 00005 00004 00005 00004 00004 00005 00004
# Histogram Overflows: 00000 00000 00000 00000 00000 00000 00000 00000 00000 00000 00000 00000 00000 00000 00000 00000
# Histogram Overflow at cycle number:
# Thread 0:
# Thread 1:
# Thread 2:
# Thread 3:
# Thread 4:
# Thread 5:
# Thread 6:
# Thread 7:
# Thread 8:
# Thread 9:
# Thread 10:
# Thread 11:
# Thread 12:
# Thread 13:
# Thread 14:
# Thread 15:

Exemple de mauvais résultats

running cmd: cyclictest -q -D 10m -p 1 -t 16 -a 2,4,6,8,10,12,14,16,54,56,58,60,62,64,66,68 -h 30 -i 1000 -m
# Histogram
000000 000000   000000  000000  000000  000000  000000  000000  000000  000000  000000  000000  000000  000000  000000  000000  000000
000001 000000   000000  000000  000000  000000  000000  000000  000000  000000  000000  000000  000000  000000  000000  000000  000000
000002 564632   579686  354911  563036  492543  521983  515884  378266  592621  463547  482764  591976  590409  588145  589556  353518
More histogram entries ...
# Total: 000599999 000599999 000599999 000599997 000599997 000599998 000599998 000599997 000599997 000599996 000599995 000599996 000599995 000599995 000599995 000599993
# Min Latencies: 00002 00002 00002 00002 00002 00002 00002 00002 00002 00002 00002 00002 00002 00002 00002 00002
# Avg Latencies: 00002 00002 00002 00002 00002 00002 00002 00002 00002 00002 00002 00002 00002 00002 00002 00002
# Max Latencies: 00493 00387 00271 00619 00541 00513 00009 00389 00252 00215 00539 00498 00363 00204 00068 00520
# Histogram Overflows: 00001 00001 00001 00002 00002 00001 00000 00001 00001 00001 00002 00001 00001 00001 00001 00002
# Histogram Overflow at cycle number:
# Thread 0: 155922
# Thread 1: 110064
# Thread 2: 110064
# Thread 3: 110063 155921
# Thread 4: 110063 155921
# Thread 5: 155920
# Thread 6:
# Thread 7: 110062
# Thread 8: 110062
# Thread 9: 155919
# Thread 10: 110061 155919
# Thread 11: 155918
# Thread 12: 155918
# Thread 13: 110060
# Thread 14: 110060
# Thread 15: 110059 155917

15.4.3. Course à pied de l'oslat
Copier lien

Le test oslat simule une application DPDK à forte intensité de CPU et mesure toutes les interruptions et perturbations afin de tester la manière dont le cluster gère le traitement des données à forte intensité de CPU.

Important

Always exécuter les tests de latence avec DISCOVERY_MODE=true. Si vous ne le faites pas, la suite de tests apportera des modifications à la configuration du cluster en cours d'exécution.

Note

Lorsque vous exécutez les commandes podman en tant qu'utilisateur non root ou non privilégié, les chemins de montage peuvent échouer avec des erreurs permission denied. Pour que la commande podman fonctionne, ajoutez :Z à la création des volumes ; par exemple, -v $(pwd)/:/kubeconfig:Z. Cela permet à podman d'effectuer le réétiquetage SELinux approprié.

Conditions préalables

  • Vous vous êtes connecté à registry.redhat.io avec vos identifiants du portail client.
  • Vous avez appliqué un profil de performance de cluster en utilisant l'opérateur Node Tuning.

Procédure

  • Pour effectuer le test oslat, exécutez la commande suivante, en remplaçant les valeurs des variables par celles qui conviennent : 

    $ podman run -v $(pwd)/:/kubeconfig:Z -e KUBECONFIG=/kubeconfig/kubeconfig \
-e LATENCY_TEST_RUN=true -e DISCOVERY_MODE=true -e FEATURES=performance -e ROLE_WORKER_CNF=worker-cnf \
-e LATENCY_TEST_CPUS=10 -e LATENCY_TEST_RUNTIME=600 -e MAXIMUM_LATENCY=20 \
registry.redhat.io/openshift4/cnf-tests-rhel8:v4.12 \
/usr/bin/test-run.sh -ginkgo.v -ginkgo.focus="oslat"

    LATENCY_TEST_CPUS spécifie la liste des unités centrales à tester avec la commande oslat.

    La commande exécute l'outil oslat pendant 10 minutes (600 secondes). Le test s'exécute avec succès lorsque la latence maximale observée est inférieure à MAXIMUM_LATENCY (20 μs).

    Si les résultats dépassent le seuil de latence, le test échoue.

    Important

    Pour obtenir des résultats valables, le test doit durer au moins 12 heures.

    Exemple de sortie de panne

    running /usr/bin/cnftests -ginkgo.v -ginkgo.focus=oslat
I0908 12:51:55.999393      27 request.go:601] Waited for 1.044848101s due to client-side throttling, not priority and fairness, request: GET:https://compute-1.example.com:6443/apis/machineconfiguration.openshift.io/v1?timeout=32s
Running Suite: CNF Features e2e integration tests
=================================================
Random Seed: 1662641514
Will run 1 of 194 specs

[...]

• Failure [77.833 seconds]
[performance] Latency Test
/remote-source/app/vendor/github.com/openshift/cluster-node-tuning-operator/test/e2e/performanceprofile/functests/4_latency/latency.go:62
  with the oslat image
  /remote-source/app/vendor/github.com/openshift/cluster-node-tuning-operator/test/e2e/performanceprofile/functests/4_latency/latency.go:128
    should succeed [It]
    /remote-source/app/vendor/github.com/openshift/cluster-node-tuning-operator/test/e2e/performanceprofile/functests/4_latency/latency.go:153

    The current latency 304 is bigger than the expected one 1 :
    1 
    

[...]

Summarizing 1 Failure:

[Fail] [performance] Latency Test with the oslat image [It] should succeed
/remote-source/app/vendor/github.com/openshift/cluster-node-tuning-operator/test/e2e/performanceprofile/functests/4_latency/latency.go:177

Ran 1 of 194 Specs in 161.091 seconds
FAIL! -- 0 Passed | 1 Failed | 0 Pending | 193 Skipped
--- FAIL: TestTest (161.42s)
FAIL

    1
    Dans cet exemple, la latence mesurée est en dehors de la valeur maximale autorisée.
Red Hat logoGithubredditYoutubeTwitter

Apprendre

Essayez, achetez et vendez

Communautés

À propos de la documentation Red Hat

Nous aidons les utilisateurs de Red Hat à innover et à atteindre leurs objectifs grâce à nos produits et services avec un contenu auquel ils peuvent faire confiance. Découvrez nos récentes mises à jour.

Rendre l’open source plus inclusif

Red Hat s'engage à remplacer le langage problématique dans notre code, notre documentation et nos propriétés Web. Pour plus de détails, consultez le Blog Red Hat.

À propos de Red Hat

Nous proposons des solutions renforcées qui facilitent le travail des entreprises sur plusieurs plates-formes et environnements, du centre de données central à la périphérie du réseau.

Theme

© 2026 Red HatRetour au début