RAM en storage goed dimensioneren voor je workload
Kort antwoord
Dimensioneer RAM op je working set en piekbelasting, niet op je totale dataset of gemiddeld gebruik, en laat ruimte over: een server die rond de 95% RAM draait, begint te swappen en de prestaties vallen dan scherp terug, niet geleidelijk. Dimensioneer storage op je groeitempo over de looptijd van het contract, niet alleen op wat je nu nodig hebt, en begroot backup- of snapshot-storage apart van live data.
RAM bepalen: working set, niet totale dataset
Een databaseserver heeft niet genoeg RAM nodig om de hele dataset vast te houden, hij heeft genoeg RAM nodig om de working set te cachen: het deel van de data dat daadwerkelijk regelmatig wordt gelezen en geschreven. Een database van 500GB waarbij de meeste queries dezelfde 20GB recente, actieve data raken, presteert heel anders dan een database waarbij queries gelijkmatig over de hele dataset scannen, ook al zijn het op papier allebei "databases van 500GB". RAM dimensioneren op het verkeerde getal, de totale datasetgrootte in plaats van de working set, leidt tot ofwel fors overgedimensioneerde servers, ofwel ondergedimensioneerde servers die in tests prima lijken te werken maar in productie vastlopen.
Dezelfde logica geldt voor het geheugengebruik van applicaties: dimensioneer op piekbelasting, niet op gemiddelde belasting. Een applicatie die het grootste deel van de dag comfortabel in 4GB past, maar tijdens een dagelijkse piek naar 12GB schiet, moet worden gedimensioneerd op die 12GB, niet op het gemiddelde, anders faalt hij precies op het moment dat het ertoe doet.
Laat bij elke workload ruimte over boven het getal dat je berekent. RAM-gebruik is geen resource die geleidelijk achteruitgaat naarmate hij voller raakt: een systeem dat bijna vol zit, begint geheugenpagina's naar disk te swappen, en zodra dat begint, dalen de prestaties niet geleidelijk, ze storten in, omdat disk vele malen trager is dan RAM voor het soort random access dat swappen veroorzaakt.
Storage bepalen: groeitempo, niet huidige omvang
Fouten bij het dimensioneren van storage zijn meestal een timingprobleem, geen capaciteitsprobleem: het is makkelijk om te dimensioneren op wat je op dag één nodig hebt en te vergeten dat data groeit gedurende de looptijd van het contract. Kijk naar het groeitempo, niet alleen naar de huidige omvang, en dimensioneer met die trend in gedachten in plaats van later onder druk te moeten resizen.
Twee gewoontes houden je storage-dimensionering accuraat:
- Scheid OS- en applicatiestorage van datastorage waar mogelijk. Door het besturingssysteem en de applicatiebestanden op een eigen volume te zetten, gescheiden van de data die daadwerkelijk groeit, wordt resizen, migreren of opnieuw installeren veel makkelijker zonder de data zelf te raken.
- Begroot backup- en snapshot-storage bovenop live data, niet erin. Backups en snapshots gebruiken hun eigen capaciteit, naast de data die ze beschermen, en die extra ruimte kan flink oplopen afhankelijk van de retentie. Zie Backups en snapshots: wat is het verschil? voor hoe de twee aanpakken verschillen en wat elk kost in storagetermen.
Typische RAM:storage-verhoudingen per workload
Dit zijn algemene patronen om een dimensioneringskeuze tegen af te zetten, geen vaste regels: de daadwerkelijke verhoudingen hangen sterk af van de specifieke applicatie en het dataprofiel.
| Type workload | Typisch patroon | Waarom |
|---|---|---|
| Algemene webapplicatie | Gematigd RAM, storage gedimensioneerd op groei van content/media | RAM dekt de applicatie en een request-cache; storage groeit doorgaans mee met geüploade content en logs, niet met de applicatie zelf |
| Database | RAM gedimensioneerd op working set, storage gedimensioneerd op volledige dataset plus groei | Queryprestaties hangen af van hoeveel van de actieve data in RAM past; storage moet nog steeds alles bevatten, inclusief data buiten de working set |
| Cache / in-memory store (bijv. Redis) | Zwaar op RAM ten opzichte van storage, storage vooral voor persistence-snapshots | Het hele punt van deze workload is serveren vanuit geheugen; storage is bijzaak, vooral voor duurzaamheid van data |
| File server | Zwaar op storage ten opzichte van RAM | Prestaties hangen meer af van capaciteit en I/O-doorvoer dan van het cachen van grote hoeveelheden bestandsinhoud in RAM |
Dit combineren met CPU- en storage-mediakeuzes
RAM- en storagecapaciteit zijn maar twee onderdelen van het dimensioneringsvraagstuk. Zie Een CPU kiezen voor CI/CD, virtualisatie en Kubernetes-nodes voor de compute-kant, en Storagemedia kiezen: NVMe vs. SSD vs. HDD per workload voor hoe het type storage, niet alleen de omvang, dezelfde workloads uit dit artikel beïnvloedt.