Cette astuce Linux empêche les plantages de Next.js.

Vous exécutez `next build` sur un nouveau serveur Ubuntu et tout semble bien pendant environ 10 secondes. Puis, la charge moyenne explose, le CPU atteint 100%, et votre session SSH commence à perdre des caractères comme lors d'un mauvais appel Zoom. Une minute plus tard, le terminal revient avec un mot unique et frustrant : « Tué. »

Pas de trace de pile, pas de code d'erreur soigné, juste une construction morte. Relancez-la et vous obtiendrez le même schéma : les ventilateurs s'activent, le haut affiche Node et une nuée de travailleurs grignote le processeur, puis le silence. Si vous consultez les graphiques de votre fournisseur par la suite, vous voyez un pic aigu de CPU et de mémoire, suivi d'une chute où votre processus a disparu.

Ce mode de défaillance touche particulièrement les options les moins chères du cloud. Ces instances à 1 Go de RAM à 5–7 $/mois chez DigitalOcean, Vultr, Linode ou Lightsail sont parfaites pour une application Node basique—jusqu'à ce que vous leur demandiez de exécuter une build Next.js moderne. Pendant cette période de construction, votre « minuscule mais puissant » droplet se comporte soudainement comme un Raspberry Pi essayant de compiler Chrome.

Les développeurs répondent généralement à cela avec le réflexe le plus coûteux dans le cloud computing : supposer que le matériel est le problème. L'histoire se déroule de la même manière à chaque fois. La construction échoue, le serveur semble figé, et la réaction instinctive est : « Cette machine ne peut tout simplement pas gérer Next.js. J'ai besoin de 2 Go, peut-être 4 Go. »

Les tableaux de bord cloud vous y incitent même. Vous voyez la mémoire saturée, le CPU à son maximum, et un événement rouge « mémoire pleine » dans les journaux. Le bouton de mise à niveau est à un clic, promettant qu'un niveau d'instance plus grand fera disparaître le problème. Pour de nombreuses équipes, ce clic devient une partie intégrante du manuel de déploiement.

La réalité est moins glamour et beaucoup moins chère. Ces plantages ne signifient généralement pas que votre application nécessite en permanence une machine plus grande ; ils signifient que votre étape de construction a temporairement besoin de plus de mémoire que ce que votre instance peut fournir. Et sur une image Ubuntu par défaut avec le swap désactivé, le noyau n'a qu'une seule façon fiable de faire face à ce pic : tuer votre build.

Next.js apparaît comme un unique processus `node` sur `htop`, mais `next build` se comporte plutôt comme un petit système distribué compressé dans un seul binaire. Sous le capot, Next.js orchestre plusieurs travailleurs Node, une chaîne d'outils TypeScript, un empaqueteur et des pipelines d'actifs, tous en concurrence pour le même espace limité de 1 Go de RAM.

Commencez par Node lui-même. Le processus principal lance plusieurs threads de travail ou processus enfants pour paralléliser la compilation de pages. Chaque travailleur charge son propre extrait du graphe de dépendances, des tas V8 et des métadonnées de construction. Au lieu d'un processus de 200 à 300 Mo, vous obtenez brièvement plusieurs, et leurs pics s'accumulent.

Ensuite, l'histoire de TypeScript. Lorsque vous exécutez `next build` sur un projet TypeScript, la chaîne d'outils charge le compilateur TypeScript, analyse l'ensemble de votre codebase et effectue une vérification des types. Cela signifie que plusieurs grands AST, tables de symboles et caches résident en mémoire en même temps, atteignant souvent des centaines de mégaoctets sur des projets de taille moyenne.

De plus, Next.js invoque un bundler (Webpack ou Turbopack) pour générer à la fois les bundles client et serveur. Chaque cible nécessite son propre graphe de dépendances, des passes d'optimisation et des cartes sources. Les grandes bibliothèques de composants, les frameworks UI et les systèmes de design gonflent ces graphes, de sorte qu'un projet qui fonctionne bien avec 300 à 400 Mo en production peut atteindre 800 à 900 Mo ou plus lors d'une construction.

