Salut les libristes !
Aujourd’hui, je vais vous raconter comment j’ai failli transformer mon petit serveur de réemploi en radiateur de compétition. Installez-vous confortablement, c’est l’histoire d’une ambition un peu trop grande pour un vaillant petit processeur.
Le plan (presque) parfait
Tout a commencé avec une idée noble : BlablaGit. Je voulais avoir mes propres miroirs de dépôts GitHub, bien au chaud à la maison sur mes machines de réemploi. Pour automatiser tout ça, j’utilise l’outil Gitea Mirror.
Dans mon esprit, j’avais séparé les choses proprement : d’un côté mes 17 dépôts personnels, et de l’autre, une organisation dédiée à mes « Favoris » GitHub. Sur mes 250 dépôts mis en étoiles, j’en avais sélectionné 45 à cloner en miroir. Total de l’opération : 62 dépôts qui tournent en boucle. Je me suis dit : « Soyons fous, c’est le paradis de l’archiviste ! »
Mais dans la réalité du processeur, c’était le début de la mutinerie.
L’apocalypse en direct
Soudain, mon tableau de bord Proxmox s’est mis à ressembler à un sapin de Noël qui aurait trop bu.
- Le CPU ? Bloqué à 100 %, en train de hurler à la mort.
- Le Load average ? Il est monté à 9.00… sur une machine qui d’habitude ronronne à 0.1.
Mon serveur essayait de survivre à une attaque massive de « moi-même ». En ouvrant un htop, j’ai vu une forêt de processus git diff-tree et git cat-file. Gitea essayait de scanner chaque ligne de code de chaque dépôt (dont certains étaient d’énormes projets communautaires) pour voir ce qui avait changé.
L’art de brider la bête (mon app.ini et Postgres)
Avant de tout casser, j’ai tenté la diplomatie technique via le fichier app.ini. Mon idée ? Imposer la politesse. Au lieu de laisser 10 ouvriers se ruer sur le CPU en même temps, j’ai dit à Gitea : « Tu en prends un seul à la fois, et tu finis ton travail avant de passer au suivant ».
Le coin du geek :
- Dans la section
[queue.mirror], j’ai fixéMAX_WORKERS = 1etBATCH_LENGTH = 1. C’est le réglage « file indienne » : un seul dépôt traité à la fois pour éviter que le CPU ne s’asphyxie.- Côté base de données, j’ai optimisé PostgreSQL avec un
MAX_OPEN_CONNSbien réglé pour que Gitea puisse discuter avec sa base sans créer de bouchons.- J’ai aussi désactivé l’indexeur de code (
REPO_INDEXER_ENABLED = false) car sur mon matériel de réemploi, scanner le contenu de chaque fichier est un luxe que je ne peux pas toujours m’offrir.
Le régime miracle : 90 Go à 3 Go
Malgré ces réglages, le constat était là : mon matériel de réemploi (Dell/HP ProDesk) n’est pas un serveur de la NASA. J’avais des miroirs de projets tiers massifs qui ne m’appartenaient pas et qui saturaient mes bus de données. Alors, j’ai sorti la grosse gomme.
- Clic. Suppression de l’organisation « Stars ».
- Clic. Je ne garde que mes 17 dépôts personnels, le vrai cœur de BlablaGit.
Le résultat est hallucinant : mon disque dur est passé de 90 Go à 3 Go. J’ai jeté 87 Go de « bruit » numérique.
Le retour au calme
Magie de la sobriété : mon CPU est redescendu instantanément à 1 %. La RAM fait la sieste à 200 Mo. Mon serveur me regarde maintenant avec reconnaissance, comme s’il venait de sortir d’un spa après un marathon.
Moralité : dans le monde du réemploi, la puissance n’est rien sans la sobriété. Je n’ai pas besoin de serveurs derniers cris pour avoir une infrastructure qui tient la route, j’ai juste besoin de savoir adapter ma gourmandise aux capacités de mon matériel.
À bientôt pour de nouvelles aventures !
Amaury aka BlablaLinux