Hoe RAM correct te testen op QNAP-servers met behulp van MemHound
RAM testen terwijl het besturingssysteem draait (in userspace), is technisch lastig. Het besturingssysteem, virtualisatie en caching-services (vooral de ZFS ARC) blijven adresruimte reserveren en blokkeren de toegang daartoe.
MemHound, het Memory Doctor-venster van StorageDiag Workbench, werkt met een escalatieladder: Quick → Standard → Deep → Hammer → Boot. Het vergrendelt al het vrije RAM dat het mag nemen, op een marge van 256 MB na, schrijft er testpatronen in en leest ze terug. Het houdt elk blok vast tot de testronde voorbij is, zodat de kernel elke vrije pagina moet afstaan. Hieronder lees je hoe je de stabiliteit van het geheugen controleert voor jouw configuratie en bestandssysteem.
- Quicksnelle scan, de NAS blijft functioneren
- Standardmoving inversions, de NAS blijft functioneren
- Deepstopt services, maakt de ARC vrij
- Hammerrow-hammer op elke core
- Bootde USB-stick, buiten het NAS-systeem
01Dagelijkse diagnostiek op QTS (ext4)
Met een traditioneel bestandssysteem (ext4) reserveert QTS geen grote hoeveelheden RAM voor zichzelf, waardoor een betrouwbare test vanuit het draaiende systeem eenvoudiger is. Geheugenfouten duiken vaak op in de user space, en daarom werken regelmatige snelle tests goed.
- Schakel de niet-kritieke netwerkservices uit (Samba, NFS, AFP).
- Stop de zware apps in App Center (HDMI desktop stations, containers, virtuele machines) en laat alleen StorageDiag draaien. Laat maar één browsertabblad met de NAS open.
- Met vrijgemaakte caches en gestopte services is het grootste deel van het fysieke RAM vrij voor de test. De Quick-kaart krijgt de tag
DAILYwanneer ten minste 90% van het RAM vrij is. - Voer de Quick-test uit. Die test is snel: na een adrescontrole draait hij twee patronen, en hij slaat de cache-flush per regel over die Standard wel doet. Stel 1 tot 3 rondes in (het veld Passes accepteert 1 tot 16, en begint bij 1). Heeft het geheugen dat de test bereikt een hardwarefout, dan vindt de test die vrijwel meteen.
02Diagnostiek op QuTS hero (ZFS)
Het ZFS-bestandssysteem gebruikt de ARC (Adaptive Replacement Cache), die het grootste deel van het beschikbare RAM in beslag kan nemen. Een gewone Quick-test dekt dan maar een klein deel van het geheugen.
- Kies de Deep-test in plaats van Quick.
- Zodra je bevestigt (Stop services & test), stopt MemHound de NAS-services en de App Center-apps (het webpaneel blijft actief), leegt het de ZFS ARC en wist het de kernel-caches. Dit maakt het grootste deel van het fysieke geheugen vrij voor de test: op een 128 GB TS-1288X nam het beschikbare geheugen toe van 96,6 GB naar 116,9 GB.
- Werkwijze: eerst draait een Quick-ronde over het vrijgemaakte RAM. Vindt die ronde fouten, dan stopt de procedure meteen, en dat bespaart tijd. Vindt ze geen fouten, dan gaat de tool verder met de Standard-ronde.
- Downtime: de services liggen stil vanaf het moment dat ze worden gestopt tot het einde van beide testrondes, en een Standard-ronde over veel RAM kan uren duren. Ze starten vanzelf weer wanneer de test eindigt, wanneer je hem annuleert, als het testproces wegvalt, en uiterlijk twee uur na de start. Duurt alleen al het stoppen van de services langer dan 30 minuten, dan wordt de test afgebroken en wordt alles hersteld.
03Absoluut testen (Rescue-modus / offline)
Wanneer het kernel-logboek (klog) wijst op instabiel geheugen (spontane segfaults in verschillende programma's, call traces, machine checks of EDAC-fouten) maar de tests vanaf het draaiende systeem (Quick, Deep) eindigen met PASS, stap dan over op een geïsoleerde omgeving, die het besturingssysteem van de NAS volledig omzeilt.
Optie A: een opstartbare USB-stick (aanbevolen)
De USB-stick is zo gebouwd dat de hele test vanzelf draait, ook op apparaten waarop je geen monitor en toetsenbord kunt aansluiten. Je hoeft nergens op een toets te drukken. De opstartvermelding maakt de USB-stick de standaard voor de volgende herstart. De test start vanzelf en meldt zijn voortgang op het eigen adres van de NAS; het MemHound-venster leest dat voor je uit. Na een PASS herstart de NAS vanzelf in QTS en toont het venster het oordeel; na een geheugenfout schakelt de test de NAS uit (zie hieronder). Een monitor en toetsenbord zijn alleen nodig wanneer de firmware de opstartvermelding niet kan verwerken en de USB-stick via het opstartmenu van het apparaat moet worden gestart.
- Klik in het MemHound-venster op Create bootable USB in de titelbalk.
- Steek een USB-stick van meer dan 192 MB in een USB-poort van de QNAP. Alles erop wordt gewist en de huidige formattering doet er niet toe.
- Klik op Update the image als de wizard een nieuwere build aanbiedt (Download the image de eerste keer), en volg daarna de aanwijzingen: Continue, typ de apparaatnaam, Erase and write, Add the boot entry.
- Herstart de server vanaf de voorbereide diagnostische USB-stick (Restart now and test). Is de NAS weer terug, dan toont het venster het oordeel.
De USB-stick start alleen x86-apparaten op: een ARM-apparaat kan de generieke image niet opstarten.
Wanneer de test tijdens het opstarten niet verloopt zoals gepland
- De NAS start de test niet vanaf de USB-stick. Add the boot entry plaatst één bestand,
grub/custom.cfg, op de eigen opstartpartitie van de NAS. Bij het inschakelen zoekt de bootloader van de NAS (GRUB) naar een volume met het labelMEMHOUNDen start dat volume als hij het vindt. GRUB ziet een USB-stick alleen via de eigen USB-ondersteuning van de firmware, dus de NAS start QTS zoals gewoonlijk wanneer de firmware de USB-stick bij het inschakelen niet aanbiedt (bij sommige goedkope of slechte USB-sticks gebeurt dat niet), wanneer USB-opstarten is uitgeschakeld in de firmware-setup, of om een reden die de firmware niet toont. Probeer een andere USB-stick, een USB-poort aan de achterkant, of start de USB-stick via het opstartmenu van het apparaat (F11, of de toets die dit model gebruikt, bij het inschakelen). De wizard meldt This firmware cannot be given a boot entry wanneer de bootloader het bestand helemaal niet leest, en The boot entry here is an old one wanneer een eerdere versie het heeft geschreven (Replace the boot entry). Een USB-stick waarvan de test al is uitgevoerd, wordt niet nogmaals gestart: schrijf de stick opnieuw met Create bootable USB om nog een keer te testen. - De NAS heeft zichzelf uitgeschakeld en is niet meer opgestart. Dat is wat de test doet als hij een geheugenfout vindt: hij schakelt de NAS opzettelijk uit, zodat er niets naar de schijven wordt geschreven zolang het geheugen in die toestand is. Hij herstart de NAS niet. Een test die slaagt, herstart de NAS in plaats daarvan naar QTS. Een NAS die zichzelf tijdens de opstarttest heeft uitgeschakeld en uit is gebleven, wijst dus op een geheugenfout. De details staan op de USB-stick (FAT32, label
MEMHOUND): lees/memhound/report-<time>.txtenmap-<time>.jsonop een willekeurige computer, of steek de USB-stick in een gezonde NAS met StorageDiag Workbench en open MemHound, dat de stick zelf uitleest.
Optie B: Rescue-modus (zonder geconfigureerde schijven) via SSH
Werk je liever op afstand en ken je de basis van de opdrachtregel, dan biedt deze modus een volledige test zonder USB-stick.
- Log in op de QNAP-server via SSH.
- Kies in het tekstmenu (QTS Console Management) voor een herstart van de server in de Rescue-modus (zonder geconfigureerde schijven).
- Na de herstart vindt Qfinder de server als "uninitialized". Dat hoort zo.
- Schakel SSH in via Qfinder. Log in als
admin(op QTS 5.2 en nieuwer is het standaardwachtwoord het cloud-wachtwoord; op oudere versies is dit het volledige MAC-adres in hoofdletters zonder dubbele punten). - Download en pak MemHound uit met het eerste blok hieronder, en start daarna met het tweede blok de tests in de tekstmodus.
Volg het initialisatie- of reset-scherm in de browser niet: gebruik alleen Qfinder. De Rescue-modus heeft een DHCP-netwerk met internettoegang nodig.
# Download en pak MemHound uit
arch=$(uname -m)
[ "$arch" = armv7l ] && arch=armhf
wget https://www.qnaputilities.com/pub/memhound/bin/memhound.tar.gz
tar zxvf memhound.tar.gz
chmod +x memhound-*
# Quick test met 2 passes (aanbevolen startpunt) ./memhound-$arch --quick --passes 2 --ui # Standard test (na een Quick PASS met End reason : completed) ./memhound-$arch --standard --ui
Quick controleert eerst de adressen, schrijft dan een schaakbordpatroon en een random moving inversion. Standard herhaalt deze twee patronen en voegt er nog elf toe, allemaal in één run, en voert één ronde (pass) uit tenzij je --passes toevoegt. Wanneer de tekstinterface sluit, toont MemHound een samenvatting in het Engels. Ga door met Standard wanneer er Verdict : PASS en End reason : completed staat: een testronde die is afgebroken door geheugendruk (memory pressure) geeft nog steeds PASS aan, met End reason : aborted: …. Sectie 04 legt de andere oordelen uit.
04Hoe de resultaten te lezen
MemHound beslist volgens vaste regels, en de regels hangen af van de test. Quick, Standard, Deep en Hammer zoeken naar fouten in het geheugen dat ze bereiken. Benchmark en Quality, verderop, beoordeelt een complete geheugenkit.
Quick, Standard, Deep en Hammer
- Harde en transiënte fouten. Eén foute leesactie is nog geen reden om een module af te schrijven. MemHound telt zo'n fout als transiënt: de kaart markeert het als Suspect en de tekstsamenvatting zegt
PASS_WITH_TRANSIENTS. Een fout wordt hard wanneer een latere controle opnieuw faalt op hetzelfde adres in het eigen geheugen van MemHound (het virtuele adres; het fysieke adres staat ernaast alsp=), standaard na twee treffers (--hard-threshold 2). Elke harde fout leidt tot het oordeelFAIL. - Wat het Workbench-venster zegt. De statusregel telt beide soorten, bijvoorbeeld FAIL — 0 hard fault(s), 1 transient. Is er geen harde fout, herhaal de test dan offline (met de USB-stick of in Rescue-modus) voordat je een module de schuld geeft: de gids in de app behandelt een resultaat met uitsluitend transiënte fouten als reden voor een offline hertest, nooit voor een RMA. De tekstsamenvatting voegt toe dat dergelijke resultaten kunnen wijzen op de voeding, hitte of timings die op het randje zitten.
- ECC-tellers en het kernel-logboek. De ECC-tellers (EDAC) en de gebeurtenissen uit het kernel-logboek staan naast het resultaat, en de samenvatting voegt
<== HARDWARE ECC ERRORS DURING TESTtoe wanneer een teller is gestegen. Ze veranderen het oordeel niet, dus controleer ze zelf. - Hoe de testronde is geëindigd. De samenvatting eindigt met
End reason:completed,stopped by userofaborted: …. Een testronde die niet eindigde metcompletedheeft niet alles getest wat de bedoeling was, ongeacht wat de oordeelregel zegt.
Goed om te weten: Benchmark en Quality
De Benchmark and Quality-knop in de titelbalk van MemHound meet de aanhoudende geheugenbandbreedte ten opzichte van het JEDEC-cijfer van de geïnstalleerde modules, controleert latentie-jitter en geeft FAIL bij elke bitfout. Het oordeel is PASS (of PASS-UNQUALIFIED), MARGINAL, FAIL of INCONCLUSIVE, en de regels zijn strenger dan bij de foutenjacht.
Een klik op de knop start de run direct, zonder bevestigingsvraag. De eerste run kan niet worden onderbroken en standaard wordt het resultaat gepubliceerd op het openbare RAM-bord.
- Fouten. Eén bitfout, één ongecorrigeerde ECC-fout (UE) of één kritieke kernelgebeurtenis die tijdens de run wordt gelogd, maakt het oordeel FAIL. Kritieke gebeurtenissen zijn een machine check of "Hardware Error", een ongecorrigeerde geheugenfout, een memory failure, datacorruptie of een kernel panic. Een gecorrigeerde ECC-fout (CE) beperkt het oordeel tot MARGINAL: de module werkt, maar de kit kan niet worden gecertificeerd. Segfaults, call traces, Oops en OOM kills worden wel getoond, maar veranderen het oordeel niet.
- Een gematchte kit. De test beoordeelt één gematchte kit. De kit komt niet door de toegangscontrole (de gate) wanneer de modules verschillen (op onderdeelnummer, of op grootte, snelheid, type en ECC wanneer DMI het onderdeelnummer niet weergeeft), wanneer er 3 modules zijn of een oneven aantal boven de 4, of wanneer kanalen A en B een verschillende capaciteit hebben. De test gaat wel door ter informatie, maar het oordeel is FAIL, en het resultaat wordt niet opgeslagen en niet gedeeld. Wanneer DMI niets meldt, wordt de gate overgeslagen.
- Een drukke NAS. Wanneer de bandbreedte tekortschiet (FAIL of MARGINAL) of de latentie-jitter faalt terwijl de NAS drukbezet is (een 1-minuut belasting van meer dan 0,6 per CPU), te weinig geheugen heeft (minder dan 40% vrij bij de start) of wordt gethrottled, is het oordeel INCONCLUSIVE: de toestand van het systeem is de oorzaak, niet de modules. Een test die door jou of door de memory guard is gestopt, is ook INCONCLUSIVE. Bitfouten, UE, kritieke kernelgebeurtenissen, patroonfouten, bit fade en de kit gate worden op deze manier nooit verzacht.
05RAM in een NAS, best practices en hardware-eigenaardigheden
Voordat je de schijven of het netwerk de schuld geeft van trage overdrachten, helpt het om te weten wat er bijzonder is aan geheugen in een NAS. NAS-geheugen is geen gaming-PC-geheugen. Een NAS draait de klok rond onder een constante belasting: systeembuffers, de ZFS-cache (ARC), virtuele machines en containers. Wat een NAS van het geheugen nodig heeft, is stabiliteit en compatibiliteit, geen recordkloksnelheden. Een NAS verdraagt fouten ook slechter dan een desktop-pc: door een lange uptime en een constante belasting komen zeldzame fouten boven die op een pc door het vele herstarten verborgen blijven.
"Het werkt" is niet hetzelfde als "ondersteund"
- Buiten de specificatie. Een NAS start vaak op met meer geheugen dan de officiële limiet van de processorfabrikant, bijvoorbeeld 32 GB in een systeem met een opgegeven maximum van 16 GB.
- Stabiel op het eerste gezicht. Een dergelijke configuratie doorstaat meestal de power-on self-test, rapporteert de volledige capaciteit en draait goed zolang hij niets te doen heeft. De fouten verschijnen pas onder een lange, zware belasting.
- De ondersteuning van de fabrikant. Wanneer er iets faalt, kan de QNAP-ondersteuning weigeren te helpen totdat de fout wordt bevestigd op de originele, ondersteunde modules. Bewaar de originele modules voor het geval je een supportticket moet openen.
Het mixen van modules: wat te vermijden en waarom
Gemengde modules vergroten de kans op incompatibiliteit en instabiliteit aanzienlijk.
- Verschillende merken of snelheden. De modules bevatten verschillende SPD-profielen en sub-timings, en de geheugencontroller moet ze allemaal afstemmen op wat ze gemeen hebben, meestal het langzaamste gedeelde JEDEC-profiel.
- Een derde module. Het toevoegen van één module aan een paar verbreekt de dual-channel symmetrie: een deel van het geheugen draait in de tragere single-channel modus, en de extra module verhoogt de elektrische belasting op de bus. Drie modules kunnen minder bandbreedte en meer latentie opleveren dan twee gematchte exemplaren. Daarom weigert Benchmark and Quality van MemHound drie modules te beoordelen, en ook elk oneven aantal boven de vier.
- ECC met non-ECC. Combineer nooit foutcorrigerende modules (ECC) met gewone modules (non-ECC).
Dual channel en de rol van ECC
- Dual channel. Een gematcht paar identieke modules (dezelfde capaciteit, snelheid, timings en rank-organisatie) is de stabiele keuze en stuurt beide kanalen samen aan, een 128-bits pad. Bij echte workloads is de winst typisch 1,2× tot 1,5×. Dat merk je bij geheugenintensief werk zoals videotranscodering, waarbij de geïntegreerde GPU de geheugenbandbreedte deelt met de processor. Bij gewoon bestanden aanbieden is de winst klein: het netwerk en de schijven bepalen daar de limiet.
- ECC en ZFS. ECC-geheugen corrigeert single-bit fouten op het moment dat ze optreden en detecteert double-bit fouten. Dat is vooral belangrijk bij QuTS hero: ZFS verifieert de checksums van wat het van de schijven leest, maar vertrouwt op wat er in het geheugen staat. Een bit die in het RAM omklapt voordat de checksum is berekend, wordt naar de schijf geschreven met een geldige checksum, alsof het correct was, en blijft daar staan.
- Wat ECC nodig heeft. ECC is afhankelijk van de processor en het moederbord. Op consumentenplatforms zonder ECC, zoals veel Intel Celeron en Pentium-processors, kan deze functie met geen enkele instelling worden ingeschakeld.
Symptomen van slecht geheugen
Let op hoe de NAS zich gedraagt voordat je de schijven de schuld geeft van slechte prestaties. Slecht of incompatibel geheugen herken je aan:
- helemaal niet opstarten, of steeds weer herstarten, direct nadat het geheugen is veranderd;
- er wordt minder geheugen gedetecteerd dan er is geïnstalleerd;
- willekeurige vastlopers of spontane herstarts;
- op platforms met ECC: ongecorrigeerde fouten (machine checks, EDAC UE) in het kernel-logboek, wat een bewijs is van een hardwarefout. Eén enkele gecorrigeerde fout is dat niet (de eigen gids van de Workbench over machine checks zegt: Don't panic at a single corrected event), maar gecorrigeerde fouten die steeds van één module komen, wijzen wel naar die module.
OOM-fouten
De OOM killer van de kernel beëindigt processen wanneer niet aan een verzoek om geheugen kan worden voldaan, om het systeem zelf draaiende te houden. Meestal betekent dit te weinig geheugen voor wat er draait, of overbelast geheugen, en geen defecte module. Het kan gebeuren terwijl de Resource Monitor nog steeds veel vrij geheugen toont, want 'vrij' is niet hetzelfde als 'bruikbaar' voor dat specifieke verzoek:
- het verzoek heeft mogelijk één aaneengesloten blok nodig, en vrij geheugen dat verspreid ligt in kleine stukjes kan daaraan niet voldoen;
- een container of een app kan zijn eigen geheugenlimiet hebben bereikt, ongeacht hoeveel de NAS als geheel nog vrij heeft;
- geheugen dat wordt vastgehouden door de ZFS ARC, huge pages of locked pages, wordt niet onmiddellijk vrijgegeven;
- en bij defecte hardware haalt de kernel pagina's uit de roulatie na geheugenfouten (
Memory failurein het kernel-logboek), en een module die het systeem niet volledig detecteert, laat het systeem minder geheugen over om mee te werken.
Let dus op het beschikbare (available) geheugen in plaats van het vrije (free) geheugen, en test het geheugen sowieso. Elke MemHound-test controleert eerst de adressen en meldt een vastgelopen adres voordat er enig patroon draait, en de Workbench plaatst een waarschuwing op het Memory-icoon wanneer een bundel OOM-kills of een gemengde geheugenkit vertoont.
| Platform | ECC | Modules | Voorbeeld QNAP-modellen |
|---|---|---|---|
| Intel Celeron, Pentium (Jasper Lake, Gemini Lake) | nee | SODIMM DDR4 | TS-464, TS-264, TS-664, TS-x53-serie |
| AMD Ryzen Embedded V1500B, V1000 | ja | SODIMM DDR4 | TS-873A, TS-473A, TS-1273AU |
| Intel Xeon E, W | ja | UDIMM DDR4 | TS-883XU, TS-983XU, TVS-h1688X |
| Intel Atom C3000, C5000 | ja | SODIMM, UDIMM DDR4 | entry-enterprise rackmounts |
| Intel Xeon D | ja | RDIMM DDR4 | ES2486dc |
| AMD EPYC | ja | RDIMM DDR4 | TS-h1290FX |
Op een platform zonder ECC (bijvoorbeeld een TS-464) kan geen enkele instelling ECC inschakelen. UDIMM's zijn ongebufferd (unbuffered); RDIMM's en LRDIMM's zijn geregistreerd (registered) en nemen belasting weg van de controller, zodat een kanaal meer modules met een grote capaciteit aankan.
Voorbeeld: de TS-464, "het werkt" is niet "ondersteund"
De TS-464 heeft een Intel Celeron N5095 of N5105 en twee SODIMM DDR4-sleuven, zonder ECC. Het officiële maximum is 16 GB (2 × 8 GB), de eigen limiet van de processor. In de praktijk start 2 × 16 GB (32 GB) op en toont het de volledige capaciteit, maar dit valt buiten de specificatie van Intel en QNAP. Een dergelijk geheugen kan de power-on test doorstaan en in rust (idle) goed functioneren, en pas falen onder een lange, zware belasting. Test een nieuwe configuratie daarom voordat je erop vertrouwt.
| Wat u mixt | Wat er gebeurt | Resultaat | Advies |
|---|---|---|---|
| Verschillende merken, verschillende kits | verschillende SPD-profielen, sub-timings, rank-organisatie en DRAM-chips; kits worden uitsluitend als één set gevalideerd | een terugval naar het basis-JEDEC-profiel, mogelijke instabiliteit onder belasting | één kit uit één doos |
| Verschillende snelheden | de controller stemt al het geheugen af op het traagste gedeelde profiel | al het geheugen vertraagt naar de langzaamste module (3200 + 2400 → 2400) | dezelfde snelheid, latentie en voltage |
| Verschillende capaciteiten (16 + 8 GB) | start meestal op met volledige capaciteit, maar volledige dual-channel is niet gegarandeerd | onzekere bandbreedte; sommige modellen met gepaarde sleuven starten niet op | een paar van dezelfde capaciteit |
| Drie modules in plaats van twee | verbreken de dual-channel symmetrie en belasten één kanaal | een deel van het geheugen draait single-channel; op AMD leidt dit tot een lagere gegarandeerde kloksnelheid | een even, gematcht aantal modules |
| ECC met non-ECC | een afwijkend woordformaat | het systeem schakelt ECC uit of start helemaal niet op | uitsluitend één type |
Kunnen drie modules langzamer zijn dan twee? Ja, met name op AMD. Een Ryzen-geheugencontroller verlaagt zijn gegarandeerde kloksnelheid naarmate het aantal modules en ranks per kanaal toeneemt: DDR4 3200 met één module per kanaal, 2933 met twee single-rank modules, 2666 met twee dual-rank modules. Meer modules bieden meer capaciteit maar minder bandbreedte; wanneer een taak geheugen tekortkomt, is meer capaciteit altijd nog beter dan dat het geheugen opraakt en er geswapt moet worden.
| App | Gevoelig voor | Waar op te letten |
|---|---|---|
| Virtualization Station | capaciteit en bandbreedte | de host behoudt zelf ongeveer 1,5–2 GB; bij geheugentekort gaat de host swappen en vertraagt elke VM tegelijkertijd |
| Container Station | capaciteit | zware stacks (Nextcloud, Immich, databases) hebben ongeveer 16 GB nodig |
| QuTS hero (ZFS, ARC) | capaciteit | minimaal 8 GB, 16 GB voor deduplicatie, 32 GB of meer aanbevolen; een hoog gebruik door de ARC is normaal, geen storing |
| QuMagie, Qsirch | capaciteit | indexeren kan veel geheugen in beslag nemen |
| Transcodering, iGPU | bandbreedte | dual-channel helpt de grafische prestaties; Quick Sync transcodering zelf trekt zich weinig aan van het aantal kanalen |
Best practice in het kort
- Een gematcht paar identieke modules: dezelfde capaciteit, snelheid, timings en rank-organisatie. Dat zorgt voor volledige dual-channel en stabiliteit.
- Bewaar de originele modules. Ga voordat je een supportticket aanmaakt terug naar de fabrieksmodules en controleer of het probleem aanhoudt.
- Test na een upgrade, vooral als je boven het officiële maximum gaat: eerst Quick, dan Deep of de USB-stick.
- Controleer de gedetecteerde capaciteit in de Resource Monitor: minder dan wat is geïnstalleerd wijst op een incompatibele of slecht geplaatste module.
- Een even aantal modules van dezelfde capaciteit. Sommige modellen starten niet op met een ongelijk paar.
- Meer kanalen is niet altijd sneller. Voor het serveren van bestanden bepalen het netwerk en de schijven de limiet; geïntegreerde grafische chips, VM's en ZFS merken het meest van dual-channel.