Sous Linux, la charge moyenne compte les processus en sommeil ininterruptible autant que les processus exécutables, donc une charge élevée avec des CPU au repos veut presque toujours dire que des processus sont bloqués sur des entrées sorties. Vérifiez l'iowait et l'utilisation des périphériques avec iostat, cherchez les processus en état D, et pensez à un disque lent, un système de fichiers réseau bloqué, ou un volume de stockage saturé. Parfois c'est de la contention de verrous ou un montage suspendu plutôt qu'un problème de débit.
Pourquoi les recruteurs posent cette question
C'est un test classique des fondamentaux Linux que beaucoup de candidats infrastructure ratent, parce qu'ils supposent que la charge égale la demande CPU. Le recruteur veut le détail du sommeil ininterruptible puis un chemin de diagnostic méthodique avec des outils nommés. Ça montre aussi si vous savez raisonner sur une machine en direct plutôt que de la redémarrer tout de suite en espérant que le symptôme disparaisse.
Comment structurer votre réponse
- Corrigez l'hypothèse : sous Linux la charge inclut le sommeil ininterruptible.
- Nommez le blocage sur les entrées sorties comme cause probable.
- Donnez la séquence de diagnostic avec des commandes précises.
- Mentionnez les causes moins fréquentes avant de conclure.
Exemple de réponse
La charge moyenne sous Linux n'est pas une file d'attente CPU, elle compte les processus exécutables plus les processus ininterruptibles, donc des processus coincés à attendre un disque ou un montage réseau la gonflent pendant que les CPU restent au repos. Mon premier geste, c'est donc de confirmer ça : ps pour chercher les processus en état D, et vmstat ou top pour regarder la colonne iowait. Ensuite iostat pour voir si un périphérique est à cent pour cent d'utilisation avec un await horrible, ce qui pointe vers un disque saturé ou défaillant, ou vers un volume cloud qui a épuisé ses crédits de burst, un truc que j'ai rencontré plus d'une fois sur un volume à usage général qui allait bien pendant des mois et puis d'un coup non. Si les processus en état D touchent tous le même montage, je regarde le système de fichiers réseau, parce qu'un export NFS suspendu produit exactement cette image : charge énorme et rien qui avance. Si le stockage a l'air sain, j'élargis vers la contention de verrous ou un problème de pilote. Le point clé, c'est que redémarrer l'application ici ne m'apprendrait rien, parce que l'application est la victime, pas la cause.
Vous passez cet entretien bientôt ? GhostPilot écoute votre appel en direct, repère la question dès qu'elle est posée et affiche une réponse structurée à l'écran en temps réel. Essayez-le lors de votre prochain entretien blanc, ou prenez un Session Pass à $29, sans abonnement, pour le jour J.
Voir comment ça marcheQuestions de relance à prévoir
- Comment distingueriez-vous un volume saturé d'un volume défaillant ?
- Que signifie un processus en état D pour un signal kill ?
- Sur quelle métrique alerteriez-vous vraiment à la place de la charge moyenne ?
Autres questions pour Ingénieur DevOps
Votre recruteur posera sa propre version de celle-ci. Collez votre véritable fiche de poste dans le Question Predictor gratuit et obtenez les 20 questions que ce poste a le plus de chances de poser, avec ce que chacune cherche vraiment à sonder.
Prédire mes questions