Choisissez la mémoire pour le système d'exploitation, les services persistants et une concurrence réaliste avec une marge. Choisissez le CPU après avoir mesuré quelles tâches sont occupées, si elles s'exécutent en parallèle et quels délais les utilisateurs subissent réellement.
Décrivez séparément le travail normal et le travail de pointe
Le nombre de visiteurs seul est une faible donnée de dimensionnement. Une requête peut servir un fichier mis en cache tandis qu'une autre génère un rapport ou interroge de nombreuses tables. Listez les workers web, la base de données, le cache, les consommateurs de files d'attente et les tâches de maintenance qui partageront le VPS. Décrivez la concurrence normale et l'opération la plus chargée attendue. Incluez les exports planifiés, les mises à jour de paquets et les déploiements plutôt que de les traiter comme une activité d'arrière-plan invisible.
Pour un projet existant, collectez une période représentative incluant une fenêtre de pointe. Consignez les temps de réponse et les erreurs en parallèle de l'utilisation des ressources. Pour un nouveau projet, créez un petit test avec des formes de requêtes et des tailles de données réalistes. Votre estimation initiale sera imparfaite ; l'objectif utile est un point de départ documenté que vous pourrez comparer au comportement mesuré après la livraison.
Établissez le budget mémoire avant d'ajouter des processus
La demande de mémoire provient du système, des services applicatifs persistants, de l'usage par worker et des opérations temporaires. Multiplier l'empreinte d'un worker par une concurrence planifiée est un outil de planification approximatif, pas une garantie, car la mémoire partagée et les caches compliquent le total. Observez les processus réels sous charge. Laissez suffisamment de marge pour qu'une tâche de maintenance ne force pas l'application à se disputer chaque page restante.
Les paramètres de base de données peuvent multiplier l'usage de mémoire de façon inattendue. PostgreSQL documente que work_mem s'applique aux opérations de requête, et que plusieurs opérations ou sessions peuvent s'exécuter simultanément. Un paramètre qui semble modeste isolément peut donc avoir un effet plus important sur le système. Consultez les recommandations propres à votre base de données, testez une concurrence réaliste et évitez d'attribuer chaque gigaoctet annoncé à un seul cache.
Distinguez l'utilisation de CPU du parallélisme utile
Un nombre de processeurs indique combien de ressources d'exécution sont présentées à l'invité, pas avec quelle efficacité votre logiciel peut les utiliser. Un seul thread occupé peut limiter une application tandis que d'autres cœurs restent inactifs. Ajouter des workers peut aider pour des requêtes indépendantes, mais peut aussi accroître la contention sur la base de données et la demande de mémoire. Vérifiez le modèle de concurrence de l'application avant de supposer que deux fois le nombre de cœurs produit deux fois le débit.
KVM fournit aux machines virtuelles leur propre matériel virtuel. Cela ne transforme pas chaque étiquette de vCPU en un benchmark identique d'un hôte et d'une génération de processeur à l'autre. Comparez le modèle CPU indiqué et les conditions d'allocation lorsqu'elles sont disponibles, puis évaluez le service avec votre propre charge de travail. Évitez de tirer une conclusion d'achat d'un score synthétique court qui ne ressemble pas à l'application.
Recherchez la pression et l'attente, pas seulement les moyennes
Un système peut sembler lent sans maintenir un pourcentage CPU moyen élevé. Les processus peuvent attendre le stockage, la récupération de mémoire ou un autre service. L'information de pression d'attente (Pressure Stall Information) du noyau Linux expose des informations d'attente pour le CPU, la mémoire et les E/S sur les systèmes pris en charge. Ces signaux peuvent aider à identifier une contention de ressources aux côtés des métriques d'utilisation habituelles et des temps de réponse applicatifs.
Lisez les métriques ensemble. Une pression mémoire soutenue, du swapping, des allocations échouées et des requêtes lentes orientent vers une intervention différente d'un seul worker de calcul occupé. Les attentes de stockage peuvent justifier des modifications de requêtes ou un profil de disque différent. Un délai d'API externe ne sera pas corrigé en ajoutant de la RAM locale. Expliquez la contrainte observée avant de choisir la ressource à augmenter.
| Comportement observé | Question à examiner | Étape suivante possible |
|---|---|---|
| Un thread occupé, des cœurs disponibles inactifs | Ce travail peut-il s'exécuter en parallèle ? | Améliorer la tâche ou modifier la conception des workers |
| Pression mémoire pendant un rapport | Combien d'opérations se chevauchent ? | Limiter la concurrence ou ajouter une marge testée |
| Requêtes lentes avec attentes d'E/S | Quelles lectures ou écritures sont retardées ? | Inspecter les requêtes et le comportement du stockage |
| CPU et mémoire faibles, requêtes lentes | Une dépendance retarde-t-elle les réponses ? | Mesurer les appels en aval |
Un exemple de planification avec des hypothèses explicites
Imaginez une petite application avec deux workers web, une base de données et un consommateur de file d'attente. L'équipe mesure ces services pendant des requêtes ordinaires et une tâche de génération de rapports. Elle découvre que permettre quatre rapports à la fois augmente fortement la demande de mémoire tout en retardant le trafic normal. Au lieu d'acheter immédiatement le plus grand plan, elle limite la concurrence des rapports et mesure à nouveau le résultat.
Si la charge de travail ajustée nécessite encore plus de mémoire, l'augmentation répond désormais à un besoin observé. Si la file d'attente reste limitée par le CPU et que des tâches indépendantes peuvent s'exécuter simultanément, davantage de ressources d'exécution peuvent être appropriées. Ce sont des exemples de décisions, pas des chiffres de performance pour les plans SwissOctet. Conservez vos propres mesures et contraintes avec la configuration choisie.
Laissez un chemin clair pour la prochaine mesure
Définissez les signes qui déclencheront une révision : détérioration du temps de réponse, pression mémoire répétée, files d'attente croissantes ou charge de travail modifiée. Gardez la surveillance suffisamment légère pour qu'elle ne devienne pas un nouveau goulot d'étranglement. Réévaluez après l'ajout d'une fonctionnalité ou d'un jeu de données majeur, et évitez les augmentations répétées lorsque le vrai problème est un processus sans limite ou une requête lente.
Les familles VPS de SwissOctet exposent les spécifications de CPU et de mémoire ainsi que certaines options de ressources. Lisez la configuration finale après ajout d'extras, y compris la période de facturation et le total. Confirmez les modalités de mise à niveau avec l'opérateur en production avant de vous y fier. Une taille VPS utile est celle qui exécute la charge de travail mesurée avec une marge raisonnable et une étape suivante compréhensible.
Votre liste de contrôle pratique.
- Inventorier les services et les tâches de maintenance.
- Mesurer la concurrence en période normale et en période de pointe.
- Budgéter la mémoire persistante et temporaire.
- Vérifier si le travail CPU peut s'exécuter en parallèle.
- Comparer la pression, l'utilisation et les temps de réponse applicatifs.
- Définir quand réviser la configuration.
Les détails qui comptent.
Dois-je dimensionner un VPS selon les visiteurs mensuels ?+
Utilisez le nombre de visiteurs comme contexte, puis mesurez la complexité des requêtes, la concurrence, la taille des données et le travail en arrière-plan. Des nombres de visiteurs égaux peuvent créer des charges différentes.
Plus de RAM rend-il toujours un service plus rapide ?+
Non. Cela aide lorsque la mémoire est une contrainte ou permet une mise en cache utile, mais ne résout pas tous les délais liés au CPU, au stockage ou à une dépendance externe.
Deux fois le nombre de vCPU double-t-il les performances ?+
Non. Le parallélisme, les caractéristiques du processeur, la contention et la conception de l'application déterminent la quantité de capacité supplémentaire utile.
Allez à la source.
Ces références soutiennent les concepts techniques de ce guide. Suivez la documentation actuelle avant de modifier un système de production.
- Noyau Linux : Pressure Stall Information docs.kernel.org
- PostgreSQL : Consommation de ressources www.postgresql.org
- Projet KVM : Kernel Virtual Machine www.linux-kvm.org
Conseils éditoriaux par SwissOctet. Les exemples sont illustratifs. Les spécifications de service, les options disponibles et les conditions contractuelles doivent être vérifiées séparément.