Une base de données lente ne renvoie pas toujours une erreur : elle se manifeste par des pages qui mettent deux secondes à s'afficher et des utilisateurs qui rafraîchissent. Sur un VPS, le goulot se trouve rarement là où on le cherche. Avant d'ajouter de la RAM, il faut comprendre ce que le disque, la mémoire et quelques paramètres font réellement à vos requêtes : voici dans quel ordre mesurer, ce qui compte, et quand un plan supérieur devient la bonne réponse.
Pourquoi la base décide de la vitesse perçue
Dans une application de gestion, le temps de réponse suit toujours la même chaîne : une requête arrive, l'application interroge la base, le moteur cherche les pages nécessaires, puis renvoie un résultat. Le processeur travaille en microsecondes, le disque en millisecondes : cet écart, répété des milliers de fois par heure, sépare une interface fluide d'une interface pénible.
La conséquence est simple : le matériel fixe le plafond, la configuration décide de la distance qui vous en sépare.
NVMe ou SATA : ce qui change pour un moteur de base
Ce que le NVMe apporte réellement
Un moteur de base ne lit pas de gros fichiers d'un bloc : il lit des pages de 8 ou 16 Ko dispersées sur le volume, plusieurs en parallèle. C'est le profil d'accès aléatoire, celui où le NVMe distance le plus nettement un disque mécanique et garde son avantage sur un SSD SATA.
Ce que le NVMe ne corrige pas
Un disque rapide n'annule pas une requête mal écrite : un balayage complet de table, un index manquant ou un tri non indexé restent lents. Un volume NVMe rempli à 95 % perd aussi l'essentiel de son avance, le contrôleur devant gérer l'usure et réordonner les écritures.
- Latence : ce que votre application ressent, requête par requête.
- Débit : ce qui compte pour les sauvegardes et les restaurations.
- Files d'attente et espace libre : les deux signaux d'un disque qui décroche.
Working set contre RAM : le vrai point de bascule
Le working set — le jeu de travail — désigne les pages que la base consulte réellement dans une journée : index chauds, tables les plus lues, quelques lignes très sollicitées. Tant qu'il tient dans la mémoire disponible, le moteur répond sans toucher au disque ; dès qu'il déborde, chaque requête réclame une lecture physique.
Mesurez donc ce working set avant de raisonner en gigaoctets. Un catalogue de 20 Go dont 2 Go sont lus chaque jour n'a pas besoin de 20 Go de mémoire ; une table de 800 Mo lue à chaque connexion sature une machine de 1 Go. Regardez ensuite le taux de lectures servies par le cache : sous 95 %, la mémoire manque avant le processeur.
Les six réglages qui comptent vraiment
Six paramètres expliquent la majorité des écarts entre une base lente et une base correcte. Ils se règlent dans cet ordre, un seul à la fois.
La mémoire allouée au moteur
shared_buffers pour PostgreSQL, innodb_buffer_pool_size pour MariaDB et MySQL : c'est le cache interne du moteur, celui qui garde les pages chaudes. Un quart de la RAM est un point de départ raisonnable pour PostgreSQL ; sur un serveur dédié, le pool InnoDB peut monter plus haut, à condition de laisser au système son cache de fichiers.
Les tris et les connexions
work_mem se paie par opération de tri, pas par requête : une valeur généreuse multipliée par cinquante connexions simultanées sature la mémoire. effective_cache_size n'alloue rien, il indique au planificateur ce que le système peut garder en cache. Et max_connections se règle avec un pool côté application : dix connexions actives valent mieux que deux cents qui attendent.
Les écritures et la durabilité
Les paramètres de durabilité — synchronisation des journaux, taille des journaux de transactions, fréquence des points de contrôle — arbitrent entre sécurité et vitesse. Les assouplir accélère les insertions massives, au prix d'une perte des dernières transactions en cas de coupure brutale : un choix d'exploitation à documenter, pas un réglage à copier.
Le cache devant le moteur
La couche la plus rentable n'est souvent pas dans la base : un cache applicatif pour les résultats coûteux, un cache de pages pour les visiteurs anonymes et un CDN pour le statique suppriment des milliers d'appels avant qu'ils n'atteignent le serveur.
Mesurer avant de régler
Régler sans référence revient à piloter sans compteur :
- Fixer une référence : latence au 95e centile, requêtes par seconde, temps de la page la plus lente, à heure creuse comme à heure pleine.
- Classer les requêtes par temps total avec pg_stat_statements ou performance_schema : non pas la plus lente, mais celle qui consomme le plus à elle seule.
- Regarder le disque : temps d'attente moyen, taux d'utilisation, longueur des files. Un disque proche de la saturation explique plus de lenteurs qu'un processeur à 60 %.
- Vérifier la mémoire : lectures servies par le cache, recours au swap, mémoire réellement disponible.
- Changer un seul paramètre, puis remesurer dans les mêmes conditions : deux réglages modifiés ensemble interdisent de savoir lequel a aidé.
Un piège fréquent : comparer une mesure prise pendant une réindexation avec un lundi matin calme.
Quel plan VPS pour quelle charge
Le bon dimensionnement se déduit du working set et des connexions simultanées, pas du volume total. Le tableau résume les quatre plans intermédiaires ; la liste complète est publiée sur la page tarifs d'Open Vista.
| Plan | vCPU / RAM | NVMe | Profil de base visé | USD / mois | DH HT / mois |
|---|---|---|---|---|---|
| VPS-2G Business | 1 vCPU / 2 Go | 40 Go | Working set de 1 à 1,5 Go, quelques dizaines de connexions | 19,99 $ | 189,06 |
| VPS-3G Performance | 2 vCPU / 3 Go | 50 Go | Base et application sur la même machine, cache chaud modéré | 34,99 $ | 330,93 |
| VPS-4G Avancé | 2 vCPU / 4 Go | 80 Go | Base dédiée de 2 à 3 Go de working set, écritures régulières | 39,99 $ | 378,22 |
| VPS-5G Ultra | 3 vCPU / 5 Go | 100 Go | Charges mixtes lecture/écriture, plusieurs bases ou une grosse base | 49,99 $ | 472,80 |
Chaque plan inclut une adresse IPv4 dédiée, la bande passante illimitée, l'accès root, un panneau de gestion, les sauvegardes automatiques, un pare-feu avec protection DDoS, la supervision 24/7, un support six jours sur sept et un SLA de 99,9 % sur l'infrastructure. Les serveurs sont hébergés à New York ; un datacenter à Rabat est annoncé, mais il n'est pas encore ouvert. Livraison en moins de quinze minutes, montée en gamme sans migration douloureuse.
FAQ
Faut-il plus de RAM ou plus de vCPU pour une base lente ?
Regardez d'abord le taux de lectures servies par le cache et l'utilisation disque : un cache qui stagne et des files qui s'allongent désignent la mémoire, pas le processeur. Un processeur saturé avec un cache confortable désigne le calcul : voyez les index et les requêtes avant le matériel.
Peut-on héberger la base et l'application sur le même VPS ?
Oui, et c'est le cas le plus fréquent jusqu'à quelques dizaines de milliers de visites mensuelles. Réservez alors la mémoire du moteur avec prudence, plafonnez les connexions et surveillez les pics : un import peut consommer la RAM dont la base a besoin.
Le NVMe suffit-il à rendre une base rapide ?
Non. Le NVMe réduit le coût des lectures aléatoires, ce qui aide quand le working set dépasse la RAM, mais il ne compense ni un index absent ni un tri mal placé. Sur une base dont le working set tient en mémoire, le gain reste modeste : corrigez d'abord les requêtes.
Comment savoir si le disque est le goulot ?
Comparez le temps d'attente moyen sur les entrées-sorties avec le temps de réponse applicatif, et observez la longueur des files sur une période chargée. Si les deux montent ensemble, le disque est en cause ; sinon, cherchez du côté des verrous ou des connexions épuisées.
Conclusion : mesurer, régler, puis dimensionner
Une base rapide sur un VPS est rarement une question de budget : c'est une question d'ordre des opérations. Mesurez la latence réelle, classez les requêtes par coût total, vérifiez que le working set tient dans la mémoire, puis réglez un paramètre à la fois. Ce travail apporte souvent plus que le changement de machine, et il rend celui-ci utile quand il devient nécessaire.
La prochaine étape est concrète : ouvrez la page VPS NVMe d'Open Vista, comparez les cinq plans à la lumière de votre working set mesuré, et choisissez celui qui correspond à votre charge actuelle. Si vous hésitez entre deux niveaux, partez du plus petit : l'upgrade se fait sans migration douloureuse le mois suivant.