Optimisation des performances de Bash : guide pratique pour des scripts plus rapides

Introduction

Bash est la colle par défaut pour l'automatisation, les pipelines d'intégration continue et les tâches ponctuelles sur serveur. Il s'écrit rapidement et est disponible partout, mais sa commodité cache un coût : des scripts qui s'exécutent des ordres de grandeur plus lentement que nécessaire à cause de constructions inefficaces. Un script qui prend 10 minutes au lieu de 10 secondes peut retarder des déploiements, bloquer le traitement de données ou faire expirer un test de surveillance.

Ce guide s'adresse aux développeurs, ingénieurs DevOps et opérateurs techniques qui ont besoin de rendre leurs scripts Bash mesurablement plus rapides. Il couvre les goulots d'étranglement de performance les plus courants, comment les mesurer, comment les corriger et comment éviter de les réintroduire. Chaque recommandation inclut un exemple concret avec un résultat attendu, afin que vous puissiez l'appliquer immédiatement à vos propres scripts.

L'objectif est une optimisation sûre et observable. Avant de changer quoi que ce soit, capturez une référence. Faites un petit changement à la fois et vérifiez le résultat. Si quelque chose casse, vous avez besoin d'une version connue comme fonctionnelle pour revenir en arrière.

Inventaire de la version et de l'environnement

Avant d'optimiser, vous devez savoir ce que vous exécutez. La version de Bash peut affecter les performances car les versions plus récentes ont des optimisations et des fonctionnalités que les anciennes n'ont pas. Utilisez les commandes en lecture seule suivantes pour inventorier votre environnement :

bash --version | head -n 1
uname -m
ulimit -n
getconf PAGESIZE

Exemple de sortie sur un système Ubuntu 22.04 typique :

GNU bash, version 5.1.16(1)-release (x86_64-pc-linux-gnu)
x86_64
1024
4096

La valeur de ulimit -n (nombre de descripteurs de fichiers ouverts) peut affecter les performances si votre script ouvre de nombreux fichiers. Si elle est basse (par exemple, 1024), un script qui traite des milliers de fichiers peut atteindre la limite et échouer ou être lent. Vous pouvez l'augmenter dans le script avec ulimit -n 65536 si nécessaire, mais c'est un changement avec un rayon d'impact : il affecte toute la session shell.

Vérifiez également le type de système de fichiers où votre script va lire/écrire des données. Utilisez df -T /chemin pour voir si vous êtes sur un montage réseau (NFS), qui peut être lent pour de nombreuses petites opérations. Par exemple :

df -T /tmp

Si la sortie affiche overlay ou ext4, les E/S locales sont probablement rapides. Si elle affiche nfs, fuse ou smb, prévoyez de minimiser les E/S ou de regrouper les opérations.

Enfin, enregistrez la référence de performance actuelle. Utilisez la commande intégrée time ou /usr/bin/time avec une sortie verbeuse. Par exemple :

time ./mon_script.sh

Exemple de sortie :

real    0m12.345s
user    0m10.111s
sys     0m1.234s

Notez ces chiffres. Ils sont votre point de comparaison pour chaque optimisation que vous effectuez.

Chemin de configuration sûr

La façon la plus sûre d'optimiser un script Bash est de modifier une copie, pas l'original en production. Suivez ce chemin :

1. Copiez le script dans un nouveau fichier : cp mon_script.sh mon_script_optimise.sh
2. Modifiez la copie avec une sauvegarde sous contrôle de version : git checkout -b optimisation (si dans un dépôt) ou cp mon_script_optimise.sh mon_script_optimise.sh.bak
3. Exécutez la même entrée sur les deux versions et comparez les sorties avec diff
4. Mesurez la différence de temps avec time
5. Si la sortie est identique et le temps meilleur, gardez le changement ; sinon, revenez en arrière

Voici un exemple concret d'optimisation d'une boucle. Le script original traite une liste de fichiers et appelle cat sur chacun :

