La famine de processus dans les systèmes d’exploitation : causes, mécanismes et solutions de qualité production

La famine de processus (process starvation) survient lorsqu’un processus se voit indéfiniment refuser le temps CPU, la mémoire ou la bande passante I/O dont il a besoin pour progresser — non pas parce que les ressources n’existent pas, mais parce que la politique d’ordonnancement favorise systématiquement d’autres processus. Contrairement à l’interblocage (deadlock), où tous les processus en compétition sont bloqués, la famine permet au système de paraître fonctionnel tout en dégradant ou en arrêtant silencieusement des charges de travail spécifiques.

Cette distinction est importante sur le plan opérationnel : un processus affamé ne produit aucune erreur au niveau du noyau, ne génère aucun vidage mémoire (crash dump) et peut ne pas déclencher les seuils d’alerte standard — ce qui en fait l’une des pathologies de performance les plus insidieuses dans les environnements serveurs multi-locataires et à haute concurrence.

Ce que la famine signifie réellement au niveau du noyau

Le terme est emprunté à l’écologie des ressources : un processus « meurt de faim » lorsqu’il est perpétuellement surpassé dans la compétition pour une ressource finie. Dans les systèmes d’exploitation modernes, le Linux Completely Fair Scheduler (CFS), les files de priorité Windows NT et le planificateur BSD ULE implémentent tous des mécanismes pour prévenir la famine — pourtant, elle apparaît encore en production dans des conditions spécifiques.

Au niveau du noyau, la famine se manifeste comme un processus dont le temps d’exécution virtuel (en terminologie CFS) ou le temps d’attente croît sans limite sans jamais être sélectionné pour l’exécution. Le processus reste dans l’état TASK_RUNNING — il est prêt et éligible — mais le planificateur ne lui accorde jamais de tranche CPU car des tâches de priorité plus élevée ou plus fréquemment exécutables le préemptent toujours.

Distinction technique clé :

• Interblocage (Deadlock) : Deux processus ou plus sont mutuellement bloqués, chacun attendant une ressource détenue par l’autre. Le système ne progresse pas du tout sur ces tâches.
• Famine (Starvation) : Un ou plusieurs processus sont perpétuellement ignorés par le planificateur. Les autres processus continuent de s’exécuter normalement.
• Livelock : Les processus ne sont pas bloqués mais changent continuellement d’état en réponse les uns aux autres sans réellement progresser.

Causes profondes de la famine de processus

Comprendre la famine nécessite d’examiner les mécanismes spécifiques qui la produisent, et pas seulement de lister « ressources limitées » comme cause.

1. Inversion de priorité statique sans vieillissement

La plupart des planificateurs basés sur les priorités attribuent une priorité fixe ou semi-fixe à chaque processus. Si un processus de faible priorité est toujours préempté par un flux de tâches de priorité moyenne et élevée, il ne s’exécute jamais. Le mode de défaillance critique ici est l’absence de vieillissement (aging) — une technique où la priorité effective d’un processus est progressivement augmentée plus il attend. Sans vieillissement, une tâche d’arrière-plan de faible priorité sur un serveur occupé peut attendre indéfiniment.

Sur Linux, la plage de valeurs nice (-20 à +19) et les priorités temps réel (SCHED_FIFO, SCHED_RR) créent exactement ce risque. Un processus s’exécutant sous SCHED_FIFO à la priorité 99 préemptera chaque processus SCHED_OTHER sur le même cœur CPU jusqu’à ce qu’il cède volontairement ou se bloque.

2. File d’attente inéquitable dans les planificateurs I/O

La famine CPU est bien documentée, mais la famine I/O est tout aussi destructrice et souvent négligée. Le planificateur I/O Linux (historiquement CFQ, maintenant BFQ ou mq-deadline selon la version du noyau et le type de stockage) gère l’ordre dans lequel les requêtes de périphériques de blocs sont traitées. Sous des charges d’écriture séquentielle intensive — courantes dans les serveurs de bases de données et les applications à journalisation intensive — le planificateur I/O peut déprioriser les requêtes de lecture aléatoire d’autres processus, les privant effectivement d’accès au disque.

