Skip to main content
Square Cloud met en œuvre des limites de ressources basées sur les conteneurs afin de garantir l’isolation, la stabilité et une répartition équitable de l’infrastructure entre les applications.

​
Exigences minimales de ressources

Chaque projet hébergé sur la plateforme Square Cloud a des exigences minimales de ressources spécifiques pour garantir des performances optimales :
  • Bots : Minimum de 256 Mo de RAM requis.
  • Sites web : Minimum de 512 Mo de RAM requis.
  • Bases de données de cache : Minimum de 512 Mo de RAM requis.
  • Bases de données générales : Minimum de 1 Go de RAM requis.

​
Pourquoi des minimums de RAM existent-ils ?

Les conteneurs ont une surcharge opérationnelle obligatoire : runtime du langage, bibliothèques de l’OS et tampons réseau. En dessous de 256 Mo, l’OOM Killer du noyau a tendance à interrompre les processus au démarrage ou pendant le ramasse-miettes, rendant l’application inviable. Implications techniques :
  • Chaque conteneur consomme 1 IPv4 dynamique et des IOPS de stockage NVMe
  • Les allocations minimales évitent la fragmentation des ressources (effet « noisy neighbor »)
  • Formule des snapshots quotidiens : (Total RAM / 256) * 2 (approximatif ; le quota exact par plan peut être inférieur sur les niveaux supérieurs)
Données d’impact : Après la mise en place de la limite minimale de 256 Mo, la stabilité des applications a considérablement augmenté, réduisant le taux de crash dû à l’OOM (Out of Memory) de 97,7 %.

​
Allocation CPU

Réponse courte : le CPU est alloué en fonction de la RAM configurée. Augmenter la RAM accorde généralement davantage de vCPU.

​
Règles

​
Plans à vCPU unique

Les applications sur les plans à 1 vCPU reçoivent la pleine capacité sans throttling.

​
Plans multicœurs (≥2 vCPU)

  • Plancher de performance : les applications avec ≥512 Mo de RAM reçoivent au moins 2 vCPU.
  • Mise à l’échelle proportionnelle :
    • Hobby (≤2 vCPU) : +1 vCPU par 512 Mo de RAM
    • Standard / Pro / Enterprise : +1 vCPU par 1 Go (1024 Mo) de RAM

​
Exemples

​
Throttling et limites de sécurité

Le système applique la limite de vCPU du plan et procède à un nivellement pour maintenir une répartition équitable. Une élasticité à court terme peut accorder des vCPU supplémentaires lors des pics, mais elle n’est pas garantie. Utilisations CPU interdites :
  • Minage de cryptomonnaies
  • Charges de travail ML intensives et non restreintes sans autorisation
  • Abus délibéré des ressources
Ces utilisations enfreignent la politique contre les abus, le minage de cryptomonnaies et le spam. Par ailleurs, une application qui occupe en permanence tous ses vCPU est arrêtée avec LACK_OF_CPU.

​
Limites réseau

Chaque application dispose d’une bande passante dédiée, identique en envoi et en réception, qui évolue proportionnellement à la RAM allouée : +50 Mbps par 256 Mo. Elle est réservée à votre conteneur, jamais partagée avec des voisins, et le trafic n’est ni mesuré ni facturé. Quelques exemples : Pour des charges soutenues à fort trafic, le support peut mettre en place un cluster dédié. Turbo de démarrage. Chaque démarrage bénéficie d’une accélération bien au-delà de la bande passante du plan : installer les dépendances, télécharger des modèles ou reconstruire des caches est rapide, quelle que soit votre allocation. Les bases de données disposent de leur propre bande passante dédiée, dans les deux sens, dimensionnée selon leur RAM.

​
Limites de stockage

Tous les projets reçoivent 10 Go de stockage NVMe par défaut. Caractéristiques :
  • NVMe de qualité entreprise
  • Persistant à travers les déploiements et les redémarrages
  • IOPS et débit élevés

​
Statuts de dépassement de limite

Lorsqu’une application dépasse ses ressources, Square Cloud l’arrête, écrit dans ses logs une ligne [SQUARE-SHIELD] indiquant la raison et vous envoie un e-mail. Ce tableau sert de référence aux autres pages ; les corrections se trouvent en dessous. Le centre d’aide explique les e-mails d’alerte dans alertes d’indisponibilité : RAM, CPU et blocages de requêtes.

​
LACK_OF_RAM

L’application a atteint la RAM qui lui est allouée, le processus a donc été arrêté pour protéger l’hôte. Comment corriger :
  1. Identifiez les fuites de mémoire avec un profiler (Node.js : --inspect, Python : memory_profiler). Voir fuites de mémoire en Node.js.
  2. Réduisez les caches en mémoire ou déplacez-les vers Redis.
  3. Augmentez la RAM de l’application dans le tableau de bord, ou relevez MEMORY dans le fichier de configuration.

​
LACK_OF_CPU

L’application a utilisé tous ses vCPU pendant une période prolongée, le processus a donc été arrêté. Comment corriger :
  1. Profilez les points chauds CPU (Node.js : 0x, Python : cProfile). Voir CPU à 100 % : conseils d’optimisation.
  2. Optimisez les boucles chaudes, les requêtes en base de données et les opérations liées aux I/O.
  3. Augmentez la RAM pour obtenir davantage de vCPU (voir allocation CPU).
  4. Déplacez le travail lourd vers des workers asynchrones ou des jobs par lots.
Compromis : augmenter la RAM pour gagner du CPU augmente les coûts. Évaluez si optimiser le code revient moins cher que monter en capacité.

​
CONTAINER_TEMPORARILY_SUSPENDED

Les logs ont affiché [SQUARE-SHIELD] ABUSE_REQUESTS : l’application a envoyé des requêtes à Discord ou à des sites squareweb.app à un rythme abusif pendant une période prolongée. La cause est presque toujours une boucle infinie, une nouvelle tentative sans délai ou un cache manquant, pas un vrai succès. L’application a été arrêtée et, tant que le blocage dure, son démarrage échoue avec CONTAINER_TEMPORARILY_SUSPENDED. Comment corriger :
  1. Lisez l’e-mail et les derniers logs pour trouver le code qui envoie les requêtes.
  2. Mettez en cache ce que vous récupérez, ajoutez un délai entre les tentatives et respectez les en-têtes de limite de débit de l’API que vous appelez. Voir limites de débit de l’API Discord.
  3. Patientez un moment, puis redémarrez l’application.