Eerst een stukje terminologie, omdat elk cijfer hieronder ervan afhangt. Microsoft telt de synchronisatielimiet in items — bestanden en mappen samen. Onze testbibliotheek had 997.392 items: 890.191 bestanden en 107.201 mappen. Waar dit artikel "een miljoen bestanden" zegt, bedoelt het items in de zin van Microsoft.

Het korte antwoord

  • 997.392items in de testbibliotheek op SharePoint
  • 52 mineerste synchronisatie vanaf nul
  • 351/secgemiddeld tempo, piek bij 590 items/sec
  • 3,6 GBpiek RAM-gebruik
  • 20,6 GBpiek vereiste schijfruimte
  • 5,9%van een verbinding van 99 Mbps gebruikt
  • 238 minlangste "zoeken naar wijzigingen" na opnieuw aanmelden
  • 44 van 45pogingen om een bestand te openen tijdens die fase mislukten door time-out

De vraag is niet langer of OneDrive een miljoen items kan synchroniseren. Dat kan. De vraag is hoe werkbaar die bibliotheek is zodra het synchroniseren klaar is.

De eerste synchronisatie was sneller dan we verwachtten, en niets op de machine bezweek: de CPU draaide op 2,1 van de 16 kernen, het netwerk op 5,9% van de verbinding, en de schijfwachtrij liep nooit vol. De problemen begonnen nadat we ons afmeldden bij Windows en opnieuw aanmeldden — wat elke gebruiker elke ochtend doet.

Elke bewering in dit artikel is gelabeld naar type:

Microsoft zegt — bevestigd door officiële documentatie.

Wij maten — een cijfer uit onze logs, ruwe CSV's bestaan.

Wij observeerden — wat er gebeurde, zonder verklaring waarom.

Onze interpretatie — onze conclusie, geen feit.

Openheid: wij bouwen OneMount, een tool die SharePoint-bibliotheken als Windows-schijf koppelt zonder te synchroniseren, dus we hebben een duidelijk belangenconflict. Daarom komen de cijfers en de methode eerst en het product pas na de conclusies. We konden geen gepubliceerde onafhankelijke benchmark van deze configuratie op een miljoen echte items vinden; als die bestaat, stuur hem op en we vergelijken de methodologie.

Ondersteunt OneDrive echt 1.000.000 bestanden?

Ja. Microsoft zegt: in openbare preview ondersteunt de OneDrive-synchronisatieclient tot 1.000.000 items per synchronisatie-instantie per apparaat (Microsoft-documentatie). Microsoft rolt de functie geleidelijk uit aan deelnemers van het Insider-programma.

Is de limiet van OneDrive 300.000 of 1.000.000 items?

Dit is het meest voorkomende verwarringspunt. Microsoft zegt: 300.000 items blijft de aanbeveling voor optimale prestaties. Het ene getal heeft het andere niet vervangen — beide gelden tegelijk en betekenen iets anders.

GetalWat het betekent
tot 300.000 itemsMicrosofts aanbeveling voor optimale prestaties. Het getal om rond te plannen.
tot 1.000.000 itemsDe bovengrens van ondersteuning in openbare preview — geen garantie van prestaties.

Vereisten voor Windows en hardware

Microsoft zegt — de vereisten voor de preview van 1.000.000 items:

  • Windows 11 of Windows Server 2022 en nieuwer;
  • minstens 16 GB RAM, 32 GB aanbevolen;
  • een SSD, geen HDD;
  • een processor van de klasse Intel Core i5 / AMD Ryzen 5 of beter;
  • de OneDrive-client met de optie voor previewbuilds ingeschakeld;
  • VDI wordt niet ondersteund.

Dat laatste punt is apart de aandacht waard: als uw omgeving op virtuele desktops draait, geldt de limiet van 1.000.000 items voor u nog niet. Dat is ook waarom onze test op een fysieke machine liep.