Viennent ensuite les images et les éléments statiques. Lorsque vous activez next/image ou traitez de grands médias, le pipeline de construction décode, redimensionne et recomprime les fichiers. Les opérations sur les images consomment beaucoup de mémoire : quelques images héroïques en 4K ou feuilles de sprites peuvent occuper temporairement des dizaines ou des centaines de mégaoctets par travailleur avant d'être réécrites sur le disque.

Tout cela se produit dans une fenêtre étroite de quelques secondes à quelques minutes. Imaginez un café de 20 places qui accueille soudainement une flash mob de 60 personnes. Le trafic normal fonctionne bien, mais cette courte poussée chaotique bloque les portes, submerge le personnel et laisse les habitués coincés à l'extérieur. `next build` crée exactement ce type de surcharge temporelle sur un droplet de 1 Go.

Sur un serveur Ubuntu de 1 Go sans swap, cette foule en folie pousse l'utilisation de la mémoire au-delà de la limite physique. Le noyau commence à récupérer de manière agressive, les caches disparaissent, et lorsque la RAM n'est toujours pas suffisante, le tueur OOM intervient et termine les processus les plus lourds. Votre `prochain build` meurt avec un épitaphe en un mot : `Tué`.

Le tueur OOM semble dramatique parce qu'il l'est. Lorsque un système Linux manque de RAM physique, le tueur Out-Of-Memory (OOM) du noyau intervient comme une soupape de sécurité de dernier recours, analysant chaque processus en cours d'exécution et décidant lequel sacrifier pour éviter que l'ensemble de la machine ne se bloque. Sans lui, un droplet Ubuntu de 1 Go sous pression mémoire gelerait simplement, interrompant les sessions SSH et vous laissant avec un terminal mort et un redémarrage forcé.

Les builds Next.js font de parfaits cibles. Pendant `next build`, Node lance plusieurs processus de travail, charge des compilateurs comme TypeScript, traite des bundles, et parfois gère des images, ce qui fait facilement grimper l'utilisation de la mémoire de plusieurs centaines de mégaoctets au-dessus du niveau de base en une courte poussée. Pour le noyau, cela ressemble à un processus important, récent et non essentiel qui peut être arrêté avec un impact "système global" minimal.

Linux utilise une heuristique appelée oom_score (et oom_score_adj) pour classer les victimes. Les grands processus qui ont récemment alloué beaucoup de mémoire, ne fonctionnent pas en tant que root et n'appartiennent pas aux services essentiels du système, remontent en tête. Un build Next.js sur un droplet de 1 Go, déjà à côté de nginx, sshd, et peut-être une petite base de données, devient souvent la chose la plus gourmande et la plus jetable dans la RAM.

Aucun échange ne modifie totalement les enjeux. Lorsque la RAM atteint 100 % et qu'aucun échange n'est configuré, le noyau n'a que deux options : bloquer tout en tentant désespérément de récupérer des pages, ou invoquer le tueur OOM. Ce choix binaire explique pourquoi votre terminal se fige un instant puis affiche un seul mot – "Tué" – sans trace de pile, sans erreur Next.js, et sans indice utile de Node.

Cette ligne « Tué » n'est pas une impolitesse de npm ; c'est la signature du noyau. Vous la verrez sur les échecs de `pnpm install`, `npm install` ou `next build` lorsque le tueur OOM termine le processus en plein vol. Les journaux système (`dmesg` ou `journalctl -k`) révèlent généralement le coupable avec des entrées telles que « Mémoire insuffisante : tuer le processus 1234 (node) score 900 ou sacrifier l'enfant. »