Code original :

#!/bin/bash
for fichier in *.txt; do
  cat "$fichier" >> combine.txt
done

Cette boucle crée un processus cat séparé pour chaque fichier. Pour 1000 fichiers, cela fait 1000 créations de processus, ce qui est lent. À la place, utilisez la redirection du shell pour concaténer sans commandes externes :

#!/bin/bash
for fichier in *.txt; do
  printf '%s\n' "$(<"$fichier")" >> combine.txt
done

La construction $(<fichier) lit le contenu du fichier directement dans le shell sans créer de sous-processus. Vous pouvez aussi utiliser cat une seule fois avec un motif :

cat *.txt > combine.txt

Cependant, cela échoue s'il y a trop de fichiers (liste d'arguments trop longue). Une approche robuste utilise find -exec avec + pour regrouper les arguments :

find . -maxdepth 1 -name '*.txt' -exec cat {} + > combine.txt

Cela exécute cat avec autant de fichiers que possible par invocation, réduisant drastiquement les créations de processus.

Vérification : après chaque changement, exécutez diff ancien_combine.txt nouveau_combine.txt pour vous assurer que la sortie est identique, et time pour mesurer l'amélioration. Sur un répertoire avec 5000 petits fichiers, l'original peut prendre 30 secondes, tandis que la version find -exec cat {} + prend moins d'une seconde.

Vérification et diagnostics

Pour savoir si votre optimisation fonctionne, vous avez besoin de métriques fiables. Voici les commandes clés :

• time (intégré au shell) : mesure le temps réel, utilisateur et système.
• /usr/bin/time (externe) : fournit des statistiques plus détaillées avec -v.
• strace : trace les appels système pour voir où le temps est passé.
• bash -x : affiche chaque commande exécutée, utile pour trouver des erreurs de logique mais ajoute une surcharge.

Exemple d'utilisation de /usr/bin/time pour capturer des statistiques détaillées :

/usr/bin/time -v ./mon_script.sh

Fragment de sortie exemple :

Maximum resident set size (kbytes): 28372
Page faults (major): 0
Page faults (minor): 1230
Voluntary context switches: 253
Involuntary context switches: 45
System time (seconds): 0.11
User time (seconds): 2.34
Elapsed (wall clock) time (h:mm:ss or m:ss): 0:02.45

Un temps système élevé par rapport au temps utilisateur peut indiquer des E/S lourdes ou de nombreuses créations de processus.

Utilisez strace pour voir les appels système réels. Pour un script qui lance cat à plusieurs reprises, vous verriez de nombreux appels execve. Pour les compter :

strace -c -f ./mon_script.sh 2>&1 | grep execve

Si vous voyez des centaines ou des milliers d'appels execve, c'est votre goulot. Réduisez-les en utilisant des commandes intégrées au shell, en regroupant les commandes ou en réécrivant la logique.

Un autre problème courant est l'utilisation de echo dans une boucle serrée. echo est une commande intégrée dans Bash moderne, mais chaque itération entraîne tout de même une surcharge. Remplacer une boucle qui fait de nombreux echo par un seul printf peut donner une accélération de 10 à 50 %.

Modes d'échec et récupération

Les optimisations peuvent introduire des bugs subtils. Voici les modes d'échec les plus courants et comment les récupérer.

1. Changements de découpage des mots et d'expansion des noms de fichiers.

Si vous changez une boucle pour utiliser xargs ou find, vous pouvez oublier de gérer les espaces et les caractères spéciaux dans les noms de fichiers. Par exemple :

find . -name '*.txt' -print | xargs cat > combine.txt

Cela casse si les noms de fichiers contiennent des espaces ou des retours à la ligne. La version sûre utilise des séparateurs nuls :

find . -name '*.txt' -print0 | xargs -0 cat > combine.txt

