Hardware-realiteiten, resourcelimieten en diepgaande prestatiemonitoring
Wanneer een QNAP NAS traag aanvoelt, begint het onderzoek bij wat de hardware aankan. Vervolgens wordt gekeken waar de NAS zijn resources aan besteedt, en pas daarna naar de dieper liggende wachtrijen: processen die vastzitten op I/O en virtuele machines die strijden om de processor.
- Verwachtingenwaar deze hardware voor is
- Basislijnstop de extra's, controleer RAM en SWAP
- D-statussenprocessen die vastzitten op I/O
- vCPU'sthreads, oversubscription, steal
- GrafiekenBlackBox en Pulse, goed lezen
01Hardwareverwachtingen en realiteit
QNAP-servers worden gebouwd met onderdelen die passen bij hun prijs. QNAP levert nog steeds firmware-updates voor units van meer dan tien jaar oud, maar dat betekent niet dat een oude of instap-NAS zonder compromissen alle hedendaagse apps kan draaien. Software wordt met elke nieuwe versie zwaarder; de hardware blijft wat hij was.
Een budget-NAS is ontworpen om bestanden soepel te serveren. Wie verwacht dat zo'n NAS zonder problemen virtuele machines of zware databases draait, begrijpt niet goed wat het apparaat is. Controleer wat je processor en geheugen echt aankunnen, en neem de verantwoordelijkheid voor je keuze van hardware. De kerntaak van de NAS is werken met bestanden; al het andere is een aanvulling die draait binnen de middelen die nog over zijn.
02Tak 1: de basislijn, door services te isoleren
Wanneer de NAS trager wordt, vooral wanneer het geheugen op is en het systeem SWAP begint te gebruiken (wat elke bewerking aanzienlijk vertraagt), is de eerste diagnostische stap het isoleren van de services.
- Log in op QTS of QuTS hero.
- Open App Center en stop de niet-essentiële apps en services één voor één. De Workbench stopt geen apps voor je.
- Bekijk het systeem in de Resource Monitor van QTS of in Pulse van de Workbench (het bureaublad Utilities, Startmenu → Monitoring → Pulse; alleen beheerders). Het dashboard ververst elke twee seconden: CPU-belasting met één balk per logische CPU, gebruikt RAM afgezet tegen totaal RAM, met de page cache in een aparte strook, een SWAP-balk wanneer de NAS swap heeft, de belasting over 1 minuut en de run queue. Kijk of de CPU-belasting en het SWAP-gebruik dalen.
- Vind de basislijn: blijf services stoppen totdat de kernfunctie van de NAS, het soepel serveren van bestanden, weer volledig terug is.
Dat is de basislijn van je hardware. Start van daaruit de andere apps één voor één op, strikt binnen de grenzen van de middelen die de hardware nog over heeft.
03Tak 2: D-statussen en verborgen knelpunten
Soms is het probleem niet een overbelaste CPU of een gebrek aan RAM. Het systeem kan vastlopen met een processor die nog lang niet vol is, wanneer processen in uninterruptible sleep staan, de D-status. In de eigen bewoordingen van de Workbench wacht een proces in status D op kernel-I/O (een schijf, een netwerkbestandssysteem, een vastgelopen driver) en kan het zelfs niet worden beëindigd (kill) totdat die I/O klaar is. Staan er veel processen in D, dan staan ze in de rij, meestal achter trage schijf-I/O, en loopt het apparaat vast.
Deze wachtrijvorming is het meest schadelijk wanneer de NAS virtuele machines (Virtualization Station, KVM) host. Een slechte verdeling van resources zie je daar aan verloren netwerkpakketten en lange I/O-vertragingen.
- Pulse meldt Processes in D-state (I/O) zodra één proces zich in de D-status bevindt, en markeert dit als kritiek bij meer dan twee processen. Op het tabblad Processes toont D + Z alleen de vastgelopen (D) en zombie (Z) processen en hun ouderprocessen.
- BlackBox registreert de gegevens van de NAS elke 20 seconden vanaf het moment dat het pakket draait; je hoeft niets in te schakelen. BlackBox bewaart de CPU-belasting, iowait en de kloksnelheid per core, de load, de run queue en Blocked (D); gebruikt en beschikbaar geheugen, page cache, swap en OOM kills; per interface het dataverkeer, de drops en TCP-retransmits; per schijf de await, queue depth en bezettingsgraad; de temperaturen en ventilators; en per VM de CPU, vCPU's, geheugen en disk-I/O. Elke meting van 20 seconden blijft een dag bewaard, daarna blijven er samenvattingen: een week lang per minuut, een maand lang per vijf minuten en een jaar lang per uur.
- Twee verschillende D-tellingen. Blocked (D) van BlackBox is het aantal geblokkeerde taken volgens de kernel; Pulse telt de processen die hij in status D ziet. De twee hoeven niet gelijk te zijn.
- iowait, geen PSI. De kernels van QNAP zijn gecompileerd zonder pressure stall information, dus de Workbench meet I/O-vertraging als iowait.
04CPU-toewijzing: pCPU, lCPU en vCPU
Ken de topologie voordat je een VM zijn resources geeft:
- pCPU (physical CPU): de fysieke cores van de NAS-processor.
- lCPU (logical CPU): de cores die het besturingssysteem ziet, inclusief Hyper-Threading. Hyper-Threading verdubbelt de prestaties niet; als vuistregel levert het ongeveer 30% meer doorvoer op.
- vCPU (virtual CPU): de virtuele cores die aan de VM's zijn toegewezen.
Pulse telt logische CPU's: toont Pulse 12 cores op een Xeon W-1250 met zes cores en twaalf threads, dan zijn dat threads.
De valkuil van oversubscription. 128 vCPU's toewijzen aan VM's op een 32-core processor veronderstelt dat ze nooit allemaal tegelijk druk bezig zullen zijn. Wanneer ze dat wel zijn, kan de hypervisor de vCPU's niet snel genoeg inplannen, en blijven de VM's hangen terwijl ze op CPU-tijd wachten, wat in een gastbesturingssysteem (guest) zichtbaar wordt als steal time (gestolen tijd). Pulse rapporteert dit vanaf de kant van de host:
- vCPU over-subscription (informatief) wanneer de draaiende VM's meer vCPU's hebben dan de NAS logische CPU's heeft;
- VMs contending for CPU (waarschuwing) wanneer daarnaast de host voor meer dan 75% bezig is, of de run queue langer is dan het aantal threads. De bijbehorende notitie op deze NAS: Over-subscribed (17 vCPUs / 12 cores) AND the host is busy (84%, queue 11) — your VMs are likely contending for physical cores NOW. This is CPU theft, host-side.
- Steal time wordt gemeten in het gastbesturingssysteem. Op de NAS is die waarde altijd nul, en dat hoort zo; de eigen notitie van de Workbench zegt dat je de steal van een guest niet vanaf de host kunt zien. Beoordeel de strijd (contention) op de NAS aan de hand van de vCPU's ten opzichte van de threads, het druktepercentage (busy) en de run queue, en lees de steal af in de VM (de
stkolom vantopofvmstatin een Linux-guest).
05De virtuele machines in de gaten houden
Je hoeft voor de Workbench geen agent in een VM te installeren. De Workbench meet de NAS waarop hij draait, en daarmee ook de virtuele machines op die NAS:
- Open Pulse, het tabblad VM: elke draaiende VM met zijn vCPU's, CPU%, geheugen, RSS, status en proces-ID, en de titelregel Hosting 4 VM(s), 17 vCPUs.
- Open BlackBox (Startmenu → Monitoring), ga naar Heat map en zet de rij Virtual machines aan: het CPU-gebruik van elke VM gedurende de dag, naast de temperaturen en de await van de schijven. De grafieken houden ook de vCPU's, het geheugen en de disk-I/O van elke VM bij, evenals het starten en stoppen van elke VM.
- Om te volgen of een VM via het netwerk bereikbaar is, voeg je het adres toe in BlackBox onder Settings → Monitored hosts: BlackBox registreert vervolgens de round trip en de packet loss.
- In de VM zelf volg je de steal time met de eigen tools van de guest.
Het venster Virtual Machines · LOCAL (Local NAS → Virtual Machines) toont de configuratie van elke VM vanuit Virtualization Station: het aantal vCPU's, de topologie, de CPU-set, het CPU-model, de schijven en netwerkkaarten. Bij het openen draaien de eigen diagnostische dumps van QNAP, en hun uitvoer komt in de cache van de Workbench; er wordt geen instelling gewijzigd.
06De grafieken lezen: de kritieke statussen
- Hoge D-status en I/O-vertraging. Processen wachten op de schijven. Het wekelijkse rapport van BlackBox noemt dit Processes waiting on storage (een iowait op het 95e percentiel van 20% of meer is een waarschuwing, 40% of meer is kritiek) en noemt de drukste schijf; Slow array member markeert een schijf waarvan de await tweemaal zo hoog is als die van de andere schijven in de array en ten minste 50 ms bedraagt (kritiek bij 200 ms), en Disk with no headroom markeert een schijf die gedurende twee uur voor 90% of meer bezet is. De oplossing is het advies van de auteur: verplaats de VM naar een SSD-volume, controleer de gezondheid van de schijven (zie de prestatiegids), en controleer of er geen ander proces de RAID verzadigt.
- Lange CPU-wachtrij. De processor van de NAS is oversubscribed: Pulse meldt VMs contending for CPU, en de melding Virtual machine hogging the host in het wekelijkse rapport wijst op een VM die 150% van één core of meer verbruikt (300% is kritiek). Wijs de VM's minder vCPU's toe: begin met één of twee per VM en voeg er pas meer toe als de guest ze echt nodig heeft.
- Thermal throttling (thermische snelheidsbegrenzing). Een hoge CPU-temperatuur, gevolgd door een lagere kloksnelheid en langere vertragingen, betekent dat de processor oververhit raakt. Het wekelijkse rapport noemt het CPU thermal throttling: een core draait op 60% of minder van zijn eigen gebruikelijke kloksnelheid terwijl de CPU voor minstens 60% belast wordt. Op de heatmap is 65 °C oranje en 80 °C rood. Het eigen advies van de Workbench: verwijder stof van de heatsink, de ventilatoren en de luchtinlaten, controleer of de ventilatoren draaien en verbeter de luchtstroom of verlaag de kamertemperatuur; een hogere ventilatorsnelheid in QTS helpt ook.
07KVM best practice: het CPU-model
- Host / passthrough (aanbevolen): geeft de NAS-processor zelf door aan de VM, met alle instructiesets die hij heeft (bijvoorbeeld AVX). Het levert de beste prestaties op en zorgt voor de minste overhead op een enkele NAS.
- Een geëmuleerd model (een generieke Intel- of AMD-CPU): verbergt de processor van de host. Dit is handig in een cluster, om draaiende VM's te verplaatsen tussen fysiek verschillende hosts; op een enkele NAS kost het alleen maar prestaties.
Het venster Virtual Machines · LOCAL toont het CPU-model dat aan elke VM is toegewezen (bijvoorbeeld Westmere) en zijn topologie; de Workbench beoordeelt die keuze niet.
08Basiskennis: resource overcommit
Zo voorkom je dat de prestaties van je VM's wegzakken aan de grens van wat een NAS kan. Het eerste wat je moet tellen, is de verhouding tussen vCPU's en fysieke cores (pCPU):
| Resource | Voordeel | Risico | Advies |
|---|---|---|---|
| CPU (vCPU : pCPU) | meer VM's, goedkope reserve voor korte pieken | bij verzadiging zorgen steal en wachtrijen voor vertraging in elke VM | productie 2:1–4:1, kritieke VM's tot 2:1; host blijft onder 80 % |
| RAM (ballooning, Dynamic Memory) | geheugen dat tijdens het draaien wordt verplaatst, goed voor VM's die niets doen | als de host swapt, dalen de prestaties drastisch | laat de host nooit actieve pagina's swappen; reserveer geheugen voor kritieke VM's |
| Storage (thin) | ruimtebesparing, schijven in een oogwenk gemaakt | een volle datastore stopt de VM's onmiddellijk | waarschuwingen bij 75–85 %; ruimte vrijmaken (UNMAP); kritieke data beter thick |
Algemene regel. Overcommit is veilig onder een lichte, ongelijkmatige belasting in combinatie met actieve monitoring, en is gevaarlijk bij piekbelastingen zonder reserve. Zorg ervoor dat er altijd een reserve is.
Tips
- Begin met 1 vCPU per VM en voeg er alleen meer toe als de belasting dit vereist. Meer vCPU's toewijzen dan nodig is betekent meer overhead voor de scheduler, niet meer snelheid.
- Tel fysieke cores, geen threads. Wijs aan alle VM's samen niet meer vCPU's toe dan de host aan cores heeft.
- Houd de CPU van de host onder de 80 %. Boven de 90 % strijden de VM's met elkaar om cycles, waardoor de steal in de guests toeneemt.
- Lees "top" in de guest: %wa is wachten op I/O (een schijf-bottleneck), %st is steal (te veel overcommit), %id is reservecapaciteit.
- Hoog %wa? Snellere opslag of een SSD. Hoog %st? Minder vCPU's of minder VM's.
- VirtIO voor schijf en netwerk: veel sneller dan emulatie. Gebruik PCIe- of GPU-passthrough alleen als het echt nodig is: het apparaat hoort dan bij één VM alleen.
Een VM-snapshot is geen back-up
Een snapshot registreert alleen het verschil ten opzichte van het basispunt (de wijzigingen op de schijven, en met een opgeslagen status ook het geheugen). Beschadiging aan de basis of aan de snapshotketen maakt ook de snapshots ongeldig. Wil je echt beschermd zijn, maak dan een back-up van complete VM-images: met een export, met HBS of op een apart medium.