Base et cache sur le même serveur dédié : 128GB ou 256GB ?

Additionner d’abord les trois usages

Les deux paliers sont un AMD EPYC 7543P, 32 cœurs / 64 threads, 2,8–3,7 GHz. 128GB coûte $449 par mois, 256GB $599. La mémoire est de la DDR4-3200 ECC RDIMM. Elle se choisit à la commande. On n’ajoute pas de barrette ensuite. Décidez avant de payer si la base principale et le cache partagent cette machine. Il n’y a pas de troisième palier ensuite.

Sur un hôte, la RAM se partage en au moins trois parts. La première : le système, le cache de pages et les connexions, y compris les processus d’admin ouverts en SSH. La deuxième : les données chaudes que la base doit garder résidentes. Sous MySQL, c’est surtout le buffer pool InnoDB. Sous PostgreSQL, shared_buffers, plus le cache de pages que le système conserve pour elle. La troisième : Redis, ou un autre cache, sous maxmemory. Si l’application tourne aussi ici, retirez sa mémoire résidente.

Additionnez les trois, gardez une marge, puis comparez à 128 et 256. La taille du répertoire sur disque n’est pas le besoin en RAM. Un répertoire de 400GB peut n’avoir que quelques dizaines de gigaoctets vraiment chauds. À l’inverse, 128GB manque en premier si le cache doit tenir la majeure partie d’un jeu d’objets, même avec un petit disque.

Ce texte vise MySQL, PostgreSQL et Redis sous Linux. Avec Windows Server, calculez à part la mémoire de SQL Server. Ne recopiez pas les ratios de pool ci-dessous sur Windows. Sous Linux, on modifie la configuration en SSH. La connexion est la même sur les deux paliers.

Quand 128GB suffit

128GB suffit quand plusieurs conditions sont vraies ensemble. Le pool couvre le jeu chaud et le taux de succès est déjà stable. Redis ne garde que des sessions, des clés chaudes ou un cache d’objets borné, de l’ordre de 8GB à 24GB, et les évictions restent acceptables. Le système, les connexions et l’application sur le même hôte laissent encore environ 16GB à 24GB. Sur six mois, le jeu chaud ne double pas, et aucun second service gourmand en mémoire ne monte sur cette machine.

C’est une feuille de calcul, pas une promesse de capacité. Sur 128GB, laissez d’abord environ 20GB au système et aux connexions. Si Redis est prévu à 16GB, il reste environ 90GB pour la base. Un pool MySQL peut démarrer entre 64GB et 80GB, avec de la place pour le cache de pages et les tris sur disque. Si Redis ne fait que quelques gigaoctets, le pool peut se rapprocher de 80GB. S’il demande déjà 24GB, ne poussez pas le pool au-delà.

PostgreSQL place souvent shared_buffers plus bas qu’un pool MySQL, autour du quart de la RAM physique. Le reste va au cache de pages du système. Le même jeu chaud peut donc rester sur 128GB, tant que les tris concurrents et les agrégats par hachage ne multiplient pas work_mem en un pic large. Une requête peut contenir plusieurs nœuds de tri, puis on multiplie par le nombre de requêtes simultanées. 64MB fois quelques dizaines d’opérations tiennent souvent. Des centaines de mégaoctets de work_mem fois plus de cent opérations simultanées remplissent la marge de 128GB.

Quand choisir 256GB

Un seul de ces cas oriente vers 256GB. Vous voulez un pool autour de 80GB et, en même temps, un Redis de plusieurs dizaines de gigaoctets. Sur la machine actuelle, la RSS de la base plus celle du cache est déjà proche ou au-dessus de 90GB. PostgreSQL trie beaucoup en parallèle, et work_mem fois cette concurrence remplit la marge. Outre la base et Redis, un moteur de recherche ou un autre service à gros tas doit vivre ici. L’application n’est pas séparée et demande elle-même plus de 10GB.

Sur 256GB, laissez d’abord 24GB à 32GB au système et aux connexions. Si Redis a besoin de 32GB à 48GB, le pool peut encore se placer entre 120GB et 160GB. C’est un départ. Après la mise en service, ramenez les plafonds avec le taux de succès, les fichiers temporaires et les évictions Redis. Ne donnez pas environ 90 pour cent de la RAM au pool tout en faisant tourner un gros Redis. Quand les deux grossissent, l’hôte commence à swapper. C’est plus difficile à lire qu’un défaut de cache qui tombe sur le disque.