L'échange permet au noyau d'avoir un autre moyen d'agir. Même avec un fichier d'échange de 1 à 2 Go, le système peut transférer des pages froides—démons inactifs, pages de cache, bibliothèques peu utilisées—sur le disque, libérant de la RAM afin que la compilation puisse se terminer plutôt que d'être interrompue. Pour des conseils étape par étape, des ressources telles que Comment créer un fichier d'échange pour déployer une application NextJS et Docker sur un VPS Ubuntu expliquent comment mettre en place un environnement adapté à la production.

L'espace d'échange agit comme une soupape de pression pour la mémoire de votre petit serveur. Au lieu de tuer immédiatement `next build` lorsque la RAM atteint 100%, le noyau Linux peut déverser les données excédentaires dans une partie dédiée du disque et continuer son fonctionnement. Cette partie est votre fichier d'échange.

Considérez l'échange comme une "mémoire RAM de débordement" qui réside sur le stockage plutôt que sur le silicium. Linux crée un fichier ou une partition sur le disque et le considère comme une extension de la mémoire physique, mesurée en mêmes pages de 4 Ko que la RAM classique utilise.

Lorsque votre droplet de 1 Go manque de RAM lors d'une construction Next.js, le noyau commence la gestion des priorités. Les pages appartenant aux démons inactifs, aux anciens caches ou aux services en arrière-plan sont déplacées de la RAM vers le fichier d'échange, libérant ainsi de la mémoire réelle pour les chemins de code chaud de la construction.

Le noyau le fait automatiquement grâce à son gestionnaire de mémoire virtuelle. Vous n'avez pas besoin de réécrire votre application ni de toucher aux options de Node ; une fois que le swap existe et est actif, le système déplace discrètement les pages les moins utilisées et réserve la mémoire la plus rapide pour la tâche qui effectue le plus de travail.

Le disque est lent par rapport à la RAM — des millisecondes au lieu de nanosecondes — donc l'utilisation de l'échange ajoute toujours de la latence. Cependant, pour un build éphémère, la stabilité l'emporte sur la vitesse : un `next build` qui se termine en 90 secondes sur un serveur en échange est bien mieux qu'un qui s'arrête après 20 secondes avec un seul mot, “Tué”.

Sur un serveur avec swap configuré, ce même pic de mémoire brutal semble ennuyeux. Le CPU continue de monter, les ventilateurs tournent, mais votre session SSH reste réactive, `top` montre l'utilisation du swap augmenter, et la construction se poursuit plutôt que de faire exploser la table des processus.

Sur un serveur sans swap, le noyau n'a pas de sortie de secours. Une fois que la RAM est pleine, il soit se fige en luttant pour récupérer des pages, soit invoque le tueur OOM, terminant Node, votre gestionnaire de paquets, ou tout autre processus jugé dispensable juste pour rester en vie.

Ce contraste est frappant : avec swap, les constructions semblent lourdes mais fiables ; sans lui, la même charge de travail peut faire planter votre shell, endommager votre déploiement et vous obliger à surveiller un droplet redémarré.

Commencez par confirmer si votre machine Ubuntu possède déjà un swap. Exécutez `sudo swapon --show`. Un résultat vide signifie qu'il n'y a pas de dispositifs swap actifs. Suivez avec `free -h` pour voir la RAM totale et le swap actuel, puis `df -h` pour vérifier l'utilisation du disque. Sur un droplet typique de 25 Go, vous verrez généralement moins de 20 % utilisés, ce qui laisse amplement de place pour un fichier swap de 2 Go.

Avec l'espace disque confirmé, allouez le fichier d'échange. Pour un serveur avec 1 Go de RAM, un fichier de 2 Go offre à Next.js des marges de manœuvre sans thrashing du disque. Utilisez `sudo fallocate -l 2G /swapfile`. Cela réserve 2 Go instantanément sans réellement écrire de zéros. Vérifiez-le avec `ls -lh /swapfile` et vous devriez voir `2.0G` dans la colonne de taille.

En ce moment, `/swapfile` est juste un fichier ordinaire que n'importe qui pourrait toucher. Verrouillez-le afin que seul le root puisse lire ou écrire. Exécutez `sudo chmod 600 /swapfile`. Vérifiez à nouveau les permissions avec `ls -lh /swapfile` et vous devriez voir `-rw-------` au début de la ligne, ce qui confirme que le fichier est privé au root.