C’est un problème fréquent dans les environnements VPS Hosting où plusieurs locataires partagent l’infrastructure de stockage sous-jacente et où la contention I/O est une préoccupation opérationnelle réelle.

3. Pression mémoire et le tueur OOM

Lorsque la RAM physique est épuisée, le tueur Out-Of-Memory (OOM) du noyau Linux sélectionne un processus à terminer en fonction d’un oom_score. Bien qu’il s’agisse techniquement d’une terminaison plutôt que d’une famine, l’état précurseur — où un processus est répétitivement échangé sur le disque et ne dispose jamais de suffisamment de mémoire résidente pour s’exécuter efficacement — constitue une famine mémoire. Le processus s’exécute techniquement mais progresse de façon négligeable en raison de défauts de page constants et d’I/O de swap.

4. Contention de verrous et famine de mutex

Dans les applications multi-threadées, la famine se produit au niveau des primitives de synchronisation. Si un mutex ou un sémaphore utilise une politique d’acquisition non équitable (dernier entré, premier sorti ou sélection aléatoire parmi les threads en attente), un thread spécifique peut être perpétuellement ignoré même si le verrou est fréquemment libéré. Cela est distinct de l’ordonnancement au niveau du système d’exploitation et se produit entièrement dans l’espace utilisateur ou le sous-système de synchronisation du noyau.

5. Famine de bande passante réseau

Dans les environnements conteneurisés et virtualisés, un processus ou conteneur consommant toute la bande passante réseau disponible peut priver d’autres processus d’I/O réseau. Sans mise en forme du trafic via tc (contrôle du trafic) et cgroups, un seul processus incontrôlé peut monopoliser le débit de la carte réseau.

Famine vs. Interblocage vs. Livelock : comparaison technique

Comment les planificateurs modernes traitent la famine

Le Linux Completely Fair Scheduler (CFS)

CFS, introduit dans le noyau Linux 2.6.23, traite la famine en suivant le temps d’exécution virtuel (vruntime) pour chaque processus. Le planificateur sélectionne toujours le processus avec le vruntime le plus bas — ce qui signifie que les processus ayant reçu moins de temps CPU sont systématiquement prioritaires. Cette conception rend la famine CPU pure presque impossible sous CFS pour les processus SCHED_OTHER.

Cependant, CFS ne protège pas contre la famine causée par les processus temps réel. Tout processus planifié sous SCHED_FIFO ou SCHED_RR préempte toutes les tâches SCHED_OTHER. Le paramètre noyau /proc/sys/kernel/sched_rt_runtime_us (par défaut : 950 000 microsecondes par seconde) réserve 5 % du temps CPU pour les tâches non temps réel précisément pour éviter cela.

Vieillissement des priorités

Les algorithmes de vieillissement classiques incrémentent la priorité effective d’un processus d’une quantité fixe pour chaque cycle d’ordonnancement passé en attente. Une fois que la priorité effective atteint le niveau le plus élevé, l’exécution du processus est garantie. Après son exécution, sa priorité est réinitialisée à sa valeur de base. C’est la solution théorique à la famine basée sur les priorités et elle est implémentée sous diverses formes dans Windows NT, Solaris et les anciens planificateurs Linux.

File d’attente équitable et file d’attente équitable pondérée (WFQ)

Pour les ressources réseau et I/O, la file d’attente équitable pondérée (Weighted Fair Queuing) attribue à chaque flux ou processus une part de bande passante proportionnelle à son poids. Même si un flux à poids élevé génère plus de trafic, les flux à faible poids se voient garantir un débit de service minimum. Linux implémente cela via les disciplines Hierarchical Token Bucket (HTB) et Stochastic Fair Queuing (SFQ) dans le sous-système tc.

Diagnostic de la famine dans les systèmes Linux en production

Identifier la famine nécessite de corréler simultanément plusieurs sources de données.

