# Faire grandir un service

> Plus de mémoire, plus de processeur, sans coupure.

## Savoir qu'il faut grandir

Trois signaux, par ordre de fiabilité :

1. **Les jauges de la vue d'ensemble** collées en haut pendant des jours — pas une pointe,
   une habitude.
2. **Les journaux** qui parlent de mémoire : `OutOfMemoryError`, `Killed`, un redémarrage
   sans raison apparente.
3. **Le ressenti** : un serveur de jeu qui saccade quand les joueurs arrivent.

<Note>
Un service tué pour dépassement mémoire redémarre tout seul et ne laisse presque rien
dans ses journaux. Une pastille qui repasse au vert sans que tu aies rien fait, plusieurs
fois par jour, c'est ce symptôme-là.
</Note>

## Grandir

<Steps>
  <Step title="Réglages, bloc Taille">
    Les curseurs vont des bornes basses aux bornes hautes du nœud qui héberge.
  </Step>
  <Step title="Regarde le prix avant de valider">
    L'ancien tarif est barré, le nouveau à côté. Le tarif court **dès que tu appliques**.
  </Step>
  <Step title="Applique">
    Processeur et mémoire changent **sans coupure** : le service continue de tourner.
  </Step>
</Steps>

<Warning>
Le disque ne se réduit jamais : tes fichiers y sont. Monte-le avec parcimonie — c'est le
seul des trois curseurs qui ne revient pas en arrière.
</Warning>

## Ce qui a besoin d'un redémarrage quand même

La limite système bouge tout de suite. Mais un programme qui a **calculé sa mémoire à son
démarrage** garde son ancien calcul : une JVM avec `-Xmx`, un pool de connexions
dimensionné au boot. Pour ceux-là, redémarre après avoir appliqué.

## Redescendre

Le même écran. Processeur et mémoire redescendent librement, et le tarif suit dans la
seconde. C'est la manière la plus simple de tenir un budget : monter pour un événement,
redescendre après.