Ensuite, transformez ce fichier ordinaire en véritable espace d'échange. Utilisez `sudo mkswap /swapfile`. Ubuntu répondra par un message comme `configuration de l'espace d'échange version 1, taille = 2 GiB`. Ce message signifie que le noyau reconnaît maintenant `/swapfile` comme une zone d'échange valide, mais elle reste inactive jusqu'à ce que vous l'activiez explicitement.

Activez l'échange avec une seule commande : `sudo swapon /swapfile`. Exécutez à nouveau `sudo swapon --show` et vous devriez maintenant voir un tableau répertoriant `/swapfile`, sa taille (environ `2G`) et sa priorité. `free -h` affichera également `Swap: 2.0Gi` dans le récapitulatif, confirmant que le noyau peut maintenant décharger les pages de mémoire lorsque les allocations de mémoire Next.js augmentent.

Pour que cette configuration survive aux redémarrages, vous devez la rendre permanente. Modifiez `/etc/fstab` avec `sudo nano /etc/fstab` et ajoutez une ligne en bas :

- `/swapfile none swap sw 0 0`

Enregistrez, quittez et c'est terminé. Lors du prochain redémarrage, Ubuntu activera automatiquement `/swapfile`, de sorte que vos builds Next.js continuent de fonctionner même après des mises à jour du noyau, des redémarrages ou des plantages inattendus.

L'échange que vous venez de créer ne survit que le temps du démarrage actuel. La commande `swapon /swapfile` active un commutateur en cours d'exécution ; dès que le noyau redémarre, cet état disparaît et vos constructions Next.js recommencent à s'arrêter avec l'état `Tué`.

Pour garder le swap en ligne entre les redémarrages, vous devez l'enregistrer dans `/etc/fstab`, le tableau du système de fichiers que Linux lit au démarrage. Ce fichier indique au noyau quels disques, partitions et zones de swap monter automatiquement.

Avant de le modifier, faites une sauvegarde. Un fichier `/etc/fstab` corrompu peut empêcher le serveur de démarrer, vous laissant à la recherche d'une console de récupération sur votre tableau de bord cloud.

Courir :

- `sudo cp /etc/fstab /etc/fstab.bak`

Maintenant, ouvrez le fichier avec un éditeur capable de permissions root, par exemple :

- `sudo nano /etc/fstab`

Faites défiler vers le bas et ajoutez cette ligne exacte :

- `/swapfile aucun échange sw 0 0`

Chaque champ compte. `/swapfile` est le chemin vers votre fichier d'échange. `none` représente un point de montage, car l'échange ne se monte pas dans l'arborescence des répertoires.

`swap` déclare le type de système de fichiers, informant le noyau que cette entrée est de la mémoire virtuelle, et non ext4 ou xfs. `sw` est l'option de montage définie, un raccourci pour "considérer ceci comme de la mémoire échange avec le comportement par défaut."

Les deux derniers zéros contrôlent le comportement de `dump` et `fsck`. `0 0` signifie que le système n'essaiera pas de faire un dump ni d'effectuer de vérifications de système de fichiers sur ce fichier, ce qui est exactement ce que vous souhaitez pour la mémoire d'échange.

Après avoir enregistré, validez la syntaxe avec :

- `sudo mount -a`

Aucun résultat signifie généralement succès. Redémarrez avec `sudo reboot`, puis confirmez la persistance en utilisant `free -h` ou `swapon --show`. Pour un réglage plus approfondi et des informations sur les performances du swap, consultez Superchargez votre système Linux avec l'espace de swap - Kite Metric.

Swap se comporte comme une soupape de pression pour la mémoire, et non comme une mise à niveau de performance gratuite. Utilisé avec prudence, il maintient une petite goutte de 1 Go en vie suffisamment longtemps pour que les builds Next.js soient terminés. Utilisé négligemment, il peut mettre un app de production à terre.