OneDrive-instellingen, tabblad Info, met de schakelaar voor het OneDrive Insider-programma
De previewschakelaar staat in OneDrive-instellingen → Info → OneDrive Insider-programma. De screenshot toont de status vóór het omzetten: build 26.163.0823.0004, de schakelaar uit. Na inschakelen en herstarten werkte de client bij naar 26.168.0830.0004 — de build waarop de hele test draaide.

Hoe we OneDrive testten met 1 miljoen bestanden

De testbibliotheek op SharePoint

De bibliotheek is echt en in dagelijks gebruik, niet gegenereerd: documenten, exports, scans en projectmappen die zich jarenlang hebben opgestapeld, met de lange namen en diepe nesting die bij zo'n corpus horen.

SharePoint-beheercentrum, tabblad Activiteit voor een site met 890.191 bestanden
SharePoint-beheercentrum: 890.191 bestanden, 1,38 TB van 1,50 TB gebruikt. Over 30 dagen werden 21.231 bestanden bekeken of bewerkt — ongeveer 2% van het corpus is actief in gebruik.

Wij maten: het exacte aantal items kwam uit de REST-API van de bibliotheek vóór de synchronisatie startte — 997.392. Twee groottecijfers komen niet overeen, en dat is te verwachten: het beheercentrum meldt 1,38 TB (alle siteopslag inclusief versiegeschiedenis en prullenbak), terwijl de eigen database van de synchronisatie-engine 995 GB logische grootte telde — de huidige versies van bestanden, wat daadwerkelijk synchroniseert.

De testmachine

CPUIntel Core i9-11900K, 8 kernen / 16 threads
Geheugen32 GB — de hoogste aanbeveling van Microsoft
SchijfNVMe-SSD met het gebruikersprofiel
OSWindows 11 Pro 25H2, build 26200.9457
OneDrive26.168.0830.0004, previewbuilds ingeschakeld
VerbindingBeoordeeld op 99/100 Mbps; vooraf gemeten op 98,57 / 99,63 Mbps, 2 ms ping
ProfielEen schoon, apart Windows-account
Systeeminformatie van Windows 11: Intel Core i9-11900K, 32 GB RAM
Een fysieke machine, geen VM: Core i9-11900K, 32 GB RAM, Windows 11 Pro 25H2 — een configuratie boven de aanbeveling van Microsoft, niet er net op.

We hebben zwakkere configuraties niet gemeten, dus elk cijfer hieronder geldt alleen voor deze bench. Onze verwachting dat een machine met minder geheugen en een tragere schijf slechter zou presteren, is een aanname, geen meting.

Hoe we maten

De bestandsboom doorlopen tijdens een synchronisatie is geen optie: het doorlopen zelf raakt de bestandsstatus en zou vervormen wat u juist probeert te meten. Dus deden we dat niet. Voortgang wordt rechtstreeks uitgelezen uit de database van de OneDrive-synchronisatie-engine (SyncEngineDatabase.db, SQLite) — live en alleen-lezen. Dat levert het aantal items, de verdeling cloud-only versus lokaal gedownload, de seconden aan serverzijdige beperking en de responscodes. Belastingcijfers komen uit CIM, waar eigenschapsnamen niet afhankelijk zijn van de weergavetaal van het besturingssysteem.

Een apart hydratatieonderzoek draait ernaast: het script probeert periodiek een klein cloud-only bestand uit de bibliotheek te openen met een harde time-out, legt het resultaat en de duur vast, en zet het bestand daarna terug naar zijn cloud-only staat. Die proef leverde de interessantste gegevens uit de hele test op.

Onze interpretatie: we gaan ervan uit dat de records in die database zijn waarop de limiet van 300.000 / 1.000.000 wordt toegepast — maar Microsoft publiceert zijn telmethode niet, dus dit is een aanname.

