Sur Ubuntu, un processeur très sollicité ne signale pas forcément une panne : un encodage vidéo peut légitimement mobiliser plusieurs cœurs, tandis qu’une application bloquée peut ralentir tout le bureau. Pour comprendre les performances, il faut distinguer le travail réellement effectué, les processus en attente et les ressources disponibles.
Le scheduler, ou ordonnanceur, répartit le temps de calcul entre les tâches selon leur politique et leur priorité des processus. Quelques outils Linux permettent de repérer un goulot d’étranglement, puis de choisir une optimisation CPU adaptée plutôt que de modifier des réglages à l’aveugle.
Utilisation du processeur et charge système sous Linux
Un processeur occupé exécute des instructions pour les applications et le noyau. La charge système, elle, reflète le nombre moyen de tâches exécutables ou en attente non interruptible : elle ne correspond donc pas directement à un pourcentage d’utilisation CPU.
Selon la page de manuel Linux sched, l’ordonnanceur organise l’exécution des tâches et tient compte de politiques différentes. En pratique, une charge moyenne supérieure au nombre de cœurs peut signaler une concurrence pour le calcul, mais il faut aussi vérifier les attentes d’entrées-sorties.
Repères utiles pour interpréter les mesures :
- Temps utilisateur : calcul effectué par les applications
- Temps système : travail accompli par le noyau
- Temps inactif : capacité de calcul disponible
- Attente d’E/S : tâches suspendues en attendant un périphérique
Un serveur qui compresse des fichiers peut afficher une activité élevée sans être en difficulté. À l’inverse, une charge modérée accompagnée de latences disque peut dégrader la réponse d’un service.
Scheduler Ubuntu : priorités et multitâche
Cette différence entre activité et attente mène au rôle du scheduler : il décide quelle tâche utilise un cœur lorsqu’il devient disponible. Le multitâche donne l’impression que plusieurs programmes avancent simultanément, même si un cœur ne peut exécuter qu’une tâche à la fois à un instant donné.
Comment l’ordonnanceur répartit le temps CPU
Selon la documentation de sched, Linux propose plusieurs politiques d’ordonnancement, notamment pour les tâches ordinaires et certaines charges temps réel. Les processus courants partagent les ressources ; la valeur « nice » permet d’ajuster leur priorité relative sans leur réserver automatiquement un cœur.
La commande nice peut réduire l’impact d’un traitement de fond, par exemple une conversion vidéo lancée pendant une visioconférence. Il ne faut toutefois pas confondre priorité et puissance disponible : une tâche favorisée ne crée pas de capacité supplémentaire.
Repères pour choisir une action mesurée :
- Application interactive : préserver une réponse fluide
- Calcul de fond : réduire sa priorité si nécessaire
- Charge persistante : vérifier les cœurs et la mémoire
- Attente disque : examiner les entrées-sorties avant le scheduler
Pourquoi les priorités ne règlent pas tout
La priorité des processus aide à arbitrer les tâches concurrentes, mais une application inefficace continuera à consommer des cycles. Si un service monopolise un cœur à cause d’une boucle de calcul, il faut examiner son code, sa configuration ou son profil de charge.
Selon la documentation de la commande top, l’affichage interactif permet d’observer les processus et l’activité CPU. Une mesure répétée pendant le ralentissement est plus parlante qu’un instantané pris après le retour à la normale.
Outils Ubuntu pour mesurer les performances CPU
Une fois les priorités comprises, quelques commandes suffisent pour repérer les tâches coûteuses. Sur Ubuntu, top est généralement disponible ; htop offre une interface interactive, tandis que mpstat et sar sont fournis par le paquet sysstat.
Tableau de choix rapide selon le besoin :
| Outil | Usage principal | À observer |
|---|---|---|
| top | Suivi interactif | Processus et temps CPU |
| htop | Vue interactive par cœur | Charge de chaque cœur |
| mpstat | Mesures détaillées | Utilisateur, système, inactivité |
| sar | Analyse dans le temps | Évolution des statistiques |
Pour débuter, ouvrez un terminal et lancez top, puis repérez les tâches dont le pourcentage reste élevé. Pour une vue par cœur et des relevés répétés, installez sysstat avec sudo apt install sysstat, puis essayez mpstat -P ALL 2 5.
Commandes pratiques pour isoler les processus gourmands :
- top : observer l’activité en direct
- ps aux –sort=-%cpu | head : classer les processus
- mpstat -P ALL : comparer les cœurs
- sar -u : consulter les mesures conservées
Diagnostic d’une utilisation CPU élevée
Quand les mesures indiquent une activité anormale, commencez par identifier le processus concerné et vérifiez si le pic est ponctuel ou durable. Une tâche d’indexation après une mise à jour n’appelle pas forcément la même réponse qu’un service qui ralentit chaque jour.
Relier les symptômes à leur cause
Un encodage vidéo, une simulation ou un calcul scientifique peut utiliser pleinement le processeur sans anomalie. Une application mal optimisée, un nombre excessif de fils d’exécution ou des ressources insuffisantes peuvent, eux, créer une saturation durable.
Tableau de diagnostic avant toute optimisation :
| Observation | Cause possible | Vérification utile |
|---|---|---|
| Un processus domine | Calcul intensif ou application défaillante | Comparer son activité dans le temps |
| Plusieurs cœurs saturés | Charge parallèle importante | Évaluer le besoin applicatif |
| Charge élevée, CPU peu occupé | Attente d’entrées-sorties possible | Examiner les disques et les E/S |
| Ralentissement intermittent | Pic de tâche planifiée | Consulter l’historique avec sar |
Selon les pages de manuel Linux de mpstat et sar, ces outils présentent respectivement des statistiques processeur détaillées et des données d’activité collectées. Croiser les relevés aide à ne pas attribuer trop vite chaque lenteur au CPU.
Appliquer une optimisation CPU prudente
Une fois la cause repérée, ajustez d’abord l’application : réduire les tâches simultanées, optimiser une requête ou choisir un algorithme moins coûteux peut améliorer les performances sans intervention sur le noyau. Sur un serveur partagé, les cgroups peuvent aussi encadrer l’usage CPU d’un groupe de processus.
Pour les conteneurs, docker stats affiche l’activité des conteneurs en cours d’exécution ; des limites CPU peuvent être définies au lancement. Dans Kubernetes, kubectl top nodes et kubectl top pods donnent une vue des ressources, à condition que Metrics Server soit disponible.
Surveillez les effets après chaque modification : une limite trop stricte peut protéger un service tout en augmentant son temps de réponse. L’optimisation la plus sûre repose sur des mesures répétées, un changement ciblé et une vérification après déploiement.
Source : page de manuel Linux sched, « Overview of CPU scheduling » ; pages de manuel Linux top, mpstat et sar.