Quand utiliser swap : des pics de mémoire brefs et aigus. Un `next build` qui s'exécute pendant 2 à 5 minutes, augmentant brièvement l'utilisation de 700 à 800 Mo à 1,3 à 1,5 Go, est parfait. Le noyau peut évacuer des pages froides vers le disque, libérer quelques centaines de mégaoctets, et votre build se termine au lieu d'être "tué".

Les mêmes règles s'appliquent à d'autres tâches sporadiques qui s'exécutent rarement et ne servent pas le trafic en direct. De bons candidats incluent : - `npm install`, `pnpm install` ou `yarn install` - Migrations de base de données ou importations de données uniques - Scripts d'administration ou de maintenance occasionnels - Étapes de déploiement dans des conteneurs ou des agents CI

Dans ces cas, votre application utilise bien moins de RAM physique—disons 300 à 500 Mo sur un serveur de 1 Go—et n'a besoin d'espace supplémentaire que pendant les constructions ou les installations. Vous troquez un peu de vitesse pour la fiabilité : une construction peut s'exécuter 20 à 40 % plus lentement en utilisant le swap, mais elle se termine en réalité. Pour de nombreuses équipes, rester sur un plus petit droplet compense immédiatement ce coût.

Quand ne pas utiliser le swap : pression mémoire stable de votre application principale. Si votre serveur Next.js et votre base de données demandent ensemble 1,4 Go sur une instance de 1 Go toute la journée, le noyau déplace constamment les pages mémoire entre la RAM et le disque. Ce thrashing détruit la performance, car le disque, même en SSD, est de plusieurs ordres de grandeur plus lent que la RAM.

Vous pouvez repérer un swap nuisible avec quelques symptômes concrets : - Une entrée/sortie disque élevée (`iostat`, `iotop`) même avec un faible volume de requêtes - Des réponses HTTP lentes ou des délais d'attente avec seulement quelques utilisateurs - `free -h` affichant des centaines de mégaoctets de swap utilisés et à peine en baisse au repos - Une moyenne de charge en forte hausse tandis que l'utilisation du CPU reste étrangement modeste

Si ces signaux d'alerte apparaissent, le swap fonctionne comme un pansement sur une plaie par balle. La véritable solution est plus de RAM ou des budgets mémoire plus stricts : réduisez le nombre de travailleurs Node, diminuez les tailles de cache, scindez les services ou déplacez la base de données hors de la boîte. Le swap devrait gérer des pics rares, et non soutenir votre application 24/7.

Swap vous offre de la marge de manœuvre, mais un autre saboteur silencieux peut encore faire échouer votre construction : Node.js lui-même. Si Node décide qu'il "a besoin" de 8 Go de mémoire vive sur un serveur de 1 Go, aucun tour de magie avec le swap ne vous sauvera du tueur OOM. C'est là qu'un seul drapeau obscur change tout.

Le drapeau `--max-old-space-size` de Node contrôle la quantité de mémoire que le moteur V8 peut utiliser pour son tas JavaScript principal, mesurée en mégaoctets. Lorsque cette limite est trop élevée, Node réserve de manière agressive de la mémoire que votre machine ne possède tout simplement pas, et le noyau réagit en tuant le processus une fois que la RAM et le swap sont épuisés.

Les projets Next.js cachent souvent ce piège dans `package.json`. Enfoui dans la section `scripts`, vous pourriez voir une commande de construction comme : - `"build": "NODE_OPTIONS='--max-old-space-size=8192' next build"`

Sur un droplet de 1 Go, cet objectif de 8192 Mo de mémoire heap est un fantasme. Node essaiera volontiers d'y atteindre, vos 1 Go de RAM et peut-être 1 à 2 Go d'espace d'échange s'évaporeront, et votre compilation se terminera avec le même message abrupt `Killed` que vous avez rencontré au départ.