Analyse de l’ordonnancement CPU

# Check per-process CPU wait time and scheduling statistics
cat /proc/<PID>/schedstat

# Monitor scheduler latency with perf
perf sched latency --sort max

# Identify processes with high voluntary/involuntary context switches
pidstat -w 1 10

# Check real-time process priorities that may be starving others
ps -eo pid,comm,cls,pri,ni --sort=-pri | head -20

La sortie schedstat fournit le temps cumulatif que le processus a passé à attendre dans la file d’exécution (run_delay en nanosecondes) — une mesure directe de la famine d’ordonnancement.

Indicateurs de famine mémoire

# Check swap activity — high si/so values indicate memory starvation
vmstat 1 10

# Identify processes with high major page fault rates
pidstat -r 1 10

# Check OOM kill history
dmesg | grep -i "oom|killed process"

# Inspect per-process memory pressure
cat /proc/<PID>/status | grep -E "VmRSS|VmSwap|VmPeak"

Détection de la famine I/O

# Per-process I/O wait statistics
iotop -b -n 5

# Block device queue depth and wait times
iostat -x 1 5

# Check I/O scheduler in use for each block device
cat /sys/block/sda/queue/scheduler

# Identify processes blocked on I/O
ps aux | awk '$8 ~ /D/ {print}'

Les processus dans l’état D (sommeil non interruptible) sont bloqués sur I/O. Une population persistante de processus en état D est un indicateur fort de famine I/O ou de saturation du sous-système de stockage.

Solutions de niveau production et stratégies d’atténuation

Implémenter cgroups v2 pour l’isolation des ressources

Les groupes de contrôle (cgroups v2) fournissent le mécanisme le plus robuste pour prévenir la famine dans les environnements multi-processus et conteneurisés. En attribuant des quotas explicites de CPU, mémoire et I/O aux groupes de processus, vous garantissez des allocations minimales de ressources quelle que soit la charge du système.

# Create a cgroup with CPU weight (higher weight = more CPU share)
mkdir /sys/fs/cgroup/my_service
echo "100" > /sys/fs/cgroup/my_service/cpu.weight

# Set memory limit to prevent memory starvation of other groups
echo "2G" > /sys/fs/cgroup/my_service/memory.max

# Assign process to cgroup
echo <PID> > /sys/fs/cgroup/my_service/cgroup.procs

Le poids CPU dans cgroups v2 utilise une plage de 1 à 10000, où la valeur par défaut est 100. Un groupe de processus avec un poids de 200 reçoit deux fois la part CPU d’un groupe avec un poids de 100 en cas de contention.

Ajuster le planificateur Linux pour votre charge de travail

# Increase scheduler migration cost to reduce cache thrashing (latency-sensitive workloads)
echo 500000 > /proc/sys/kernel/sched_migration_cost_ns

# Reduce scheduler granularity for more frequent preemption (throughput workloads)
echo 1000000 > /proc/sys/kernel/sched_min_granularity_ns

# Ensure real-time tasks cannot starve normal tasks
echo 950000 > /proc/sys/kernel/sched_rt_runtime_us

Appliquer des politiques d’ordonnancement appropriées par processus

# Set a process to batch scheduling (explicitly low-priority, won't starve interactive tasks)
chrt -b -p 0 <PID>

# Set a CPU-intensive background job to idle scheduling class
chrt -i -p 0 <PID>

# Adjust nice value for a running process
renice -n 10 -p <PID>

# Run a new command with reduced priority
nice -n 15 ./my_background_script.sh

La classe SCHED_IDLE (chrt -i) est le bon outil pour les tâches véritablement en arrière-plan — elle ne s’exécute que lorsqu’aucun autre processus exécutable n’existe, éliminant complètement sa capacité à affamer d’autres charges de travail.

Sélection du planificateur I/O

# For NVMe SSDs (low-latency, no rotational penalty): use none or mq-deadline
echo "mq-deadline" > /sys/block/nvme0n1/queue/scheduler