OneDrive-instellingen, tabblad Account, met de net gekoppelde bibliotheek
Het startpunt: de bibliotheek is net gekoppeld en leest nog steeds 0 KB. Het script draait al en schrijft zijn basislijnmoment — vandaar dat de resultaten een "voor" en een "na" hebben.

Hoe lang duurt het om 1.000.000 bestanden te synchroniseren?

52 minuten en 1.013.795 items

De klok start zodra het monitoren begint, met de bibliotheek nog niet gekoppeld. Synchroniseren werd vijf minuten later aangeklikt, en de itemteller begon 25 seconden daarna te bewegen. Het miljoenste item werd gepasseerd op 51,8 minuten, en de teller stopte met groeien bij 52,9.

Scriptconsole met de mijlpalen van 900.000 en 1.000.000 items en het OneDrive-systeemvakpictogram met de tekst Opgeslagen en gesynchroniseerd
Het miljoenste item: de console toont 900.000 items bij 46,3 min en 1.000.000 items bij 51,7 min, met de teller op 1.013.795. Het systeemvakpictogram toont Opgeslagen en gesynchroniseerd.
Items op het apparaat1.013.795 (905.313 bestanden + 108.482 mappen)
Toegevoegd tijdens deze run997.379 — de SharePoint-bibliotheek
Aanwezig vóór de start16.418 — de persoonlijke OneDrive van hetzelfde account
Cloud-only905.310 van 905.313 bestanden (99,9997%)
Lokaal gedownload3 bestanden

De client deed precies wat hij belooft: hij bouwde een volledige boom van bijna een miljoen items zonder inhoud te downloaden. Wat op de schijf terechtkwam waren plaatshouders, geen bestanden. Het verschil tussen de 997.379 toegevoegde en de referentie van 997.392 is 13 items — rekenkunde tussen twee tellingen op verschillende momenten op een levende bibliotheek, geen lijst van bestanden waar we naar op zoek waren.

Synchronisatiesnelheid van OneDrive

MijlpaalMin vanaf startTempo over het segment
100.0008,8—
300.00016,5402 items/sec
500.00023,1469 items/sec
700.00034,2297 items/sec
900.00046,3296 items/sec
1.000.00051,8297 items/sec

Wij maten: over de eerste twee segmenten hield de client 402 en 469 items/sec aan, waarna het tempo daalde naar 297 items/sec en daar bleef — 297,1, dan 296,5, dan 297,4. Dit is geen geleidelijke afname maar een stap naar een vlak plateau rond de helft. Het gemiddelde over de actieve fase was 351 items/sec, met een piek van 590.

Onze interpretatie: we kunnen de oorzaak niet noemen. Er was helemaal geen serverzijdige beperking — nul vensters, nul seconden, 1.156 serviceaanroepen en nul fouten. Netwerk, schijf en CPU waren in de tweede helft niet drukker dan in de eerste. Hoe vlak het plateau is, wijst op een vast plafond — grootte van aanvraagbatches, of het aantal parallelle streams — in plaats van een oplopende kostprijs.

Hoeveel RAM, CPU en schijf gebruikt OneDrive?

ResourceGemeten
RAM, piek3.579 MB
RAM na afronden2.790 MB
CPU, gemiddeld tijdens de actieve fase2,1 van 16 kernen (13,1%)
CPU, piek2,35 kernen (14,7%)
Netwerk, gedownloadongeveer 2 GB
Schijf, gelezen / geschreven69,3 GB / 79,3 GB
Schijfwachtrij, 95e percentiel1 (piek 4)
Database van de synchronisatie-engine2.036 MB uiteindelijk, 2.318 MB op piek
Schijfverbruik, uiteindelijk6,57 GB
Piek vereiste vrije ruimte20,62 GB
Servicebeperking0 vensters, 0 seconden

Een database van 2 GB. Wij maten: de engine besteedt ongeveer 2,1 KB van zijn eigen database per item. Die database staat in het gebruikersprofiel en wordt bij elke controle op wijzigingen gelezen en geschreven.

