le serveur raccroche ; pas de réponse, mais pas de déconnexion non plus

Un redémarrage était nécessaire. L'attendre n'a rien donné.

Après une enquête plus approfondie, il a été découvert qu'il y avait une fuite de mémoire dans la bibliothèque Perl IMAP utilisée. À l'origine, j'avais configuré le script Perl pour charger tous les comptes de messagerie dans un tableau (à partir d'un fichier texte référencé à partir de l'argument 1 de la ligne de commande), puis les parcourir en boucle en exécutant le code de migration pour chaque compte. Pour chaque itération de la boucle, le script se connectait à la fois au serveur de messagerie source et aux serveurs de messagerie cible, exécutait le code de migration, puis se déconnectait des deux serveurs de messagerie. Cela a fini par consommer toute la RAM disponible, puis tout le SWAP disponible, jusqu'à ce que finalement init a tué le processus.

J'ai pensé que je pourrais accélérer les choses : J'ai utilisé screen pour exécuter 9 de ces processus, chacun sur un ensemble différent de comptes. Après avoir lancé neuf de ces processus, le système s'est rapidement ralenti, puis a cessé de répondre. Je suppose que init aurait éventuellement a tué tous les processus Perl, mais combien de temps cela aurait-il pris ? Un redémarrage était donc nécessaire.

J'ai modifié mon script de migration Perl script pour faire un compte, puis sortir. Ensuite, j'ai mis en place une boucle bash comme ceci pour parcourir tous les comptes provenant du même fichier texte :

# cat run_migration4.sh
#!/bin/bash

FILE=$1

# read $FILE using the file descriptors
exec 3<&0
exec 0<$FILE

while read line
do
        # use $line variable to process line
        echo line: $line
        ./migration4.pl $line
done
exec 0<&3

Cela a très bien fonctionné. J'ai pu en exécuter neuf en une seule session d'écran et elles ont toutes consommé une quantité insignifiante de RAM, loin de la limite 4G du serveur. La charge moyenne du serveur n'a jamais dépassé 2 ou 3. Tout s'est déroulé sans problème.