# For HDDs with mixed workloads: use bfq for fairness
echo "bfq" > /sys/block/sda/queue/scheduler

# Make persistent across reboots (add to /etc/udev/rules.d/)
echo 'ACTION=="add|change", KERNEL=="sda", ATTR{queue/scheduler}="bfq"' 
  > /etc/udev/rules.d/60-scheduler.rules

Le BFQ (Budget Fair Queuing) est spécifiquement conçu pour prévenir la famine I/O en garantissant à chaque processus une part proportionnelle de la bande passante disque. C’est le planificateur recommandé pour les environnements d’hébergement partagé et les serveurs de bases de données.

Contrôle de la bande passante réseau avec tc

# Create a root HTB qdisc on the primary interface
tc qdisc add dev eth0 root handle 1: htb default 30

# Add a parent class with total bandwidth
tc class add dev eth0 parent 1: classid 1:1 htb rate 1gbit

# Add child classes with guaranteed minimums (prevents starvation)
tc class add dev eth0 parent 1:1 classid 1:10 htb rate 100mbit ceil 1gbit
tc class add dev eth0 parent 1:1 classid 1:20 htb rate 100mbit ceil 1gbit

# Add SFQ leaf to each class for per-flow fairness
tc qdisc add dev eth0 parent 1:10 handle 10: sfq perturb 10
tc qdisc add dev eth0 parent 1:20 handle 20: sfq perturb 10

Cette configuration garantit à chaque classe un minimum de 100 Mbps tout en permettant une utilisation en rafale jusqu’à la capacité totale du lien de 1 Gbps lorsque la bande passante est disponible.

Surengagement mémoire et ajustement du swap

# Reduce swappiness to minimize swap-induced memory starvation
echo 10 > /proc/sys/vm/swappiness

# Enable memory overcommit accounting (prevents OOM from surprising processes)
echo 2 > /proc/sys/vm/overcommit_memory

# Set overcommit ratio (total allocatable = RAM * ratio + swap)
echo 80 > /proc/sys/vm/overcommit_ratio

Définir vm.swappiness=10 indique au noyau de préférer récupérer le cache de pages plutôt que d’échanger la mémoire des processus, réduisant considérablement la probabilité de famine mémoire sous charge modérée.

La famine dans les environnements virtualisés et conteneurisés

Sur les Serveurs Dédiés exécutant des hyperviseurs (KVM, VMware ESXi, Hyper-V), la famine peut se produire à deux couches distinctes :

Famine au niveau de l’hyperviseur : Une machine virtuelle se voit refuser des cycles CPU par le planificateur de l’hyperviseur. KVM utilise le CFS du noyau hôte pour l’ordonnancement des vCPU, ce qui signifie qu’une VM avec un poids de part CPU inférieur peut être affamée par des VM avec des poids plus élevés en cas de contention. Le DRS (Distributed Resource Scheduler) de VMware utilise des parts, des réservations et des limites pour contrôler cela.

Famine au niveau du système d’exploitation invité : Au sein de la VM elle-même, les mêmes dynamiques d’ordonnancement au niveau du système d’exploitation s’appliquent. Une charge de travail conteneurisée s’exécutant sous Docker ou Kubernetes sans limites de ressources explicites peut monopoliser le CPU et la mémoire du système d’exploitation invité, affamant les conteneurs co-localisés.

Pour les environnements Kubernetes, définissez toujours à la fois requests et limits dans les spécifications de pod :

resources:
  requests:
    cpu: "250m"
    memory: "512Mi"
  limits:
    cpu: "1000m"
    memory: "1Gi"

La valeur requests détermine le placement de l’ordonnancement et le poids de part CPU du cgroup. Sans elle, le planificateur Kubernetes n’a aucune base pour un placement équitable, et le runtime de conteneur attribue des poids par défaut (égaux) — ce qui permet quand même la famine si un conteneur sature systématiquement sa limite CPU.

La famine dans les serveurs de bases de données et d’applications