Récupération : testez toujours avec des noms de fichiers contenant des espaces et des retours à la ligne. Utilisez touch 'fichier avec espace.txt' et vérifiez la sortie.

2. Régression de portabilité.

Vous pouvez introduire des fonctionnalités spécifiques à bash dans un script qui tournait auparavant sous sh. Par exemple, utiliser [[ ]] au lieu de [ ]. Si le script est déployé sur un système où sh est dash, il échouera. Vérifiez la ligne shebang et assurez-vous qu'elle est #!/bin/bash si vous utilisez des fonctionnalités Bash.

Récupération : exécutez le script avec bash -n pour la vérification syntaxique et shellcheck pour les avertissements de portabilité.

3. Problèmes de mise en tampon et de vidage.

Lorsque vous regroupez la sortie avec printf au lieu d'echo, la sortie peut être mise en mémoire tampon et ne pas apparaître immédiatement. Si le script est utilisé pour la surveillance et produit des lignes sporadiquement, vous pouvez perdre la visibilité en temps réel. Utilisez stdbuf -oL pour une sortie avec tampon de ligne si nécessaire :

stdbuf -oL ./mon_script.sh

4. Fuites de descripteurs de fichiers ou mauvaise utilisation.

Si vous redirigez manuellement de nombreux descripteurs de fichiers, vous pouvez oublier de les fermer, ce qui fait que le script épuise les descripteurs de fichiers. Fermez toujours avec exec {fd}>&- quand vous avez terminé. Surveillez avec ls /proc/$$/fd | wc -l à l'intérieur du script.

5. Changement de sémantique de $@.

Lorsque vous remplacez des boucles par des tableaux, assurez-vous de citer correctement. "${tableau[@]}" préserve chaque élément comme un mot séparé, tandis que "${tableau[*]}" les joint. Une mauvaise citation peut altérer le passage d'arguments.

Gardez toujours la version originale du script et exécutez les deux versions sur un jeu d'entrées représentatif, en comparant la sortie avec diff. Si la version optimisée produit une sortie différente, déboguez immédiatement et si nécessaire, revenez à l'original.

Liste de contrôle des opérations

Cette liste de contrôle sert à améliorer les performances d'un script Bash sans le casser. Chaque élément inclut une étape de vérification concrète.

Par exemple, si vous optimisez un script d'ingestion de données, le responsable peut être l'ingénieur de la plateforme de données. Il exécute la suite de tests sur un jeu de données d'échantillon, mesure le temps et compare les sorties. Le plan de retour en arrière consiste à restaurer la version précédente depuis le contrôle de version.

Pièges courants et comment les éviter

De nombreux problèmes de performance Bash proviennent d'habitudes qui sont inoffensives dans les petits scripts mais fatales à grande échelle.

Piège 1 : Utiliser cat fichier | while read.

Cela crée un sous-shell et peut être extrêmement lent pour les gros fichiers. Par exemple :

cat grosfichier.txt | while read ligne; do
  # traitement
  echo "$ligne" | tr 'a-z' 'A-Z'
done

Pour 1 million de lignes, cela peut prendre des minutes car chaque echo | tr crée deux processus. Une alternative plus rapide :

while IFS= read -r ligne; do
  traite="${ligne^^}"   # expansion en majuscules Bash 4+
  printf '%s\n' "$traite"
done < grosfichier.txt

Cela utilise uniquement des commandes intégrées au shell et lit directement du fichier. Sur un test de 100 000 lignes, la première version a pris 35 secondes, la seconde 1,5 seconde.

Piège 2 : Ne pas utiliser les commandes intégrées au shell quand c'est possible.

Les commandes externes comme sed, awk, cut et grep sont puissantes mais coûteuses à lancer dans une boucle. Par exemple, extraire le premier champ d'un fichier séparé par des deux-points ligne par ligne :

while read ligne; do
  echo "$ligne" | cut -d: -f1
done < /etc/passwd

Remplacez par l'expansion de paramètres :