149 GB schijf-I/O voor 2 GB verkeer. Onze interpretatie: dat is ongeveer 75× schrijfversterking ten opzichte van wat via het netwerk kwam. Op NVMe merkt u er niets van; op een instap-SATA-SSD, of op een HDD, is dat een ander verhaal — precies waarom Microsoft een SSD als vereiste vermeldt.

20,62 GB op piek versus 6,57 GB in rust. Wij maten: vrije ruimte daalde van 253,93 GB naar 233,31 GB op het moment van 51,6 minuten. De tijdelijke vraag was 3,1× groter dan wat overbleef toen de run klaar was. Het praktische gevolg: een machine met ongeveer 10 GB vrij loopt midden in de synchronisatie vast zonder schijfruimte, zelfs als de eindtoestand ruim zou hebben gepast.

Heeft u snel internet nodig voor OneDrive-synchronisatie?

We draaiden de test specifiek hiervoor op een verbinding van 99 Mbps. Wij maten:

Gemiddelde downloadsnelheid5,87 Mbps — 5,9% van de verbinding
95e percentiel12,34 Mbps — 12,5% van de verbinding
Metingen bij ≥ 80% benutting0
Metingen in de actieve fase onder 0,1 Mbps45,1%
Pure overdrachtstijd voor al het verkeerongeveer 3 minuten

Voor bijna de helft van de actieve fase was het netwerk vrijwel stil, en alles wat de client downloadde zou deze verbinding in minder dan drie minuten oversteken — tegenover een run die 52 duurde.

In onze test was de verbinding niet de beperkende factor. Een snellere lijn zou deze run niet hebben verkort.

Onze interpretatie: de beperking is geen bandbreedte, maar de retourtijd naar de service en metadataverwerking. Een miljoen items betekent een miljoen records om op te halen, te verwerken en in een lokale database te schrijven, en een bredere pijp vermindert niet hoeveel van die bewerkingen er zijn.

Voor planning: als u al een stabiele 100 Mbps heeft, verdient het upgraden van de lijn om het synchroniseren te versnellen zichzelf niet terug — dat geld doet meer in RAM en NVMe. We hebben niet onder 100 Mbps gemeten.

Wat er gebeurt na de eerste synchronisatie

238 minuten vast op "Zoeken naar wijzigingen"

Met de synchronisatie klaar meldden we ons af bij Windows en opnieuw aan. Geen wijzigingen aan de bibliotheek, geen herstart.

Wij maten: het OneDrive-proces startte om 18:18:03, en "Opgeslagen en gesynchroniseerd" verscheen om 22:15:39.

14.255 seconden = 237,6 minuten = 3 uur 58 minuten — besteed aan het controleren van wijzigingen in een bibliotheek waar niets was veranderd. Dat is 4,6× langer dan de synchronisatie zelf.

Een belangrijk voorbehoud vooraf: die 238 minuten herhaalden zich niet. Drie volgende aanmeldcycli op dezelfde machine met dezelfde bibliotheek duurden 20,7–36,6 seconden, en elke poging om een bestand te openen tijdens die cycli slaagde — details in de sectie over herhaalde cycli hieronder.

Gedetailleerde belastingsmetingen dekken 116,9 van die 237,6 minuten — het monitoringscript was niet op de allereerste seconde gestart. De volledige duur wordt gemeten van het starten van het OneDrive-proces tot de statuswijziging; beide punten zijn betrouwbaar vastgelegd.

Serviceaanroepen14 — twee daarvan EnumChanges; nul fouten
Gedownloadongeveer 22 MB (een bovengrens voor de hele machine)
Schijf, OneDrive-proces0,50 GB gelezen / 0,17 GB geschreven
Database van de synchronisatie-engineonveranderd
Wijziging van het aantal itemsnul — geen enkel record
CPUgemiddeld 1,03 kernen, piek 1,79
RAMgroeide van 936 MB naar 2.501 MB