Les moteurs de bases de données implémentent leurs propres planificateurs internes indépendants du planificateur du système d’exploitation. PostgreSQL utilise un modèle de processus par connexion où chaque processus backend est en compétition pour les ressources du système d’exploitation normalement, mais la contention de verrous au sein de la base de données (verrous au niveau des lignes, verrous consultatifs) peut provoquer une famine au niveau applicatif où des requêtes spécifiques attendent indéfiniment l’acquisition de verrous.

MySQL/InnoDB utilise un pool de threads avec des limites de concurrence configurables (innodb_thread_concurrency). Définir cette valeur trop basse provoque une famine de requêtes car les threads se mettent en file d’attente en attendant des créneaux d’exécution. La définir trop haute provoque une surcharge CPU. La valeur de départ recommandée est 2 × number of CPU cores.

Pour les serveurs web, Nginx et Apache ont des profils de famine distincts. Le modèle événementiel de Nginx est intrinsèquement résistant à la famine des workers, mais l’épuisement du pool de connexions en amont (par exemple, vers PHP-FPM ou une API backend) crée une famine au niveau applicatif. Le MPM prefork d’Apache peut épuiser sa limite MaxRequestWorkers, provoquant la mise en file d’attente indéfinie des nouvelles connexions — une forme de famine de connexions.

Ces considérations sont directement pertinentes lors de la configuration d’un VPS avec cPanel pour des charges de travail d’hébergement web partagé, où plusieurs sites sont en compétition pour les pools de workers PHP-FPM et les limites de connexions MySQL.

Infrastructure de surveillance pour la prévention de la famine

Le diagnostic réactif est insuffisant pour les systèmes en production. Une pile de surveillance proactive devrait inclure :

Métriques Prometheus + Node Exporter à surveiller :

• node_schedstat_waiting_seconds_total — temps d’attente cumulatif dans la file d’exécution CPU par CPU
• node_vmstat_pgmajfault — défauts de page majeurs indiquant une pression mémoire
• node_disk_io_time_weighted_seconds_total — saturation de la file d’attente I/O
• node_pressure_cpu_waiting_seconds_total — pression CPU Linux PSI (Pressure Stall Information)
• node_pressure_memory_full_seconds_total — temps de blocage complet PSI mémoire

Le Linux PSI (disponible depuis le noyau 4.20) est l’indicateur de famine le plus direct disponible dans le noyau. Il rapporte le pourcentage de temps pendant lequel les tâches étaient bloquées en attente de ressources CPU, mémoire ou I/O :

# Real-time PSI monitoring
cat /proc/pressure/cpu
cat /proc/pressure/memory
cat /proc/pressure/io

Format de sortie : some avg10=X.XX avg60=X.XX avg300=X.XX total=NNNN où some indique qu’au moins une tâche était bloquée. Des valeurs supérieures à 10–15 % sur avg60 justifient une investigation immédiate.

Pour les équipes gérant des Panneaux de contrôle VPS ou des piles de serveurs personnalisées, l’intégration des métriques PSI dans les tableaux de bord Grafana fournit une alerte précoce avant que la famine ne dégrade les performances visibles par les utilisateurs.

Matrice de décision pratique : choisir le bon mécanisme anti-famine

Points techniques clés à retenir

