Overselling is een veelvoorkomende praktijk onder VPS-aanbieders die je serverprestaties ongemerkt kan ondermijnen. Zo werkt het, en hier let je op bij het kiezen van een host.
Publicatiedatum: 5/22/2026
Voelt je VPS traag aan terwijl de specificaties op papier prima zijn? Dan kan overselling de oorzaak zijn. Het is een van de meest voorkomende praktijken in de hostingindustrie, en de meeste aanbieders maken er geen reclame voor. Door te begrijpen hoe het werkt, neem je een betere aankoopbeslissing en betaal je niet voor capaciteit die je in de praktijk niet betrouwbaar krijgt.
Van overselling is sprake wanneer een hostingaanbieder meer capaciteit uitgeeft dan er fysiek in de hardware zit. De logica is geleend van de luchtvaart: niet elke passagier komt opdagen, dus verkoop je meer stoelen dan het vliegtuig telt. Toegepast op hosting: niet elke klant gebruikt zijn volledige toewijzing tegelijk, dus passen er in theorie meer VPS-instanties op één server dan de specificaties eigenlijk toelaten.
Bij traditionele shared hosting wordt dit vrijwel algemeen geaccepteerd. Bij VPS-hosting ligt dat anders. Klanten betalen voor toegewezen, geïsoleerde capaciteit, en overselling ondermijnt die verwachting volledig.
RAM is het makkelijkst om te overboeken, en dat gebeurt extreem vaak. Een aanbieder kan een fysieke host met 256 GB RAM hebben, terwijl de VPS-instanties samen 512 GB of meer toegewezen krijgen. Bij laag gebruik gaat dat prima. Zodra meerdere klanten tegelijk hun toegewezen RAM aanspreken, raakt de host door zijn fysieke geheugen heen, gaat hij swappen naar schijf of begint hij in het ergste geval processen te stoppen via de OOM-killer (out-of-memory).
Voor jou ziet dat er zo uit: je applicatie crasht plotseling, services starten onverwacht opnieuw, of alles komt nagenoeg tot stilstand. Dat kan lijken op bugs in je eigen software, terwijl de echte oorzaak ligt bij een host die zonder fysiek geheugen zit.
Sommige aanbieders gebruiken memory ballooning in hun hypervisors om ongebruikt RAM dynamisch terug te vorderen van inactieve VM's. Dat is iets eerlijker dan pure overselling, maar het betekent nog steeds dat je toegewezen geheugen niet gegarandeerd is.
CPU ligt iets genuanceerder. Met moderne hypervisors kunnen aanbieders meer vCPU's aan virtuele machines toewijzen dan de fysieke host aan logische cores heeft. Een server met 64 fysieke threads kan 200 vCPU's verdeeld over zijn VM's hebben. Zolang de meeste VM's inactief zijn, kan de scheduler dat aan.
Het probleem komt aan het licht onder belasting. Wanneer meerdere klanten tegelijk CPU-intensieve taken draaien, concurreren ze allemaal om dezelfde fysieke threads. De hypervisor moet agressief gaan time-slicen en jouw taken komen in de wachtrij terecht. Dat zie je terug als CPU steal time: het percentage van de tijd dat je vCPU staat te wachten op fysieke CPU-toegang die de hypervisor niet vrijgeeft.
Hoge steal time is een betrouwbaar signaal dat je host CPU overboekt. Tools als top, vmstat en sar tonen in Linux de "st"-kolom, die steal rechtstreeks weergeeft. Zie je consistent meer dan 5–10% steal, dan deelt je VPS de CPU met meer VM's dan verstandig is.
Storage-overselling volgt hetzelfde patroon. Aanbieders wijzen samen meer schijfruimte aan VM's toe dan hun storage-arrays fysiek bevatten, in de veronderstelling dat de meeste klanten hun schijven toch niet vullen. Dat kan een tijdje goed gaan, maar zodra de onderliggende opslag vol raakt, mislukken schrijfacties of worden ze drastisch trager. Bij draaiende schijven was dit vroeger gebruikelijk; bij NVMe-arrays is het minder vergevingsgezind, omdat de prestaties dan hard instorten en meestal onverwacht.
Naast pure capaciteit kunnen prestaties ook degraderen door IOPS-throttling of concurrentie op gedeelde arrays. Zelfs als je fysiek toegewezen ruimte hebt, kunnen meerdere VM's die dezelfde SSD belasten de schrijfdoorvoer dichtknijpen.
Of het nu om RAM, CPU of disk gaat, overselling leidt tot wat algemeen het noisy neighbor-probleem heet. Je VPS deelt een fysieke host met andere klanten. Begint een van hen een back-uptaak te draaien, een grote codebase te compileren of een trafficpiek te verwerken, dan kan die onevenredig veel capaciteit opslokken en alle andere VM's op dezelfde host beïnvloeden.
Op een overboekte host kan één zwaar belaste klant de hele machine destabiliseren. Daarom voelt VPS-performance soms sterk inconsistent aan: razendsnel om 2 uur 's nachts, stroperig rond het middaguur. Die variatie is niet willekeurig; ze volgt simpelweg hoe druk je buren bezig zijn.
Er zijn een paar praktische manieren om dit te checken.
Houd CPU steal time in de gaten. Zoals gezegd is de st-kolom in top je duidelijkste signaal. Draai een CPU-intensieve taak en kijk of steal omhoog kruipt.
Doe een memory pressure-test. Tools als stress-ng kunnen geheugen alloceren en laten zien of je systeem begint te swappen onder belasting die het eigenlijk zonder moeite zou moeten aankunnen.
Benchmark de schijfdoorvoer regelmatig. Gebruik fio om sequentiële en willekeurige lees- en schrijfsnelheden op verschillende momenten van de dag te testen. Grote uitschieters tussen metingen wijzen op concurrentie in een gedeelde storagepool.
Monitor je basislatentie. Onverklaarbare latency-pieken, vooral bij lichte belasting, komen vaak door scheduling-vertraging in de hypervisor op een drukke host.
Aanbieders die niet overboeken, garanderen dat de capaciteit waarvoor je betaalt fysiek is gereserveerd voor jouw instantie. Je RAM is exclusief aan jouw VM toegewezen, niet gedeeld uit een gemeenschappelijke pool. Je vCPU's komen overeen met echte threads die niet aan vijftig andere VM's worden uitgedeeld. Je NVMe-opslag komt uit capaciteit die ook daadwerkelijk op de schijf bestaat.
Dat verschil zie je terug in consistentie. Benchmarks op verschillende momenten van de dag leveren vergelijkbare resultaten op. CPU steal blijft laag of op nul. Geheugenintensieve applicaties crashen niet zomaar. Schijfdoorvoer is voorspelbaar.
Het maakt ook uit voor de manier waarop je je systeem dimensioneert. Draai je een database of een cachinglaag, dan kun je bij overboekt RAM je geheugengrenzen niet vertrouwen. Je kunt je MySQL buffer pool instellen op 80% van je toegewezen RAM en er pas later achter komen dat dat geheugen fysiek nooit volledig voor jou beschikbaar was.
Het eerlijke antwoord is marge. Fysieke hardware is duur, en een aanbieder die 1:1 toewijst moet hogere prijzen vragen om kosten te dekken dan een aanbieder die dezelfde specificaties met een overcommit-ratio van 2:1 of 3:1 verkoopt. Voor veel toepassingen — laag bezochte websites of ontwikkelomgevingen — maakt overselling in de praktijk weinig uit. Het probleem is dat klanten die een overboekte VPS voor productie kopen er vaak pas achter komen wanneer er iets misgaat.
Sommige aanbieders zetten expliciet "geen overselling" of "gegarandeerde capaciteit" in hun communicatie. Daar mag je naar zoeken. Anderen reppen er met geen woord over, wat meestal een teken is om wat dieper te graven voordat je iets afsluit.
Overselling is een reëel prestatierisico, zeker voor wie productiediensten op een VPS draait. Hangt je toepassing af van voorspelbaar geheugen, CPU-toegang of schijfdoorvoer, dan telt wat je aanbieder daadwerkelijk garandeert zwaarder dan de vermelde specificaties.
Bedankt voor het lezen! Zoek je een hostingomgeving waar capaciteit nooit wordt overboekt? QDE biedt unmanaged KVM VPS-hosting met toegewezen RAM, pure NVMe-opslag en AMD EPYC- en Ryzen-processors — niets daarvan komt uit een overboekte pool.
Klaar om te beginnen of heb je nog vragen? Neem contact op met ons team en we helpen je het juiste pakket te kiezen voor jouw toepassing.
Overselling is wanneer een hostingaanbieder samen meer capaciteit aan zijn VM's toewijst dan de onderliggende fysieke server feitelijk heeft. Dat kan RAM, CPU en opslag betreffen en leidt vaak tot inconsistente of verminderde prestaties tijdens piekgebruik.
Het directste signaal is CPU steal time, zichtbaar in Linux via de st-kolom in top of vmstat. Consistent meer dan 5% steal onder matige belasting wijst op een overboekte host. Je kunt ook op verschillende momenten van de dag de schijfdoorvoer en het geheugen benchmarken; grote variatie is een rode vlag.
Niet altijd. Voor lichte toepassingen zoals laag bezochte sites of ontwikkelomgevingen kan een overboekte VPS prima draaien. Problemen worden zichtbaar bij langdurige belasting of wanneer meerdere klanten tegelijk actief zijn.
Het beschrijft de situatie waarin één klant op een gedeelde fysieke host een onevenredig deel van de capaciteit opslokt en daarmee de prestaties van iedereen op dezelfde machine ondermijnt. Het is een direct gevolg van overselling.
Zoek naar aanbieders die expliciet aangeven dat ze RAM of CPU niet overboeken. Bekijk benchmarks en onafhankelijke reviews. Vraag de aanbieder rechtstreeks naar hun overcommit-ratio's. Aanbieders die ontwijken of weigeren te antwoorden, doen vaak aan overselling.
RAM is de resource die het vaakst wordt overboekt, gevolgd door CPU. Opslag kan ook worden overboekt, al gebruiken sommige aanbieders thin-provisioned storagepools die zich in de praktijk vergelijkbaar gedragen.