# Waarom je Mac traag is en hoe je dat onderzoekt

> Meet CPU, geheugendruk, opslagcapaciteit, schijf-I/O, thermische status en netwerklatentie terwijl de vertraging bezig is.

Published: 2026-07-04 | Updated: 2026-10-18

Een trage Mac is een latentieprobleem, en meerdere knelpunten kunnen hetzelfde gevoel geven: CPU-strijd, geheugendruk, opslagcapaciteit, schijf-I/O, thermische grenzen of een trage netwerkdienst. Het doel is te bepalen welke bron verzadigd is terwijl de vertraging bezig is. Een momentopname nadat het probleem voorbij is, bewijst weinig.

Zo werken de onderdelen, en dit zijn de opdrachten om ze te zien.

## De mythe van RAM: vrij geheugen is niet het doel

Het meest voorkomende verkeerde instinct is naar "vrij geheugen" kijken en in paniek raken wanneer dat laag is. Op macOS is weinig vrij geheugen normaal en gezond. Ongebruikt RAM is verspild RAM, dus de kernel houdt het met opzet vol: recent gebruikte bestanden blijven in het geheugen gecachet zodat de volgende leesactie direct is, en die cache wordt vrijgegeven op het moment dat een programma de ruimte nodig heeft.

macOS comprimeert geheugen ook. Sinds OS X Mavericks comprimeert het systeem, wanneer het RAM vol raakt, inactieve pagina's ter plekke in plaats van ze meteen naar schijf te schrijven, zodat gegevens die anders naar langzamere swap zouden gaan in het RAM kunnen blijven. Je kunt de tellers direct bekijken:

```
vm_stat
```

De getallen zijn in pagina's, met de paginagrootte bovenaan afgedrukt. Wat telt is niet `Pages free` maar geheugendruk en de snelheid van verandering. `Swapins` en `Swapouts` zijn cumulatief sinds het opstarten, dus één groot getal bewijst geen actueel probleem. Draai de opdracht twee keer tijdens de vertraging, of gebruik Activiteitenweergave, om te zien of swap en druk blijven stijgen.

