Lorsque tu achètes un serveur, notamment une instance dans le cloud, dans la plupart des cas tu vas essayer de le dimensionner, c’est-à-dire adapter très précisément ses ressources pour trouver un équilibre entre le coût et la performance.

Le dimensionnement d’une instance repose principalement sur trois métriques : le nombre de cœurs (CPU), la quantité de RAM et l’espace disque.

Et puisque cela va avoir son importance, il faut toujours s’assurer que le disque est bien un vrai SSD, car ce n’est pas systématique.

J’ai eu la brillante idée de déplacer un serveur GitLab que j’avais configuré sur un Lightsail AWS vers une autre machine deux fois plus puissante, mais deux fois moins chère. Autant te dire que sur le papier, c’était très chouette, mais la réalité en a décidé autrement. L’installation s’est soldée par une interface GitLab inaccessible, des CPU qui tournaient à fond et un noyau qui balançait des erreurs de mémoire à tout-va.

Pourtant, tout semblait cohérent, un serveur plus puissant, des requirements GitLab respectés, puisque d’après GitLab, en environnement restreint, il faut 1 core (architecture AMD64), 3 Go de RAM et 20 Go d’espace disque. J’ai même lu plusieurs articles sur internet qui s’alignaient sur ma précédente config.

Pour être honnête, on tournait sur une version qui n’était pas la toute dernière, mais GitLab se doit de tourner sur cette configuration, surtout vu la taille de notre équipe et l’usage qu’on en fait. Donc pour moi, hors de question d’augmenter les ressources du serveur, mais je devais trouver une solution !

La première idée que j’ai eue a été de désactiver certains services pour améliorer les performances. Ça m’a permis au moins d’accéder à l’interface, mais ça n’a pas tenu longtemps puisque l’import de projets ne fonctionnait pas du tout.

Ensuite j’ai eu un éclair de génie. En un instant j’ai augmenté artificiellement la RAM en utilisant de l’espace disque. Cette technique s’appelle swap (ou « swapper ») et elle a totalement résolu le problème, mieux encore, ça nous a permis de réactiver tous les services.

Pour ajouter et configurer du swap, commence par établir une connexion SSH à ton serveur.

Ensuite, tape la commande free -h qui va t’afficher ta consommation de RAM.

De mon côté, tu peux voir que j’ai 130Mi de disponible et que je suis vraiment au ras des pâquerettes. Au niveau du swap, les valeurs sont à 0B donc il n’y a pas du tout de swap configuré.

Pour savoir s’il y a un manque de mémoire, j’installe stress un programme qui va volontairement consommer de la RAM.

Je demande au programme d’utiliser 2 giga de mémoire afin de voir ce qu’il se passe.

Quelques secondes plus tard, la console affiche des FAIL et des WARN qui m’indiquent que le test a échoué.

Il existe également une commande qui, combinée avec un grep, te permet de savoir s’il y a eu des alertes de type « out of memory » dans le système. C’est le meilleur moyen de savoir si tu as un problème de RAM.

Comme tu peux le constater, j’obtiens un joli message d’erreur, notamment depuis le programme stress.

Mon objectif maintenant est de faire en sorte qu’il n’y ait plus de problème de mémoire, et pour ce faire je vais ajouter de la mémoire swap.

Juste avant de commencer, je passe en mode super utilisateur via la commande suivante, ce qui m’évitera de taper sudo à chacune de mes commandes.

La première chose à faire est de contrôler qu’il n’y a pas déjà de swap activé. Normalement cette commande ne devrait rien afficher en console.

Ensuite je vais créer un fichier qui servira d’espace d’échange. Je peux définir sa taille ainsi que son emplacement. Moi j’ai décidé d’allouer 4G et de placer ce fichier à la racine en le nommant SWAP, j’exécute donc la commande suivante.

Je définis les droits adéquats pour ce fichier.

La commande mkswap permet de définir que ce fichier va servir de fichier d’échange.

En console tu devrais voir quelque chose qui ressemble à ceci.

Ensuite j’active le swap.

En retapant free -h, je constate que maintenant le Swap est à 4G.

Afin de vérifier le fonctionnement de la mémoire swap, je vais relancer un stress test et observer ce qu’il se passe au niveau de la RAM ainsi que ce qui est émis dans journalctl.

Cette fois-ci on peut voir qu’il n’y a plus d’erreur et que le test est passé avec succès.

Un petit coup de free -h me permet de voir que le swap est bien utilisé.

La prochaine étape est de configurer de quelle manière le swap va être utilisé, et pour ça il existe une option appelée swappiness.

Swappiness est une variable qui détermine à quelle vitesse les processus sont déplacés de la RAM vers le disque afin de libérer celle-ci. Elle prend une valeur comprise entre 0 et 100.

A la valeur 0, le noyau ne l’utilise que lorsque cela est vraiment nécessaire afin d’éviter les erreurs de manque de mémoire. 10 c’est la valeur recommandée quand le système à beaucoup de RAM. 60 est la valeur par défaut, et le système écrit immédiatement dans le Swap lorsque c’est configuré à 100.

Pour définir cette valeur, édite le fichier /etc/sysctl.conf.

Vu que je veux uniquement pallier à des problèmes d’erreur mémoire je vais choisir une valeur assez basse, j’ajoute donc la ligne suivante tout en bas du fichier.

Ensuite, tu peux charger la configuration en exécutant la commande suivante.

Malgré que le swap fonctionne, celui-ci n’est pas persistant. Si je reboot le serveur ou s’il vient à redémarrer pour une raison ou une autre, il faudra alors recommencer une partie des opérations.

Voici le résultat d’un free -h après avoir reboot. Tu peux voir qu’il n’y a plus de swap disponible.

Avec ls je peux voir que mon fichier d’échange est toujours disponible.

Je réexécute les deux commandes qui m’intéressent pour ré-activer le swap.

Je vérifie que le swap est bien activé.

Pour monter automatiquement le swap au démarrage de la machine, il va falloir l’ajouter à la table des partitions.

Commence par ouvrir le fichier /etc/fstab.

Ajoute tout en bas du fichier la ligne suivante (adapte le chemin et le nom du fichier swap en fonction de ce que tu as choisi).

Et maintenant si je reboot et qu’ensuite j’inspecte la mémoire, je vois bien que le swap est toujours présent et contient bien 4G.

Si ton application avait besoin d’un tout petit peu plus de RAM, eh bien maintenant c’est chose faite grâce au swap, et tu sais même le configurer toi-même !

Le swap ce n’est pas forcément une bonne chose, car écrire sur le disque est moins performant que sur de la RAM. Mais dans notre cas et sur l’architecture matérielle sur laquelle nous nous trouvons, on ne voit pas la différence et ça a totalement résolu notre problème.

A ce stade, j’aurais même tendance (sur des petites configurations) à toujours configurer un swap en mode swappiness 0 juste par mesure de sécurité.

Voilà, j’espère que ce tuto t’aura aidé. Tu pourras également retrouver la liste des commandes que j’ai utilisées sur la documentation officielle de Debian.