Wij maten: de itemteller bewoog geen enkele keer over de hele geobserveerde fase — 1.013.795 bij elke meting. Twee nieuwe items verschenen 33 seconden na de status "Opgeslagen en gesynchroniseerd". Van de 19 EnumChanges-aanroepen vielen er maar 2 binnen de fase; de andere 17 kwamen terecht in het kwartier erna.

Onze interpretatie: dit lijkt niet op het downloaden van gegevens, of zelfs op een actief gesprek met de service. Het lijkt op langdurig intern werk tegen de eigen status van de client — dezelfde database van 2 GB. We kunnen dit niet bevestigen: Microsoft publiceert niet wat de client in deze fase doet.

Wij observeerden: van buitenaf ziet de fase normaal uit. Het systeemvakpictogram toont "Zoeken naar wijzigingen" — hetzelfde wat het toont tijdens de vijf seconden durende controle na een gewone ochtendstart. We zagen geen voortgangsindicator, geen tijdschatting en geen waarschuwing. In de standaardinterface van de client vonden we niets dat onderscheid maakt tussen "wacht 20 seconden" en "wacht 4 uur."

Konden bestanden niet openen tijdens de controle

Dit is gemeten, niet geschat: het hydratatieonderzoek draaide de hele tijd.

WanneerPogingenMisluktAandeel
Tijdens de controle op wijzigingen454498%
Nadat de client zijn werkende status had bereikt900%

Wij maten: van 45 pogingen om een bestand te openen tijdens de fase slaagde één, en die duurde 49.342 ms — bijna 50 seconden voor een bestand van een paar honderd kilobyte. Zodra de client zijn werkende status had bereikt, duurden dezelfde proeven 305–645 ms.

OneDrive-fout 0x800701AA

Precisie telt hier. De geautomatiseerde proef breekt af na 60 seconden en registreert een timeout, wat betekent dat ze de aanroep afbreekt voordat Windows een foutcode teruggeeft. Wij observeerden: de code verscheen toen we handmatig een bestand openden aan het begin van dezelfde fase:

0x800701AA — De cloudbewerking is niet voltooid voordat de time-outperiode verliep.
OneDrive met de melding 1 onderbroken actie en foutcode 0x800701AA
Wat de gebruiker ziet: 1 onderbroken actie — De cloudbewerking is niet voltooid voordat de time-outperiode verliep. [Fout 0x800701AA] voor een bestand van 291 KB. Het systeemvakpictogram toont op dat moment Zoeken naar wijzigingen.

Wij observeerden: Excel reageerde hierop twee keer met "het bestandsformaat of de bestandsextensie is niet geldig" — de toepassing ontving een gedeeltelijke of lege stream en trok zelf de verkeerde conclusie. Onze interpretatie: zo ontstaan conflicterende kopieën en "beschadigde" documenten. De gebruiker ziet een formaatfout, slaat het bestand onder een andere naam op, en de keten gaat door zonder dat OneDrive er nog bij betrokken is.

Gebeurt dit bij elke herstart?

238 minuten tot een regel maken zou oneerlijk zijn. We draaiden een derde test — herstart- en aanmeldcycli op dezelfde machine met dezelfde bibliotheek. Vier runs werden vastgelegd; drie legden een volledige cyclus vast.

CyclusTriggerTot "Opgeslagen en gesynchroniseerd"
1Schone herstart36,6 s (129,6 s vanaf opstarten)
2Aanmelden, machine 11 uur aan20,7 s
3Aanmelden, 74 minuten na opstarten35,8 s

Wij maten: op consistente basis lag de spreiding tussen 20,7–36,6 seconden. Het hydratatieonderzoek draaide 12 keer met 12 successen, en zes van die proeven kwamen precies in de staat "Zoeken naar wijzigingen" terecht — allemaal succesvol, bij 707–2.572 ms. In rust hield het proces 1.507–2.187 MB geheugen vast: op een bibliotheek van een miljoen items is anderhalf tot twee gigabyte RAM permanent bezet.

