Devora Cloud · Blog
Votre site est lent ? Manque de CPU, de mémoire, ou problème de code
Apprenez à lire les graphiques CPU et mémoire, les redémarrages et les journaux (out of memory, Killed) pour choisir entre ajouter des réplicas, changer de forfait ou corriger le code.
Un site lent est l’une des plaintes les plus fréquentes — et l’une des plus coûteuses quand on répond au hasard. Beaucoup prennent un serveur plus gros et découvrent une semaine plus tard qu’il s’agissait d’une requête sans index. D’autres passent des jours à optimiser le code alors que l’application manquait simplement de mémoire.
Bonne nouvelle : les signaux sont généralement clairs quand on sait où regarder. Ce guide montre comment lire CPU, mémoire, redémarrages et journaux pour poser un diagnostic — et quand la réponse est de scaler, de changer de forfait ou de toucher au code.
D’abord, comprendre ce que mesurent les graphiques
Dans le tableau de bord Devora Cloud, les graphiques CPU et mémoire affichent le pourcentage du quota de votre application, pas celui du serveur entier. Sur le forfait Hobby, avec 0,5 vCPU et 512 Mo, 100 % de CPU signifie que ces 0,5 vCPU sont occupés ; sur Pro, que les 2 vCPU le sont.
Regardez toujours une période longue, comme les dernières 24 heures. Un pic de quelques secondes pendant un déploiement est normal. Ce qui compte, c’est la tendance : usage élevé pendant longtemps, croissance continue ou chutes brutales suivies d’un redémarrage.
Le tableau de bord vous alerte aussi quand le CPU ou la mémoire restent au-dessus de 85 % pendant au moins trois minutes — un bon point de départ pour enquêter.
Signal 1 : pas assez de CPU
Symptômes : le CPU reste au-dessus de 80 % pendant de longues périodes et les pages ralentissent précisément aux heures de pointe. La mémoire peut être tranquille.
Que faire :
- Sur Hobby (0,5 vCPU) : envisagez Pro (2 vCPU) ou Enterprise (4 vCPU).
- Sur Pro ou Enterprise : activez l’autoscaling ou ajoutez un réplica de mise à l’échelle pour répartir le trafic.
- Avant de payer plus, vérifiez qu’aucun travail lourd n’est fait à chaque requête : génération de rapports, redimensionnement d’images, traitement de gros fichiers.
Signal 2 : pas assez de mémoire
Symptômes : la mémoire dépasse 90 %, le compteur de redémarrages grimpe et les journaux affichent des messages comme ceux-ci :
- Killed — le système a arrêté le processus parce qu’il dépassait la limite de mémoire.
- out of memory ou JavaScript heap out of memory — le processus (souvent Node.js) a atteint sa limite.
- Le site tombe quelques secondes puis revient tout seul, plusieurs fois par jour.
Les réplicas ne règlent pas un manque de mémoire : chaque copie a la même limite que le forfait. La solution est souvent le forfait suivant (Hobby 512 Mo → Pro 1 Go → Enterprise 8 Go). Si la mémoire grimpe sans arrêt jusqu’à la mort du processus, cherchez aussi des fuites : caches en mémoire sans limite, listes qui ne font que grossir, fichiers entiers chargés d’un coup.
Signal 3 : le problème vient du code ou de la base
Symptômes : CPU et mémoire bas, aucun redémarrage, et pourtant les pages traînent. Là, un plus gros serveur n’aidera pas — l’application attend quelque chose.
- Requêtes lentes : index manquants, requêtes dans des boucles (le fameux N+1), tables entières chargées pour afficher dix lignes.
- API externes lentes : paiement, livraison ou e-mail appelés pendant la requête, sans délai d’expiration.
- Gros fichiers servis par l’application elle-même au lieu d’URL signées S3.
- Timeouts et erreurs 5xx dans les journaux, qui montrent précisément quelle route souffre.
La correction se fait dans le code : créer l’index, regrouper les requêtes, déplacer les tâches lourdes en arrière-plan, ajouter un cache Redis.
Tableau de diagnostic rapide
| Ce que vous voyez | Cause probable | Que faire |
|---|---|---|
| CPU élevé pendant des heures, mémoire normale | Manque de CPU | Autoscaling ou réplica (Pro/Enterprise), ou forfait avec plus de vCPU |
| Mémoire au-dessus de 90 %, redémarrages, « Killed » | Manque de mémoire | Forfait suivant ; chercher les fuites |
| CPU et mémoire bas, pages lentes | Code ou base de données | Index, moins de requêtes, cache, délais sur les API |
| Envois en échec avec QuotaExceeded | S3 plein | Supprimer des fichiers, pack supplémentaire ou forfait supérieur |
| Lent seulement pour les visiteurs éloignés | Distance jusqu’au serveur | Les applis tournent aux États-Unis ; au Brésil, le cache CDN de Devora accélère la diffusion |
Laissez votre IA faire l’analyse
Si vous utilisez le jeton IA de Devora Cloud, vous n’avez pas à faire cette lecture seul. Demandez à l’IA qui a déployé votre application « pourquoi mon site est-il lent ? ». Elle consulte les métriques CPU et mémoire des dernières 24 heures, le nombre de redémarrages de chaque réplica, les journaux de l’application et l’usage S3.
La réponse arrive avec des chiffres plutôt qu’avec des impressions — par exemple « la mémoire est restée au-dessus de 90 % et les journaux montrent des redémarrages avec Killed » — et une recommandation claire. L’IA ne change pas votre forfait et n’achète rien à votre place : cette décision reste dans le tableau de bord.
Questions fréquentes
Ajouter des réplicas règle-t-il un manque de mémoire ?
Non. Chaque réplica a la même limite de mémoire que le forfait ; si le processus manque de mémoire, c’est le cas sur toutes les copies. La solution est un forfait avec plus de RAM ou un code plus sobre.
Que signifie « Killed » dans les journaux ?
Que le processus a été arrêté parce qu’il utilisait plus de mémoire que sa limite. Le message apparaît généralement avec des redémarrages et une mémoire proche de 100 % sur le graphique.
100 % de CPU dans le tableau de bord veut-il dire que le serveur est saturé ?
Pas forcément. Le pourcentage porte sur le quota de votre application : 100 % signifie qu’elle utilise tout le CPU de votre forfait, pas que la machine entière est pleine.
L’IA peut-elle changer mon forfait ?
Non. Elle analyse métriques et journaux puis recommande. Les forfaits, réplicas payants et packs de stockage s’achètent par vous dans le tableau de bord.