F5 : CPU, mémoire, CMP et configuration utile

L’interface graphique et le traitement applicatif n’utilisent pas exactement les mêmes composants. Une GUI lente avec des services encore accessibles appelle une analyse différente d’un arrêt global du trafic.

Relevez la période, les applications touchées et les ressources de chaque appareil. Le fait qu’un backend semble peu chargé ne suffit pas à exclure une limite BIG-IP ou un problème réseau.

F5 distingue la consommation TMM des autres usages système. Le traitement par plusieurs instances et cœurs doit être compris avant de convertir un pourcentage en capacité disponible. CMP permet une distribution du traitement selon les fonctions et contraintes prises en charge.

Comparez profils, taux de nouvelles connexions, handshakes TLS et requêtes. Une charge liée aux ouvertures n’est pas décrite par le seul nombre de connexions actives. Le guide des types de VS explique aussi les différences de traitement et d’accélération.

Le provisioning répartit des ressources entre les modules. Buffers, tables de connexions et caches consomment également de la mémoire. Une faible mémoire disponible peut donc avoir plusieurs explications ; il faut corréler configuration et charge.

Dans un scénario pédagogique, doubler un buffer par connexion tout en conservant un grand nombre de connexions multiplie la réservation correspondante. Cette arithmétique ne décrit pas toute la mémoire d’un flux, mais montre pourquoi une optimisation individuelle peut devenir coûteuse à grande échelle.

Les commandes ci-dessous affichent CPU, mémoire, provisioning et statistiques du VS. Pour la table de connexions, utilisez un filtre ciblé : un inventaire global peut être volumineux et coûteux sur un système chargé.

Un objet avec un compteur nul peut être récent, destiné à une reprise ou consulté indirectement par une iRule. Avant suppression, examinez associations de VS, policies, règles, profils parents, moniteurs et services applicatifs.

Remplacer une iRule simple par un réglage natif ou une policy peut clarifier la configuration. Mais retirer un profil « qui paraît inutile » peut empêcher un événement ou une commande de fonctionner. Faites un graphe de dépendances avant de faire du nettoyage.

QKView collecte des données de diagnostic destinées à l’analyse système. Il peut compléter compteurs, logs et captures. Définissez quand le générer, son impact et le périmètre de partage ; les données collectées peuvent contenir des détails sensibles.

Un redémarrage de service modifie le contexte et peut avoir un impact. Identifiez le composant et la procédure avant de redémarrer au hasard pour résoudre une GUI lente. Préservez les preuves du problème et les informations de version.

En laboratoire, gardez le même scénario de trafic et comparez avant/après : taux d’erreurs, temps de réponse, CPU par contexte, mémoire et nouvelles connexions. Si plusieurs paramètres changent ensemble, l’amélioration éventuelle ne permet pas d’identifier lequel l’a produite.

Une fonction absente peut dépendre de licence ou de provisioning, pas d’une panne de pool. show sys license peut afficher des clés et informations sensibles : consultez la sortie localement et expurgez-la avant partage. Comparez modules actifs, plateforme et version à la fonction recherchée.

Une suspicion matérielle demande le contexte du modèle, de ses capteurs et des logs : température, alimentation, interfaces ou autre état selon la plateforme. Une panne de connectivité et une saturation peuvent produire des symptômes proches ; comparez erreurs réseau, ressources et horodatages avant de conclure.

QKView rassemble une photographie de diagnostic. Reliez les heuristiques aux symptômes et à la version, puis vérifiez les actions avec la documentation ou le support. Une alerte heuristique n’autorise pas à supprimer arbitrairement un fichier ou redémarrer un service. Préservez compteurs et traces avant une action qui efface l’état.