Première étape : ouvrez le fichier `package.json` de votre projet et inspectez tous les scripts liés à la construction. Recherchez tout ce qui définit `NODE_OPTIONS` ou qui passe directement `--max-old-space-size` à `node` ou `next`, par exemple : - `"build": "NODE_OPTIONS='--max-old-space-size=4096' next build"` - `"build": "node --max-old-space-size=6144 node_modules/next/dist/bin/next build"`

Alignez ensuite ce chiffre avec votre budget réel : RAM physique + swap, moins les frais généraux pour le système d'exploitation, la base de données et les services en arrière-plan. Sur un serveur de 1 Go avec un fichier d'échange de 2 Go (environ 3 Go au total), une limite `--max-old-space-size=2048` a généralement du sens et laisse de la marge pour tout le reste.

Mettez à jour le script, réinstallez ou redéployez et exécutez à nouveau `next build`. Avec l'échange activé et le tas de Node limité à quelque chose de réaliste, vos builds cessent de prétendre fonctionner sur un poste de travail de 64 Go et commencent à se comporter comme s'ils vivaient sur un petit droplet bon marché.

Swap silencieusement corrige plus que des constructions Next.js instables. Toute charge de travail qui occasionnellement augmente l'utilisation de la mémoire sur un petit VPS ou une machine de développement bénéficie de quelques gigaoctets de mémoire virtuelle supplémentaires sur lesquels se reposer au lieu de se heurter au tueur OOM.

Les gestionnaires de paquets sont des récidivistes à cet égard. Un seul `npm install`, `pnpm install` ou `yarn install` sur un monorepo moderne peut faire tourner des dizaines de travailleurs Node, décompresser des milliers de tarballs et calculer des arbres de dépendances en mémoire. Sur un serveur de 1 Go, cela peut facilement faire dépasser l'utilisation de la RAM de 90 à 100 % pendant plusieurs minutes.

Les scripts lourds d'importation de données et de migration se comportent de la même manière. Les tâches ETL qui ingèrent quelques centaines de mégaoctets de JSON ou de CSV en mémoire, les migrations Prisma ou TypeORM qui hydrates de grands schémas, ou les scripts administratifs ad hoc qui traitent par lots des enregistrements utilisateur créent tous des pics de mémoire courts et brutaux. Avec l'échange activé, ces pics ralentissent au lieu de faire exploser votre session SSH.

Les outils de base de données s'appuient également sur la RAM. L'exécution de `pg_restore` sur un dump PostgreSQL de plusieurs gigaoctets, l'importation d'un instantané MySQL ou l'exécution de la réindexation d'Elasticsearch peuvent temporairement allouer des centaines de mégaoctets de tampons et de caches. Un fichier d'échange de 1 à 2 Go permet au noyau de stationner les pages inactives pendant que les chemins de code actifs restent dans la RAM réelle.

Les environnements conteneurisés ajoutent une couche supplémentaire de fragilité. Un conteneur Docker construisant une application Next.js, compilant des modules natifs ou exécutant des tests pourrait atteindre sa limite de mémoire cgroup bien avant que l'hôte ne le fasse. L'espace de swap au niveau de l'hôte agit souvent comme le dernier tampon qui empêche le noyau de tuer le conteneur en pleine construction.

Le développement local n'est pas non plus épargné. Exécuter `next dev`, Storybook, une base de données et un navigateur rempli d'onglets sur un ordinateur portable de 8 Go peut rapidement consommer de la mémoire. Associer un petit fichier d'échange avec des pratiques de Comment optimiser votre environnement de développement local - Next.js maintient votre machine réactive pendant que tout se compile.

Les problèmes de mémoire sur les petits serveurs n'ont généralement pas besoin d'une plus grande carte de crédit. Ils nécessitent un diagnostic. Avant de passer d'un droplet de 1 Go à 5 $/mois à une instance de 20 $/mois, vérifiez si les constructions Next.js deviennent excessives en raison d'une utilisation de mémoire courte et sporadique ou d'une fuite lente et constante.