Scriptlog met de status LookingForChanges en drie succesvolle hydratatieproeven
[11:20:31] status -> LookingForChanges met drie opeenvolgende succesvolle proeven (2.212, 707 en 1.062 ms). Dezelfde statusnaam als tijdens de fase van 238 minuten, en het tegenovergestelde gedrag.
De fase "Zoeken naar wijzigingen" blokkeert op zichzelf niets. Er zijn minstens twee modi die dezelfde naam in de interface delen: een korte, gemeten in seconden, waarin bestanden beschikbaar zijn, en een lange, gemeten in uren, waarin dat niet zo is. Niets in de standaardinterface onderscheidt ze.

Een voorbehoud: we kunnen niet stellen dat de client in die cycli evenveel werk verrichtte. De lange fase was de eerste aanmelding na de eerste synchronisatie; de drie daaropvolgende waren dat niet. We hebben niet gemeten hoe vaak het gebeurt.

Onze interpretatie: dat is precies wat het een operationeel probleem maakt. Een gebeurtenis die zeldzaam en onvoorspelbaar is, maar uren duurt en normaal oogt, is moeilijker te beheren dan een gewone fout — een fout verschijnt in monitoring, en dit niet.

Wat een miljoen bestanden betekent op honderden pc's

Onze interpretatie: alles in deze sectie is een conclusie getrokken uit ervaring met uitrol, geen gemeten cijfer.

Resources vermenigvuldigen met het aantal machines. 6,6 GB schijf in rust en tot 21 GB op piek — op elk apparaat. Een servicedatabase van 2 GB die bij elke controle op wijzigingen gelezen en geschreven moet worden. Een piek van 3,6 GB RAM: op machines met 8 GB concurreert dat al met de toepassingen waarin mensen werken, en het minimum van 16 GB van Microsoft is geen formaliteit.

Een zeldzame gebeurtenis stopt zeldzaam te zijn op grote schaal. We weten niet hoe vaak de pathologische fase voorkomt en zullen geen cijfer verzinnen, maar de rekenkunde van schaal is onmiskenbaar: op honderden machines stopt zelfs een zeldzaam, incidenteel probleem het probleem van één gebruiker te zijn — de omvang wordt bepaald door het aantal apparaten en hoe vaak dergelijke gebeurtenissen optreden.

Gebruikers wachten niet. De 52 minuten kwamen van een inactieve, ideale machine; op een werkende laptop concurreert elk geopend bestand en elke Excel-start met de synchronisatie om dezelfde schijf en CPU.

Een tweede apparaat betekent een tweede identieke run. De limiet wordt gedefinieerd per synchronisatie-instantie per apparaat: iemand met een laptop en een desktop doorloopt de hele cyclus twee keer.

Wat de test liet zien

Beter dan verwacht. De eerste synchronisatie van een miljoen items is snel, voorspelbaar en goedkoop in resources: 52 minuten, 2 GB verkeer, 2 van de 16 kernen, nul servicefouten, nul beperking. Als engineering is dat een serieus resultaat.

Wat in onze test een probleem werd. Na de eerste synchronisatie besteedde de client 238 minuten aan "Zoeken naar wijzigingen," en 44 van de 45 pogingen om een bestand te openen mislukten door time-out. Drie volgende aanmeldcycli reproduceerden dat gedrag niet.

Praktische richtlijnen:

  • Tot 300.000 items — OneDrive-synchronisatie blijft een verstandige keuze, en onze gegevens weerspreken de aanbeveling van Microsoft niet.
  • Tussen 300.000 en 1.000.000 — het zal werken, maar alleen op machines die aan de previewvereisten voldoen, en met het besef dat u zich in "ondersteund" gebied bevindt, niet "aanbevolen".
  • Een vloot van honderden machines — begroot voor de kosten van de stabiele toestand, niet voor de duur van de eerste synchronisatie.
  • VDI — de limiet van 1.000.000 items geldt voor u niet.

