Le site répond en trois secondes au lieu de 400 ms, le back-office met une éternité à enregistrer une commande, et aucune alerte ne s'est déclenchée. Un VPS lent n'est pas automatiquement un VPS trop petit : la cause se lit le plus souvent dans trois ou quatre compteurs système, avant même d'envisager une migration. Voici un diagnostic en sept étapes, dans l'ordre où il faut les exécuter, avec les commandes à lancer et la lecture de chaque résultat. Objectif : distinguer une machine saturée d'une application mal réglée, et ne payer une montée en gamme que lorsqu'elle est justifiée.
Un VPS lent n'est pas toujours un VPS sous-dimensionné
Trois familles de causes produisent les mêmes symptômes. Les ressources : processeur partagé avec les autres invités de l'hôte, mémoire insuffisante, stockage saturé. Le réseau : latence, perte de paquets, résolution DNS lente. L'application : requêtes sans index, cache absent, extensions mal configurées, tâches planifiées qui se chevauchent. Aucune ne se corrige en ajoutant un vCPU au hasard.
Avant la première commande, qualifiez la lenteur : permanente ou par pics, sur tout le site ou quelques pages, depuis le Maroc ou depuis partout. Ce descriptif élimine déjà la moitié des pistes.
- Lenteur permanente : charge moyenne élevée en continu, souvent une fuite mémoire ou une base mal indexée.
- Pics réguliers : sauvegarde, import, cron, campagne e-mail ou pointe de trafic ; l'heure exacte du pic désigne presque toujours le coupable.
- Pages isolées : une requête lourde, un appel à une API externe, une image non compressée.
- Serveur calme mais site lent : réseau, DNS, TLS ou navigateur ; le problème n'est pas dans la machine.
Étapes 1 à 3 : processeur, mémoire et disque
Étape 1 — Mesurer le vol de CPU (steal)
Sur un VPS KVM, les vCPU sont partagés avec les autres invités de l'hôte physique. top affiche une ligne %Cpu(s) dont la colonne st (steal) indique le temps pendant lequel votre machine a voulu exécuter du code sans obtenir le processeur. Sous 1 à 2 %, le vol est négligeable ; au-delà de 5 % pendant plusieurs minutes, la contention vient de l'hôte, pas de votre application. vmstat 1 10 confirme la lecture seconde par seconde : une colonne sy élevée traduit un excès d'appels système, une colonne wa élevée une attente disque.
Étape 2 — Mémoire, swap et OOM killer
L'affichage de free -m prête à confusion : la colonne free ne dit rien d'utile, car Linux utilise la mémoire disponible pour le cache. Regardez available. Si elle tombe durablement sous 10 % de la RAM totale, le noyau puise dans le swap et les temps de réponse explosent alors que le processeur reste calme. swapon --show et les colonnes si/so de vmstat 1 confirment un échange permanent. Vérifiez ensuite si le noyau a tué des processus : dmesg -T | grep -i -E 'oom|killed process'. Un OOM kill laisse rarement une trace applicative : PHP-FPM ou MySQL disparaît, systemd le relance, et le site rame le temps du redémarrage. ps aux --sort=-rss | head désigne le processus gourmand.
Étape 3 — Disque : espace, inodes et latence
df -h montre l'espace, df -i les inodes. Des inodes épuisés bloquent toute écriture alors que des gigaoctets restent libres : classique des serveurs qui accumulent sessions et fichiers temporaires. La latence se lit avec iostat -x 1 (paquet sysstat) : sur du NVMe, un %util proche de 100 et un await de plusieurs dizaines de millisecondes trahissent une saturation. iotop -oPa identifie le processus qui écrit.
Étapes 4 et 5 : réseau et base de données
Étape 4 — Réseau et résolution
Une bande passante illimitée n'exclut pas un goulot d'étranglement. ss -s compte les sockets, ss -tulpn liste les ports en écoute. Des milliers de connexions en TIME_WAIT signalent une application qui ouvre une connexion par requête au lieu de les mutualiser. mtr -rwzbc 100 votre-domaine.tld situe ensuite la perte de paquets et le saut où la latence explose.
Étape 5 — Base de données
C'est la cause la plus fréquente d'un site lent dont le serveur paraît calme. Sur MySQL ou MariaDB, SHOW FULL PROCESSLIST; révèle les requêtes en cours et leur état, et le journal des requêtes lentes se trie par temps total, jamais par temps moyen. Sur PostgreSQL, interrogez pg_stat_activity : SELECT pid, state, wait_event_type, now() - query_start AS duree, query FROM pg_stat_activity WHERE state <> 'idle' ORDER BY duree DESC;. Une requête sans index sur une grosse table monopolise un cœur pendant des secondes. Un buffer pool InnoDB trop petit provoque en plus des lectures disque permanentes, visibles à l'étape 3.
Étapes 6 et 7 : application et cache
Étape 6 — Application et tâches planifiées
Les journaux contiennent presque toujours la réponse. journalctl -u php8.3-fpm --since '1 hour ago', les logs Nginx et ceux du framework montrent les erreurs récurrentes, les délais d'attente et les redémarrages de workers. Vérifiez les tâches planifiées : deux crons qui se chevauchent (export, sauvegarde, synchronisation) saturent un serveur vingt minutes par heure sans trace lisible dans les métriques. Sur Odoo comme sur WordPress, un module non maintenu peut alourdir chaque chargement de page.
Étape 7 — Cache et configuration
Un site qui recalcule chaque page à chaque visite sature deux vCPU sans que le matériel soit en cause. Vérifiez le cache HTTP, le cache d'objets (Redis ou Memcached), l'OPcache de PHP, la compression et HTTP/2. Un taux de succès OPcache faible signale un cache trop petit. Côté serveur web, le nombre de workers PHP-FPM doit correspondre à la RAM réellement disponible : trop de workers sur 2 Go reproduisent l'OOM de l'étape 2.
Quand le diagnostic confirme le sous-dimensionnement
Si les sept étapes sont propres — pas de vol de CPU anormal, mémoire stable, %util raisonnable, base indexée, cache actif — et que la charge reste haute aux heures de pointe, alors le plan est la limite. Le tableau reprend les cinq configurations VPS NVMe d'Open Vista et leurs tarifs, pour arbitrer entre RAM et cœurs. Prix en dollars par mois et en dirhams hors taxes.
| Offre | vCPU | RAM | NVMe | USD/mois | DH HT/mois |
|---|---|---|---|---|---|
| VPS-1G Démarrage | 1 | 1 Go | 30 Go | 9,99 | 94,48 |
| VPS-2G Business | 1 | 2 Go | 40 Go | 19,99 | 189,06 |
| VPS-3G Performance | 2 | 3 Go | 50 Go | 34,99 | 330,93 |
| VPS-4G Avancé | 2 | 4 Go | 80 Go | 39,99 | 378,22 |
| VPS-5G Ultra | 3 | 5 Go | 100 Go | 49,99 | 472,80 |
Chaque plan inclut une IPv4 dédiée, une bande passante illimitée, l'accès root, un panneau de gestion (console web, redémarrage, réinstallation, DNS), les sauvegardes automatiques, un pare-feu avec protection DDoS, une supervision 24/7, un support six jours sur sept et un SLA de 99,9 % sur l'infrastructure. La mise en service est annoncée en moins de quinze minutes, et le passage à un plan supérieur se fait sans migration douloureuse.
Pour un public marocain, un point compte : le datacenter de production est à New York, avec des latences de l'ordre de moins de 5 ms à New York, 8 ms à Ashburn, 10 à 20 ms à Montréal et environ 14 ms à Toronto. Un datacenter à Rabat est annoncé, mais il n'est pas encore ouvert : ne planifiez pas votre architecture sur cette disponibilité. Pour un site surtout consulté depuis le Maroc, la latence réseau s'ajoute à la latence applicative, et c'est parfois elle, plus que le processeur, qui explique la lenteur ressentie.
FAQ
Comment savoir si la lenteur vient du VPS ou de mon application ?
Comparez la charge processeur au trafic réel. Un CPU à 10 % avec un site lent oriente vers les entrées-sorties, la base ou le code ; une charge moyenne supérieure au nombre de vCPU désigne la machine.
Un steal élevé est-il de ma responsabilité ?
Non : le steal mesure la contention de l'hôte physique, sur laquelle vous n'avez aucune prise. Documentez la valeur avec vmstat 1 10 et transmettez la mesure au support, qui peut déplacer la machine ou vérifier l'hôte.
Passer à un plan supérieur règle-t-il toujours le problème ?
Non. Sans index ni cache, un site lent reste lent avec 5 Go de RAM. La montée en gamme corrige un sous-dimensionnement mesuré, pas une requête non indexée.
Reprendre le diagnostic dans l'ordre, puis décider
Une heure de mesure et quelques commandes suffisent souvent à nommer la cause. Si le verdict est un manque de ressources, les configurations VPS NVMe d'Open Vista se comparent sur la page VPS, avec les tarifs à jour sur la page tarifs et la commande directe dans la boutique en ligne. Si le verdict est applicatif, corrigez l'index, le cache ou le module fautif avant d'engager le moindre dirham supplémentaire.