Un simple organigramme mental vous garde honnête :

- Le crash se produit-il uniquement lors de tâches courtes et peu fréquentes (constructions Next.js, `npm install`, migrations) ? → Ajoutez d'abord de la mémoire virtuelle, puis relancez la tâche. - Le serveur semble-t-il lent lors d'un trafic normal, avec une utilisation élevée de la mémoire virtuelle et une latence accrue ? → Profilage de la mémoire, optimisation des requêtes et des caches, ou mise à niveau de la RAM. - L'utilisation de la mémoire virtuelle reste-t-elle élevée même lorsque l'application est « idle » ? → Vous masquez un véritable problème de capacité, sans le résoudre.

Pour des charges de travail variables, un fichier d'échange de 1 à 2 Go sur une machine avec 1 Go de RAM empêche souvent le OOM killer de détruire votre construction. Vous échangez quelques secondes ou minutes de temps de construction contre une construction qui se termine réellement. C'est une bonne affaire lorsque les déploiements se produisent quelques fois par jour, et non des milliers de fois par seconde.

Les calculs de coûts rendent l'argument brutal et clair. Rester sur une instance à 5 $ par mois au lieu de passer à 15 $ permet d'économiser 10 $ chaque mois, soit 120 $ par an, par serveur. Échelonnez cela sur 5 petits services et vous conservez 600 $ par an dans votre poche pour le prix d'un `fallocate` unique et d'une ligne dans `/etc/fstab`.

Le dimensionnement intelligent signifie empiler des outils, pas acheter automatiquement des machines plus grandes. Utilisez swap pour gérer les pics rares, ajustez les paramètres de mémoire Node.js lorsque les constructions continuent de mal se comporter, et seulement ensuite passez à un niveau supérieur lorsque votre utilisation à l'état stable prouve que vous en avez réellement besoin.

Vous vous retrouvez avec une infrastructure que vous comprenez plutôt qu'une infrastructure que vous craignez. Lorsque une construction échoue avec “Tué”, vous savez qu'il faut vérifier la mémoire, l'échange et les limites de Node.js avant d'ouvrir la page de tarification de votre fournisseur de cloud. Cette connaissance transforme l'évolutivité d'un acte de panique en un choix délibéré et rentable.

Pourquoi les builds de Next.js utilisent-ils autant de mémoire ?

Les builds de Next.js consomment beaucoup de mémoire car ils démarrent plusieurs processus de travail pour compiler TypeScript, regrouper le code client et serveur, et traiter les ressources comme les images simultanément. Ce bref mais intense pic d'activité peut rapidement submerger des serveurs avec une RAM limitée, comme des gouttes de nuage de 1 Go.

L'utilisation d'un fichier d'échange Linux est-elle mauvaise pour les performances ?

Le swap est nettement plus lent que la RAM, donc il peut nuire aux performances si votre application en dépend constamment pour ses opérations quotidiennes. Cependant, pour de courtes et rares augmentations de mémoire comme un processus de compilation, ce léger ralentissement est un compromis valable pour la stabilité, car il permet à la compilation de se terminer avec succès au lieu de planter.

Combien d'espace d'échange devrais-je ajouter pour une build Next.js ?

Une bonne règle générale pour un petit serveur (1-2 Go de RAM) est d'ajouter un espace d'échange égal ou double à la quantité de RAM physique. Pour un droplet de 1 Go, créer un fichier d'échange de 1 à 2 Go est souvent suffisant pour gérer les pics de mémoire pendant une construction Next.js.

Puis-je utiliser un échange au lieu de mettre à niveau la RAM de mon serveur ?

Vous pouvez utiliser le swap pour éviter une mise à niveau si vos problèmes de mémoire sont causés par des pics temporaires (comme des compilations ou des installations de packages). Si l'utilisation quotidienne de mémoire de votre application dépasse régulièrement la RAM de votre serveur, vous devriez augmenter votre RAM, car compter sur le swap pour le trafic de production entraînera de mauvaises performances.