Moet u werken met een grote SharePoint-bibliotheek zonder die lokaal te synchroniseren?

OneMount koppelt SharePoint en OneDrive als Windows-schijf: bestanden blijven in de cloud en mensen werken ermee in de Verkenner — zonder eerste synchronisatie van een grote bibliotheek en zonder lokale index van een miljoen items.

OneMount proberen →

Hoe u met een grote SharePoint-bibliotheek werkt

Splits de bibliotheek

Breek het corpus op in meerdere bibliotheken of sites, zodat elk apparaat minder dan 300.000 items synchroniseert. Het werkt, maar het vereist herstructurering, mensen opnieuw trainen en het breekt bestaande links — vaak duurder organisatorisch dan technisch.

Selectieve synchronisatie

"Mappen kiezen" voorkomt dat u de hele boom binnenhaalt. Maar de limiet telt wat u heeft geselecteerd, gebruikers vinken na een tijdje meer aan dan nodig, en het bespaart u de fase van controleren op wijzigingen niet voor wat wel synchroniseert.

Houd mensen in de browser

De veiligste optie vanuit het oogpunt van de client en de slechtste vanuit de gewoonte: waar mensen al jaren met een schijfletter werken, stuit teruggaan naar een webinterface op weerstand, en een deel van het team vindt workarounds.

Koppel SharePoint als schijf zonder te synchroniseren

Dit is de richting die wij hebben gekozen — en hier herhalen we de openheid over het belangenconflict: wij bouwen OneMount, dus we zijn geen neutrale partij.

De logica is simpel. Elk cijfer in dit artikel — 52 minuten, een database van 2 GB, 149 GB schijf-I/O, 238 minuten controleren — is de prijs van het onderhouden van een lokale kopie van de status van een miljoen items. Zonder die kopie verdwijnt de prijs: er is niets te verifiëren na aanmelden, geen database die lineair meegroeit met het aantal items, geen piek van 21 GB op de systeemschijf. In ruil neemt u andere compromissen op u: een verbinding is vereist, en hoe snel een document opent hangt af van de lijn in plaats van de lokale schijf.

Onze interpretatie: voor bibliotheken waar het grootste deel van het corpus archief is dat zelden wordt aangeraakt — in onze testbibliotheek werd ongeveer 2% van de bestanden in 30 dagen aangeraakt — lijkt het bijhouden van een volledige lokale index van een miljoen items op elk apparaat een hoge prijs voor een klein voordeel. Maar dat is onze beoordeling, en uw gebruiksprofiel kan anders zijn.

We zijn van plan dezelfde bibliotheek via dezelfde methode door OneMount te laten lopen en de cijfers naast elkaar te publiceren — inclusief de plekken waar we verliezen.

Veelgestelde vragen: OneDrive en 1.000.000 bestanden

Hoeveel bestanden kan OneDrive synchroniseren?

Tot 1.000.000 items per synchronisatie-instantie per apparaat in openbare preview, mits aan de vereisten wordt voldaan. De limiet telt items, dus bestanden en mappen samen.

Is de limiet van OneDrive 300.000 of 1.000.000 bestanden?

Beide. 300.000 is Microsofts aanbeveling voor optimale prestaties, en 1.000.000 is de bovengrens van ondersteuning in openbare preview. Het ene heeft het andere niet vervangen.

Hoe lang duurt het om 1 miljoen bestanden te synchroniseren?

In onze test 52 minuten voor 997.392 items op een machine met een Core i9, 32 GB RAM, een NVMe-SSD en een verbinding van 99 Mbps. Het gemiddelde tempo over de actieve fase was 351 items/sec. Op een zwakkere machine, of met andere taken op de achtergrond, duurt het langer.

Kan OneDrive 1 miljoen bestanden synchroniseren op Windows 11?