Het beste overzicht is **geheugendruk** in het tabblad Geheugen van Activiteitenweergave. De [geheugengids](https://support.apple.com/guide/activity-monitor/actmntr34865/mac) van Apple definieert groen als efficiënt gebruik, geel als mogelijke druk, en rood als meer RAM nodig. Lees die grafiek samen met de swaptrend en de applijst, niet alleen het cijfer voor vrij geheugen.

## Vind het echte knelpunt

<figure class="blog-diagram">
  <img src="https://mole.fit/img/en/status.webp" width="2584" height="1741" loading="lazy" alt="Een systeemoverzicht met tegels voor CPU op 16 procent en 47 graden, GPU op 0 procent, geheugen op 72 procent met een druk van 28 procent, schijf, netwerk en ventilator, boven een lijst van de zwaarste processen gesorteerd op CPU en geheugen.">
  <figcaption>De getallen die een trage Mac op één scherm verklaren: CPU-belasting en temperatuur, geheugendruk, en de processen die de meeste bronnen gebruiken. Dit is de Statusweergave van Mole.</figcaption>
</figure>

Open Activiteitenweergave en lees de tabbladen op volgorde, of gebruik de opdrachtregel:

- **CPU:** sorteer op gebruik met `top -o cpu` in Terminal, of het tabblad CPU van Activiteitenweergave. Let op dat %CPU per kern is, dus een waarde boven 100% is één proces dat meerdere kernen gebruikt. Dat is normaal voor een build of een export, en verdacht voor een app in rust.
- **Geheugen:** de drukgrafiek, zoals hierboven.
- **Schijfcapaciteit:** draai `df -h /`. APFS gebruikt vrije ruimte voor swap en tijdelijke bestanden, en een bijna volle schijf kan updates blokkeren of een taak zonder tijdelijke ruimte laten zitten. Er is geen universeel veilig percentage, dus vergelijk de beschikbare capaciteit met de taak die faalt. Als dit jouw probleem is, [zoek wat de schijf vult](https://mole.fit/nl/blog/how-to-find-large-files-on-mac) en [maak ruimte vrij](https://mole.fit/nl/blog/how-to-free-up-space-on-mac).
- **Schijf-I/O:** sorteer in het tabblad Schijf van Activiteitenweergave op Geschreven bytes of Gelezen bytes en kijk naar de grafiek terwijl de pauze optreedt. `iostat -w 1` geeft een live beeld op de opdrachtregel. Een synchronisatie, reservekopie, build of falende externe schijf kan latentie veroorzaken terwijl er nog volop capaciteit over is.
- **Warmte:** hieronder behandeld.
- **Netwerk- of dienstenlatentie:** als alleen één app met een clouddienst traag is terwijl lokale apps responsief blijven, controleer dan de netwerkactiviteit en de status van die dienst voordat je de Mac wijzigt. Niet elke trage interactie is een hardwareknelpunt.

Deze metingen scheiden een systeembreed knelpunt van één trage app. Gokken met een algemene opruiming kan meerdere variabelen tegelijk wijzigen en de echte oorzaak verbergen.

<figure class="blog-diagram">
  <img src="https://mole.fit/img/blog/performance-bottlenecks.webp" width="1360" height="454" loading="lazy" alt="Een belasting die uitwaaiert naar CPU-verzadiging, geheugendruk, schijfinvoer en -uitvoer, en thermische throttling, en daarna samenkomt als latentie">
  <figcaption>CPU-strijd, geheugendruk, schijf-I/O en thermische grenzen komen allemaal als latentie naar boven, maar elk vraagt een andere reparatie.</figcaption>
</figure>

## Een op hol geslagen proces

Als de CPU vastzit, toont `top -o cpu` de schuldige bovenaan. Een vastgelopen app, een synchronisatieclient die opnieuw scant, of een achtergrondhelper in een lus zijn de gebruikelijke gevallen. Als je het herkent als veilig om te beëindigen, sluit het dan. Als het zichzelf binnen seconden opnieuw start, zoek dan naar een launchd-taak of een app die zijn helper herstart (zie het opstartgedeelte hieronder). Alleen het proces sluiten houdt dan misschien niet.

Wees voorzichtig met systeemprocessen. `kernel_task` die stijgt is vaak het systeem dat met opzet CPU-tijd gebruikt om de chip te vertragen wanneer die heet is, geen bug om te killen. Dat is een thermisch symptoom, geen geheugen- of appsymptoom.

## Thermische throttling

Wanneer een Mac heet wordt, verlaagt de chip zijn kloksnelheid om af te koelen, en zwaar werk voelt sloom. Je kunt het bevestigen in plaats van te gokken:

```
pmset -g therm
```

Dit meldt de vastgelegde thermische en prestatiewaarschuwing wanneer macOS die beschikbaar stelt. Voor één gedetailleerd monster van vermogen en thermische druk gebruik je:

```
sudo powermetrics --samplers thermal,cpu_power -n 1
```

Interpreteer trends onder dezelfde belasting, in plaats van één temperatuur als universele grens te behandelen. Als throttling het knelpunt is, is de reparatie de belasting, de luchtstroom of service, niet het opschonen van caches. Een luide ventilator kan ondersteunend bewijs zijn, maar Macs zonder ventilator kunnen ook throttlen, en [waarom de ventilator van je MacBook luid is](https://mole.fit/nl/blog/macbook-fan-loud-overheating) behandelt wat je daaraan doet.

## Spotlight en inlogonderdelen

Twee achtergrondoorzaken zijn het uitsluiten waard. Na een macOS-update, een migratie of het verplaatsen van veel bestanden kan Spotlight delen van zijn index opnieuw bouwen. `mdutil -s /` meldt of indexering aan staat, niet of een herbouw nu actief is. Aanhoudende CPU van `mds` of `mdworker`, plus schijf-I/O en de voortgangsinterface van Spotlight, geven de context. De duur hangt af van de hoeveelheid gegevens, de opslagsnelheid, de rechten en herhaalde bestandswisselingen, dus er is geen betrouwbare belofte van één uur.

Het andere is opstartbelasting. **Systeeminstellingen > Algemeen > Inlogonderdelen en extensies** scheidt apps die bij het inloggen openen van software die op de achtergrond mag draaien. Die kunnen Service Management, launchd, extensies of app-helpers gebruiken. Zet één bekend item tegelijk uit en bevestig dat de app die het bezit nog werkt.

## Onder de motorkap: hoe een monitor dit leest zonder het erger te maken

Je kunt dit deel overslaan, maar het legt uit waarom het geheugenadvies hierboven klopt, en waarom een live monitor zelf niet een van je trage processen wordt. De [open-source CLI](https://github.com/tw93/Mole) van Mole (`cmd/status`) en de native Mac-app gebruiken aparte verzamelaars, maar beide splitsen snelle metingen van langzame verrijking.

De CLI vult de waarde voor gecachet geheugen, die zijn platformoverstijgende meetbibliotheek op macOS niet kan leveren, door bestandsondersteunde pagina's uit `vm_stat` te lezen en te vermenigvuldigen met de gemelde paginagrootte. Hij leest de systeemdrukstatus uit `memory_pressure` in plaats van die af te leiden uit vrije bytes. De native app komt tot hetzelfde antwoord zonder een shell te starten: hij leest VM-tellers met `host_statistics64` en het drukniveau via `kern.memorystatus_vm_pressure_level`.

Licht blijven is de andere helft. Een monitor die bij elke tik alles opnieuw zou meten, zou zelf een prestatieprobleem zijn, dus de verzamelaar meet in lagen:

<figure class="blog-diagram">
  <img src="https://mole.fit/img/blog/tiered-metrics-sampling.webp" width="1360" height="454" loading="lazy" alt="Snelle, langzame en eenmalige systeemmetingen gaan door gelijktijdige verzamelaars of caches, komen samen in één momentopname, gaan een ringbuffer in en worden getoond in de statusweergave en de HUD in de menubalk">
  <figcaption>De implementaties staan los van elkaar, maar het planningspatroon is hetzelfde: snelle metingen verversen live, langzame peilingen hergebruiken gecachete resultaten, en één samengevoegde momentopname voedt de huidige metingen plus een begrensde geschiedenis.</figcaption>
</figure>

De goedkope getallen (CPU, geheugen en netwerk) verversen ongeveer eens per seconde. Verrijking van processen, GPU en schijf draait op zwaardere tikken, terwijl hardware- en apparaatpeilingen caches met een langere levensduur hergebruiken. Geschiedenissen van vaste grootte bewaren alleen de recente monsters die de sparklines tekenen. Zo kan een HUD in de menubalk live bijwerken zonder van de monitor de belasting te maken die je probeert te onderzoeken.

## Waar een tool helpt

Alles hierboven is te lezen met ingebouwde opdrachten, en dat is het punt: je hebt geen app nodig om een trage Mac te onderzoeken. Wat een app je bespaart is het bij elkaar zoeken. De Statusweergave van [Mole](https://mole.fit/) toont CPU, geheugendruk, schijf, temperatuur en de zwaarste processen op één scherm, met een live uitlezing in de menubalk. Een proces aanklikken legt uit wat het heeft gestart, of het de Mac wakker houdt, en wat het leest en schrijft. Dat is hetzelfde launchd- en I/O-detail dat je anders met de hand zou verzamelen. Het is gemak boven de opdrachten, geen vervanging van ze begrijpen.

Wat je ook gebruikt, vermijd "versnel"-rondes in één klik die ongerelateerde status wijzigen. Je kunt geen blijvende prestatiewinst maken door een nuttige bestandscache uit het RAM te dwingen. Herstarten kan een nuttige diagnose zijn voor een vastgelopen proces en is voor sommige updates verplicht, maar macOS beheert geheugen en swap al continu.

## Een diagnose die je kunt herhalen

Reproduceer de vertraging, kijk naar CPU, geheugendruk, schijfcapaciteit, schijf-I/O, thermische status en netwerkactiviteit, en wijzig daarna één variabele. Meet opnieuw onder dezelfde belasting. Zo wordt "de Mac voelt traag" een oorzaak die je kunt weerleggen, en voorkom je dat een tijdelijke herstart of opruiming wordt aangezien voor een blijvende reparatie.

---

Canonical HTML page: https://mole.fit/nl/blog/why-is-my-mac-so-slow
Blog index for agents: https://mole.fit/nl/blog/llms.txt
Site index for agents: https://mole.fit/llms.txt