• Ne jamais se fier à l’ordonnancement par défaut pour les serveurs à charges de travail mixtes. Classifiez explicitement les processus en utilisant chrt, nice et cgroups v2 en fonction de leur sensibilité à la latence et de leur priorité métier.
• Activez la surveillance PSI (/proc/pressure/*) sur tous les systèmes Linux en production. C’est l’indicateur de famine en temps réel le plus précis dans le noyau et il a une surcharge quasi nulle.
• Utilisez BFQ pour les disques rotatifs et tout périphérique NVMe servant des charges de travail mixtes aléatoires/séquentielles dans des environnements multi-locataires. Les garanties d’équité valent la légère surcharge de débit.
• Définissez les demandes de ressources Kubernetes sans exception. Une requests.cpu non définie n’est pas « illimitée » — c’est une responsabilité d’ordonnancement qui permet la famine CPU au niveau des conteneurs.
• Distinguez la famine de l’interblocage avant d’intervenir. Tuer et redémarrer un processus affamé ne corrige pas le déséquilibre d’ordonnancement sous-jacent ; cela ne fait que supprimer temporairement le symptôme.
• Auditez les attributions de priorité temps réel (SCHED_FIFO/SCHED_RR) sur tout système où elles sont utilisées. Un seul processus temps réel mal configuré peut affamer indéfiniment toutes les charges de travail de priorité normale sur un cœur CPU.
• Pour les environnements d’Hébergement Web Partagé, appliquez des quotas CPU et I/O par compte au niveau des cgroups plutôt que de vous fier uniquement à la limitation de débit au niveau applicatif.

Foire aux questions

Quelle est la différence entre la famine et l’interblocage dans un système d’exploitation ?

L’interblocage se produit lorsque deux processus ou plus sont définitivement bloqués, chacun détenant une ressource dont l’autre a besoin — aucun processus ne progresse. La famine se produit lorsqu’un processus est perpétuellement ignoré par le planificateur malgré son état exécutable ; les autres processus continuent de s’exécuter normalement. L’interblocage nécessite de briser une dépendance circulaire ; la famine nécessite de corriger la politique d’ordonnancement, généralement en implémentant le vieillissement ou la file d’attente équitable.

Comment le planificateur Linux CFS prévient-il la famine CPU ?

CFS suit un temps d’exécution virtuel (vruntime) pour chaque processus et sélectionne toujours le processus avec le vruntime le plus bas pour l’exécution. Cela garantit que les processus recevant moins de temps CPU sont systématiquement prioritaires, rendant la famine CPU indéfinie des processus SCHED_OTHER presque impossible. Cependant, les processus temps réel (SCHED_FIFO, SCHED_RR) contournent entièrement CFS et peuvent toujours affamer les processus normaux si le paramètre sched_rt_runtime_us n’est pas correctement défini.

Comment puis-je détecter si un processus est affamé sur un serveur Linux ?

Lisez /proc/<PID>/schedstat pour vérifier le temps d’attente cumulatif dans la file d’exécution. Surveillez /proc/pressure/cpu pour les métriques de blocage PSI. Utilisez perf sched latency --sort max pour identifier les processus avec une latence d’ordonnancement anormalement élevée. Les processus en état persistant D visibles dans la sortie ps aux indiquent une famine I/O plutôt qu’une famine CPU.

La famine de processus affecte-t-elle différemment les environnements VPS et serveurs cloud par rapport au matériel nu (bare metal) ?

Oui. Sur un VPS, la famine peut se produire à la fois au niveau de la couche hyperviseur (le planificateur de l’hyperviseur refusant du temps vCPU à votre VM) et au sein du système d’exploitation invité. La famine au niveau de l’hyperviseur est invisible pour les outils de surveillance standard du système d’exploitation et nécessite des métriques spécifiques à l’hyperviseur ou un temps de vol (steal time) notable (%st dans la sortie top). Un temps de vol élevé — généralement supérieur à 5–10 % de façon soutenue — indique que l’hyperviseur ne fournit pas les cycles vCPU auxquels votre VM a droit.

Quelle est la façon la plus rapide d’empêcher un processus spécifique d’affamer les autres sur un serveur occupé ?

Assignez-le à la classe d’ordonnancement SCHED_IDLE avec chrt -i -p 0 <PID>. Cette classe ne s’exécute que lorsqu’aucun autre processus exécutable n’existe, garantissant qu’elle ne peut affamer aucune autre charge de travail. Pour les processus d’arrière-plan intensifs en I/O, définissez également leur priorité I/O à la classe idle : ionice -c 3 -p <PID>. La combinaison des deux élimine le processus comme source de famine CPU et I/O avec deux commandes et aucune modification d’application.