In openbare preview ondersteunt Microsoft tot 1.000.000 items per synchronisatie-instantie, mits aan de vereisten voor Windows, RAM, SSD en de OneDrive-client wordt voldaan. In onze test synchroniseerde Windows 11 Pro 25H2 met 32 GB RAM en een NVMe-SSD 997.392 items in ongeveer 52 minuten.

Waarom blijft OneDrive hangen op "Zoeken naar wijzigingen"?

We registreerden twee modi die dezelfde naam in de interface delen: een korte (20,7–36,6 seconden, bestanden beschikbaar) en een lange (238 minuten, waarbij 44 van de 45 pogingen om een bestand te openen mislukten door time-out). We hebben niet vastgesteld wat de omschakeling veroorzaakt, en niets in de standaardinterface onderscheidt de twee.

Waarom is OneDrive traag bij het synchroniseren van een grote bibliotheek?

Volgens onze metingen is de beperkende factor niet het netwerk of de schijf, maar de retourtijd naar de service en metadataverwerking. Opvallend is dat het tempo alleen in de eerste helft van de bibliotheek op 402–469 items/sec blijft, en daarna daalt naar een stabiele 297.

Hoeveel RAM gebruikt OneDrive?

De piek tijdens de eerste synchronisatie was 3.579 MB. In rust, zonder dat er iets gebeurde, hield het proces 1.507–2.187 MB vast. Tijdens de lange fase van controleren op wijzigingen groeide het gebruik van 936 MB naar 2.501 MB over twee uur observatie.

Hoeveel schijfruimte kost het synchroniseren van een miljoen items?

6,57 GB in rust met alle bestanden cloud-only, met een piek van 20,62 GB tijdens de run. Daarvan is 2.036 MB de eigen database van de synchronisatie-engine — ongeveer 2,1 KB per item.

Heeft u snel internet nodig voor OneDrive-synchronisatie?

Volgens onze metingen, nee — niet als u al ongeveer 100 Mbps heeft. OneDrive gebruikte gemiddeld 5,9% van de verbinding en kwam nooit dicht bij volledige benutting.

Wat is OneDrive-fout 0x800701AA?

"De cloudbewerking is niet voltooid voordat de time-outperiode verliep" — het verzoek om de inhoud van een cloudbestand te downloaden was niet binnen de toegestane tijd klaar. In onze test zagen we deze code tijdens de lange fase van controleren op wijzigingen; daarbuiten mislukte geen poging om een bestand te openen.

Ondersteunt OneDrive 1 miljoen bestanden op VDI?

Nee. Microsoft stelt uitdrukkelijk dat VDI niet wordt ondersteund in deze preview.

Hoe werkt u met een grote SharePoint-bibliotheek zonder te synchroniseren?

Er zijn vier opties: de bibliotheek splitsen, selectief synchroniseren, mensen in de browser houden, of de bibliotheek als Windows-schijf koppelen zonder lokale kopie van de status. De laatste optie verwijdert elke kost die in dit artikel is gemeten maar vereist een permanente verbinding — meer details in hoe u met een grote SharePoint-bibliotheek werkt.


Voor de praktische kant — hoe u SharePoint koppelt aan een schijfletter, welke methoden er bestaan en welke daarvan standhouden onder belasting: SharePoint koppelen als netwerkschijf in Windows →

Heeft u deze weg al afgelegd en herkent u de symptomen — ons verhaal over het jaar dat we vochten tegen synchronisatie op een terabyte-bibliotheek →


Bronnen

Reproduceerbaarheid. Elk cijfer hier komt uit ons eigen meetscript, dat de database van de OneDrive-synchronisatie-engine live en alleen-lezend uitleest en belastingcijfers via CIM verzamelt. Het script, het testprotocol en de ruwe CSV's worden voorbereid voor publicatie — schrijf ons als u de test op uw eigen bibliotheek wilt herhalen.