L’écart est de $150 par mois. Un trimestre : $1,347 contre $1,797. Six mois : $2,694 contre $3,594. Un an : $5,388 contre $7,188. La période ne fait que multiplier le mensuel. Choisir 256GB n’ajoute pas de remise. Déplacer une base plus tard faute de RAM coûte en général plus que ces $150. Si l’usage actuel est déjà près de la ligne des 128GB, commandez 256GB. Si le jeu chaud est concentré, le taux de succès élevé et le cache encore entre 8 et 24GB, restez en 128GB.

Coller le palier à vos chiffres

Reportez les mesures de production ou de l’hôte précédent. Une ligne dans la colonne de droite veut dire : prévoir 256GB. Si les cinq lignes sont à gauche, 128GB couvre cette commande.

Un taux de succès élevé, des évictions acceptables et un jeu chaud concentré restent en 128GB. Si le disque remplace la RAM, ou si Redis évince des clés encore utiles, choisissez 256GB. Si les chiffres sont flous, prenez la mémoire résidente de l’hôte précédent, multipliez par 1,3, puis comparez à 128 et 256. Sous environ 100GB, 128GB tient ce plan. Au-delà, commandez 256GB.

Plafonner la base et le cache après l’installation

Une fois le palier choisi, écrivez des plafonds pour la base et le cache. Sans plafond, InnoDB et Redis suivent chacun leur défaut et se disputent la même RAM.

1. 1
   Noter trois chiffres

   RSS de la base, used_memory de Redis, et la mémoire encore libre pour le système. MySQL : taux de succès du pool. Redis : used_memory et evicted_keys. PostgreSQL : succès du cache et fichiers temporaires.

2. 2
   Plafonner le pool et maxmemory à part

   Sur un hôte partagé, gardez le pool InnoDB autour de 60 à 70 pour cent de la RAM, sauf si Redis est petit. Réglez maxmemory et une politique d’éviction. Les deux plafonds doivent exister ensemble.

3. 3
   Laisser une marge au cache de pages

   La somme du pool et du plafond Redis reste sous la RAM moins le système et les connexions. Sur 128GB, essayez une somme proche de 100GB. Sur 256GB, proche de 210GB.

4. 4
   Revoir après une semaine

   Si le swap continue de monter, les plafonds sont trop hauts. Réduisez d’abord le pool ou Redis, puis regardez le taux de succès. Une lecture disque ne prouve pas à elle seule que le palier de RAM était faux.

Un disque de plus n’ajoute pas de RAM

Les disques par défaut sont 2 × 1TB NVMe, sans RAID matériel. Chaque disque est en attache directe, et la capacité utilisable est de 2TB. Quand le jeu chaud ne tient pas en RAM, les lectures tombent sur ces disques. Le NVMe absorbe les défauts. La latence reste plus haute qu’un succès en mémoire. Un disque 2TB supplémentaire coûte $79 par mois, deux au plus, toujours en attache directe. Cela ajoute de la capacité, pas des barrettes. Où placer fichiers de données et sauvegardes est une question de disque. « Encore un disque » ne remplace pas le palier 256GB.

La bande passante ne remplit pas un buffer pool. Le port par défaut est 250M, trafic non compté. 1G ajoute $250 par mois, 2G ajoute $750. Cela change le débit de sortie. Le trafic entre la base et un Redis local reste en loopback et ne consomme pas ce port. RAM et bande passante sont deux lignes distinctes. Si les sauvegardes doivent quitter la machine, jugez 250M sur ce transfert. C’est un autre choix.

Comment cela tombe sur les deux serveurs

Une fois le jeu chaud, le cache et la réserve additionnés, le formulaire propose ces deux machines. 128GB à $449 par mois, 256GB à $599. Le CPU est un EPYC 7543P, 32 cœurs / 64 threads, 2,8–3,7 GHz. La RAM est de la DDR4-3200 ECC RDIMM, choisie à la commande, sans barrette ensuite. Les serveurs sont à Tokyo, au Japon. Sous Linux, on entre en SSH pour régler le pool et maxmemory. Il n’y a pas de frais d’installation. Le montant dû est le mensuel multiplié par le nombre de mois. Mois, trimestre, semestre et année n’ajoutent pas de remise. Les options de cet hôte, disques et bande passante compris, se prépayent sur la même période.

Si la somme dépasse déjà ce que 256GB peut porter avec de la marge — grand pool, grand cache, tas de recherche et application ensemble — ne forcez pas le tout sur un seul 256GB. Séparez le cache ou la recherche sur une seconde machine. C’est plus clair que d’écrire chaque plafond au maximum. Ce texte ne choisit qu’entre les deux paliers que l’on peut commander.