while IFS=: read -r champ1 reste; do
  printf '%s\n' "$champ1"
done < /etc/passwd

Pour un gros fichier, cela peut réduire le temps d'exécution de 80 à 90 %.

Piège 3 : Lectures de fichiers excessives dans une boucle.

Lire le même fichier de manière répétée à l'intérieur d'une boucle est une erreur courante. Par exemple, vérifier si un utilisateur existe dans une liste :

for utilisateur in "$@"; do
  if grep -q "^$utilisateur$" liste_utilisateurs.txt; then
    echo "$utilisateur existe"
  fi
done

Si liste_utilisateurs.txt a 10 000 entrées et que vous bouclez sur 1000 utilisateurs, vous exécutez grep 1000 fois, chacun balayant le fichier. À la place, chargez le fichier dans un tableau associatif une fois :

declare -A map_utilisateurs
while IFS= read -r utilisateur; do
  map_utilisateurs["$utilisateur"]=1
done < liste_utilisateurs.txt

for utilisateur in "$@"; do
  if [[ -n ${map_utilisateurs[$utilisateur]} ]]; then
    echo "$utilisateur existe"
  fi
done

Cela transforme un algorithme quadratique en linéaire. Dans un test, l'original a pris 12 minutes ; la version avec tableau a pris 2 secondes.

Piège 4 : Variables non citées.

L'expansion de variables non citées peut déclencher l'expansion des noms de fichiers et le découpage de mots, ce qui peut causer un comportement inattendu et même une dégradation des performances si le shell tente d'étendre un joker. Citez toujours : "$var".

Piège 5 : Ne pas utiliser set -e et la gestion des erreurs.

Une optimisation de performance peut introduire une erreur qui passe inaperçue si le script continue. Utilisez set -euo pipefail en haut de votre script pour échouer rapidement et attraper les problèmes. Cela aide aussi pour les performances car vous évitez de faire un travail inutile après une erreur.

Piège 6 : Ignorer la mise en tampon des E/S.

Les petites écritures fréquentes sont lentes. Si vous ajoutez à un fichier journal une ligne à la fois, envisagez de regrouper les écritures ou d'utiliser un tampon. Par exemple, accumulez des lignes dans une variable et écrivez quand elle atteint une certaine taille. Cela peut réduire les E/S disque d'un facteur 10 ou plus.

Piège 7 : Utiliser sleep pour l'attente active.

Si vous attendez un fichier ou une ressource, sleep 1 dans une boucle peut s'accumuler. Utilisez inotifywait (du paquet inotify-tools) pour attendre des événements de fichier sans scrutation :

inotifywait -e close_write /chemin/vers/repertoire

Cela retourne immédiatement quand le fichier est fermé après écriture, économisant du CPU et du temps.

Piège 8 : Exécuter des commandes externes dans $() de façon répétée.

Par exemple, $(date) dans une boucle. Capturez la valeur une fois si elle ne change pas dans la boucle.

Conclusion

L'optimisation des performances Bash est une compétence pratique qui rapporte immédiatement. En mesurant les performances de référence, en identifiant les points chauds, en appliquant des optimisations ciblées et en vérifiant les résultats, vous pouvez transformer un script lent en un script rapide et fiable.

Rappelez-vous que l'objectif n'est pas de rendre chaque ligne de Bash parfaitement optimisée, mais de supprimer les goulots d'étranglement qui comptent. Un seul changement, comme remplacer cat par fichier par un find -exec groupé, peut apporter une amélioration de 10x ou plus.

Appliquez les techniques de ce guide à vos propres scripts. Commencez par profiler avec time et strace. Ensuite, utilisez la liste de contrôle des opérations pour améliorer systématiquement les performances tout en maintenant la correction. Gardez un plan de retour en arrière à proximité, et documentez ce que vous changez. Avec le temps, ces pratiques deviennent habituelles, et vos scripts Bash s'exécuteront plus rapidement avec moins d'effort.