Décision : dimensionnement du serveur
Un dimensionnement correct part du profil de charge (OLTP, data warehouse, mixte) et exige de trouver le vrai goulot (CPU, E/S ou RAM). Règle d'or : le jeu de données fréquemment consulté (working set) doit tenir en RAM ; mesurez d'abord, puis montez en charge, et gardez une marge pour les pics de charge. Cet arbre vous aide à identifier la charge et à choisir la ressource et le sens de montée en charge (verticale/horizontale) selon le goulot.
Quel est votre profil de charge ?
Le dimensionnement commence par la charge, car les charges OLTP et analytiques exigent des profils de ressources totalement différents. Quel est le travail prédominant du système : de nombreuses petites transactions rapides (OLTP), du reporting/de l'analyse avec de grands parcours et agrégations (DWH), ou un mélange des deux ? Si vous n'êtes pas sûr, vous devez d'abord mesurer.
- OLTP — nombreuses petites transactions courtes (web/application)
- Analyse / data warehouse (DWH) — grands parcours et agrégations
- Charge mixte, ou je ne suis pas sûr
- Je connais le goulot ; dois-je monter en charge verticalement ou horizontalement ?
Où se situe le goulot : RAM, E/S ou CPU ?
En OLTP, trouvez le vrai goulot au lieu d'ajouter des ressources à l'aveugle. Examinez vos métriques : les données fréquemment consultées ne tiennent-elles pas en RAM avec de fortes lectures disque (RAM/E/S), la latence/les IOPS disque sont-elles insuffisantes (E/S), ou les données sont-elles déjà en mémoire mais le CPU saturé (CPU) ? Augmenter la mauvaise ressource gaspille argent et temps.
- Les données fréquemment consultées ne tiennent pas en RAM ; lectures disque élevées
- Les données sont en mémoire, mais la latence/les IOPS disque sont insuffisantes (forte écriture)
- Les données sont en mémoire et le disque va bien, mais le CPU est constamment saturé
Recommandation : mesurez d'abord, puis dimensionnez
Acheter du matériel sur des suppositions aboutit presque toujours à une mauvaise taille. Le profil de charge et le goulot ressortent des métriques réelles. Le dimensionnement n'est pas une estimation mais une itération guidée par la mesure.
Recommandation : ajoutez de la RAM — le working set doit tenir en mémoire
La règle OLTP la plus critique : les données et index fréquemment consultés (le working set) doivent tenir en mémoire (buffer/cache). Sinon, chaque requête va sur disque, la latence explose et les E/S deviennent le goulot. La RAM est généralement l'investissement le plus rentable.
Recommandation : renforcez la couche E/S (IOPS/latence)
Même lorsque les données sont en mémoire, la vitesse du disque est déterminante sous une charge à forte écriture (commit, WAL/redo/binlog, checkpoint). Le problème ici n'est pas la capacité mais les IOPS et la latence. Une mauvaise classe de disque met le système à genoux malgré un CPU/une RAM rapides.
Recommandation : résolvez le goulot CPU (requêtes d'abord, puis cœurs)
Si le CPU est saturé alors que les données sont en mémoire et que le disque va bien, la cause racine est généralement des requêtes inefficaces (mauvais plans, index manquants, nombreuses petites requêtes) ou une concurrence excessive. Réduire la charge avant d'ajouter des cœurs est généralement moins cher et plus efficace.
Recommandation : analyse/DWH — débit, parallélisme et échelle horizontale
Une charge de data warehouse se compose d'un petit nombre de requêtes lourdes qui parcourent et agrègent de grandes tables. La priorité ici n'est pas une faible latence mais un fort débit de parcours, le parallélisme et généralement une architecture évolutive horizontalement.
Principe général : vertical vs horizontal + marge + mesurer d'abord
La façon de monter en charge compte autant que la ressource choisie. Le vertical (une machine plus grosse) est simple mais a un plafond et un point de défaillance unique ; l'horizontal (plus de machines) passe à l'échelle mais ajoute de la complexité. Dans tous les cas, gardez une marge pour les pics de charge et validez la décision par des mesures.