Najpierw jedna kwestia terminologiczna, bo zależy od niej każda liczba poniżej. Microsoft liczy limit synchronizacji w elementach — pliki i foldery razem. Nasza testowa biblioteka zawierała 997 392 elementy: 890 191 plików i 107 201 folderów. Tam, gdzie ten artykuł mówi „milion plików", ma na myśli elementy w rozumieniu Microsoftu.
Krótka odpowiedź
- 997 392elementy w testowej bibliotece SharePoint
- 52 minpierwsza synchronizacja od zera
- 351/sek.średnie tempo, ze szczytem 590 elementów/sek.
- 3,6 GBszczytowe zużycie RAM
- 20,6 GBszczytowe wymagane miejsce na dysku
- 5,9%wykorzystania łącza 99 Mb/s
- 238 minnajdłuższe „Wyszukiwanie zmian" po ponownym zalogowaniu
- 44 z 45prób otwarcia pliku w tej fazie przekroczyło limit czasu
Pytanie już nie brzmi, czy OneDrive potrafi zsynchronizować milion elementów. Potrafi. Pytanie brzmi, jak funkcjonalna jest ta biblioteka, gdy synchronizacja jest skończona.
Pierwsza synchronizacja była szybsza, niż się spodziewaliśmy, i nic na maszynie się nie ugięło: CPU pracował na 2,1 rdzenia z 16, sieć na 5,9% łącza, a kolejka dysku nigdy się nie spiętrzyła. Problemy zaczęły się po tym, jak wylogowaliśmy się z Windows i zalogowaliśmy ponownie — to, co robi każdy użytkownik każdego ranka.
Każde twierdzenie w tym artykule jest oznaczone typem:
Microsoft mówi — potwierdzone oficjalną dokumentacją.
Zmierzyliśmy — liczba z naszych logów, surowe pliki CSV istnieją.
Zaobserwowaliśmy — co się stało, bez wyjaśnienia dlaczego.
Nasza interpretacja — nasz wniosek, nie fakt.
Ujawnienie: budujemy OneMount, narzędzie, które montuje biblioteki SharePoint jako dysk Windows bez synchronizacji, więc mamy oczywisty konflikt interesów. Dlatego liczby i metoda są na pierwszym miejscu, a produkt dopiero po wnioskach. Nie znaleźliśmy opublikowanego niezależnego benchmarku tej konfiguracji na milionie prawdziwych elementów; jeśli taki istnieje, prześlijcie go nam, a porównamy metodologię.
Czy OneDrive naprawdę obsługuje 1 000 000 plików?
Tak. Microsoft mówi: w wersji zapoznawczej klient synchronizacji OneDrive obsługuje do 1 000 000 elementów na instancję synchronizacji na urządzenie (dokumentacja Microsoft). Microsoft wdraża tę funkcję stopniowo wśród uczestników programu Insider.
Czy limit OneDrive to 300 000 czy 1 000 000 plików?
To najczęstsze źródło nieporozumień. Microsoft mówi: 300 000 elementów wciąż jest zaleceniem dla optymalnej wydajności. Jedna liczba nie zastąpiła drugiej — obie obowiązują naraz i znaczą coś innego.
| Liczba | Co oznacza |
|---|---|
| do 300 000 elementów | Zalecenie Microsoftu dla optymalnej wydajności. Liczba, wokół której warto planować. |
| do 1 000 000 elementów | Górna granica wsparcia w wersji zapoznawczej — nie gwarancja wydajności. |
Wymagania dotyczące Windows i sprzętu
Microsoft mówi — wymagania dla wersji zapoznawczej na 1 000 000 elementów:
- Windows 11 lub Windows Server 2022 i nowsze;
- co najmniej 16 GB RAM, zalecane 32 GB;
- SSD, nie HDD;
- procesor klasy Intel Core i5 / AMD Ryzen 5 lub lepszy;
- klient OneDrive z włączoną opcją kompilacji zapoznawczych;
- VDI nie jest obsługiwane.
Ten ostatni punkt zasługuje na osobną uwagę: jeśli Twoja infrastruktura działa na wirtualnych pulpitach, limit 1 000 000 elementów jeszcze Cię nie dotyczy. Dlatego też nasz test przeprowadzono na fizycznej maszynie.
Jak testowaliśmy OneDrive z 1 milionem plików
Testowa biblioteka SharePoint
Biblioteka jest prawdziwa i używana na co dzień, nie wygenerowana: dokumenty, eksporty, skany i foldery projektowe zgromadzone przez lata, z długimi nazwami i głębokim zagnieżdżeniem, które towarzyszą takiemu korpusowi.
Zmierzyliśmy: dokładna liczba elementów pochodziła z REST API biblioteki przed rozpoczęciem synchronizacji — 997 392. Dwie liczby rozmiaru się nie zgadzają, i to oczekiwane: centrum administracyjne raportuje 1,38 TB (całe miejsce witryny włącznie z historią wersji i koszem), podczas gdy własna baza silnika synchronizacji policzyła 995 GB rozmiaru logicznego — bieżące wersje plików, czyli to, co faktycznie się synchronizuje.
Maszyna testowa
| CPU | Intel Core i9-11900K, 8 rdzeni / 16 wątków |
|---|---|
| Pamięć | 32 GB — górne zalecenie Microsoftu |
| Dysk | Dysk NVMe SSD zawierający profil użytkownika |
| System | Windows 11 Pro 25H2, kompilacja 26200.9457 |
| OneDrive | 26.168.0830.0004, kompilacje zapoznawcze włączone |
| Połączenie | Nominalnie 99/100 Mb/s; zmierzone przed przebiegiem: 98,57 / 99,63 Mb/s, ping 2 ms |
| Profil | Czyste, osobne konto Windows |
Nie mierzyliśmy słabszych konfiguracji, więc każda liczba poniżej dotyczy tylko tego testu. Nasze oczekiwanie, że maszyna z mniejszą pamięcią i wolniejszym dyskiem wypadnie gorzej, jest założeniem, nie pomiarem.
Jak mierzyliśmy
Przechodzenie po drzewie plików podczas synchronizacji nie wchodzi w grę: samo przechodzenie
dotyka stanu pliku i zniekształciłoby to, co próbuje się zmierzyć. Więc tego nie robiliśmy. Postęp
jest odczytywany bezpośrednio z bazy danych silnika synchronizacji OneDrive
(SyncEngineDatabase.db, SQLite) — na żywo i tylko do odczytu. To daje liczbę
elementów, podział na pliki tylko-w-chmurze i pobrane lokalnie, sekundy tłumienia po stronie usługi
oraz kody odpowiedzi. Dane o obciążeniu pochodzą z CIM, gdzie nazwy właściwości nie zależą od
języka wyświetlania systemu.
Równolegle działa osobna sonda hydratacji: skrypt okresowo próbuje otworzyć mały plik tylko-w-chmurze z biblioteki z twardym limitem czasu, zapisuje wynik i czas trwania, po czym zwraca plik do stanu tylko-w-chmurze. Ta sonda dostarczyła najciekawszych danych w całym teście.
Nasza interpretacja: zakładamy, że to właśnie do rekordów w tej bazie danych stosuje się limit 300 000 / 1 000 000, ale Microsoft nie publikuje swojej metody liczenia, więc to założenie.
Ile czasu zajmuje synchronizacja 1 000 000 plików?
52 minuty i 1 013 795 elementów
Zegar startuje, gdy rozpoczyna się monitorowanie, a biblioteka jeszcze nie jest podłączona. Synchronizację kliknięto po pięciu minutach, a licznik elementów zaczął się poruszać 25 sekund później. Milionowy element minął w 51,8 minuty, a licznik przestał rosnąć przy 52,9.
900 000 elementów w 46,3 min i
1 000 000 elementów w 51,7 min, z licznikiem na 1 013 795. Ikona w zasobniku pokazuje
Utworzono kopię zapasową i zsynchronizowano.
| Elementy na urządzeniu | 1 013 795 (905 313 plików + 108 482 foldery) |
|---|---|
| Dodane w tym przebiegu | 997 379 — biblioteka SharePoint |
| Obecne przed startem | 16 418 — osobisty OneDrive tego samego konta |
| Tylko w chmurze | 905 310 z 905 313 plików (99,9997%) |
| Pobrane lokalnie | 3 pliki |
Klient zrobił dokładnie to, co obiecuje: zbudował pełne drzewo niemal miliona elementów bez pobierania treści. Na dysku wylądowały placeholdery, nie pliki. Różnica między 997 379 dodanymi a referencyjnymi 997 392 to 13 elementów — arytmetyka dwóch liczeń wykonanych w różnych momentach na żywej bibliotece, nie lista plików, których szukaliśmy.
Szybkość synchronizacji OneDrive
| Kamień milowy | Min od startu | Tempo w segmencie |
|---|---|---|
| 100 000 | 8,8 | — |
| 300 000 | 16,5 | 402 elementy/sek. |
| 500 000 | 23,1 | 469 elementów/sek. |
| 700 000 | 34,2 | 297 elementów/sek. |
| 900 000 | 46,3 | 296 elementów/sek. |
| 1 000 000 | 51,8 | 297 elementów/sek. |
Zmierzyliśmy: przez pierwsze dwa segmenty klient utrzymywał 402 i 469 elementów/sek., potem tempo spadło do 297 elementów/sek. i tam zostało — 297,1, potem 296,5, potem 297,4. To nie stopniowa degradacja, a skokowe przejście na płaskie plateau mniej więcej w połowie. Średnia w fazie aktywnej wyniosła 351 elementów/sek., ze szczytem 590.
Nasza interpretacja: nie potrafimy nazwać przyczyny. Nie było żadnego tłumienia po stronie usługi — zero okien, zero sekund, 1156 wywołań usługi i zero błędów. Sieć, dysk i CPU nie były bardziej obciążone w drugiej połowie niż w pierwszej. To, jak płaskie jest plateau, wskazuje na stały sufit — rozmiar wsadu żądań albo liczbę równoległych strumieni — a nie na narastający koszt.
Ile RAM-u, CPU i dysku zużywa OneDrive?
| Zasób | Zmierzono |
|---|---|
| RAM, szczyt | 3579 MB |
| RAM po zakończeniu | 2790 MB |
| CPU, średnia w fazie aktywnej | 2,1 z 16 rdzeni (13,1%) |
| CPU, szczyt | 2,35 rdzenia (14,7%) |
| Sieć, pobrane | ok. 2 GB |
| Dysk, odczyt / zapis | 69,3 GB / 79,3 GB |
| Kolejka dysku, 95. percentyl | 1 (szczyt 4) |
| Baza silnika synchronizacji | 2036 MB na koniec, 2318 MB w szczycie |
| Zużyte miejsce na dysku, na koniec | 6,57 GB |
| Szczytowe wymagane wolne miejsce | 20,62 GB |
| Tłumienie usługi | 0 okien, 0 sekund |
Baza danych na 2 GB. Zmierzyliśmy: silnik zużywa mniej więcej 2,1 KB własnej bazy danych na element. Ta baza siedzi w profilu użytkownika i jest odczytywana oraz zapisywana przy każdym sprawdzaniu zmian.
149 GB operacji dyskowych na 2 GB ruchu. Nasza interpretacja: to mniej więcej 75-krotne wzmocnienie zapisu względem tego, co przyszło z sieci. Na NVMe przechodzi niezauważone; na podstawowym SSD SATA, albo na HDD, to zupełnie inna historia — dokładnie dlatego Microsoft wymienia SSD jako wymaganie.
20,62 GB w szczycie wobec 6,57 GB w spoczynku. Zmierzyliśmy: wolne miejsce spadło z 253,93 GB do 233,31 GB w 51,6 minucie. Chwilowe zapotrzebowanie było 3,1 razy większe niż to, co zostało, gdy przebieg się skończył. Praktyczna konsekwencja: maszyna z około 10 GB wolnego miejsca zabraknie dysku w połowie synchronizacji, mimo że stan końcowy zmieściłby się bez problemu.
Czy do synchronizacji OneDrive potrzebny jest szybki internet?
Przeprowadziliśmy test na łączu 99 Mb/s właśnie po to, by na to odpowiedzieć. Zmierzyliśmy:
| Średnia prędkość pobierania | 5,87 Mb/s — 5,9% łącza |
|---|---|
| 95. percentyl | 12,34 Mb/s — 12,5% łącza |
| Próbki z wykorzystaniem łącza ≥ 80% | 0 |
| Próbki fazy aktywnej poniżej 0,1 Mb/s | 45,1% |
| Czysty czas transferu całego ruchu | ok. 3 minuty |
Przez niemal połowę fazy aktywnej sieć była praktycznie cicha, a wszystko, co klient pobrał, przeszłoby przez to łącze w niecałe trzy minuty — wobec przebiegu, który zajął 52.
W naszym teście połączenie nie było wąskim gardłem. Szybsze łącze nie skróciłoby tego przebiegu.
Nasza interpretacja: ograniczeniem nie jest pasmo, lecz opóźnienie komunikacji z usługą i przetwarzanie metadanych. Milion elementów to milion rekordów do pobrania, przetworzenia i zapisania w lokalnej bazie, a szersze łącze nie zmniejsza liczby tych operacji.
Do planowania: jeśli masz już stabilne 100 Mb/s, podniesienie prędkości łącza, by przyspieszyć synchronizację, się nie zwróci — te pieniądze więcej dają w RAM-ie i NVMe. Nie mierzyliśmy poniżej 100 Mb/s.
Co dzieje się po pierwszej synchronizacji
238 minut utknięte na „Wyszukiwaniu zmian"
Po zakończeniu synchronizacji wylogowaliśmy się z Windows i zalogowaliśmy ponownie. Żadnych zmian w bibliotece, żadnego restartu.
Zmierzyliśmy: proces OneDrive wystartował o 18:18:03, a „Utworzono kopię zapasową i zsynchronizowano" pojawiło się o 22:15:39.
14 255 sekund = 237,6 minuty = 3 godziny 58 minut — spędzone na sprawdzaniu zmian w bibliotece, w której nic się nie zmieniło. To 4,6 razy dłużej niż sama synchronizacja.
Ważne zastrzeżenie na początek: te 238 minut się nie powtórzyło. Trzy kolejne cykle logowania na tej samej maszynie z tą samą biblioteką zajęły 20,7–36,6 sekundy, a każda sonda otwarcia pliku podczas nich się powiodła — szczegóły w sekcji o powtarzanych cyklach poniżej.
Szczegółowe pomiary obciążenia obejmują 116,9 z tych 237,6 minut — skrypt monitorujący nie wystartował w samej pierwszej sekundzie. Pełny czas trwania jest mierzony od startu procesu OneDrive do zmiany statusu; oba punkty są zapisane rzetelnie.
| Wywołania usługi | 14 — dwa z nich to EnumChanges; zero błędów |
|---|---|
| Pobrane | ok. 22 MB (górna granica dla całej maszyny) |
| Dysk, proces OneDrive | 0,50 GB odczyt / 0,17 GB zapis |
| Baza silnika synchronizacji | bez zmian |
| Zmiana liczby elementów | zero — ani jednego rekordu |
| CPU | średnio 1,03 rdzenia, szczyt 1,79 |
| RAM | wzrósł z 936 MB do 2501 MB |
Zmierzyliśmy: licznik elementów ani razu się nie poruszył przez całą obserwowaną fazę — 1 013 795 w każdej próbce. Dwa nowe elementy pojawiły się 33 sekundy po pojawieniu się statusu „Utworzono kopię zapasową i zsynchronizowano". Z 19 wywołań EnumChanges tylko 2 przypadły na tę fazę; pozostałe 17 wylądowały w kwadransie po jej zakończeniu.
Nasza interpretacja: to nie wygląda na pobieranie danych, ani nawet na aktywną rozmowę z usługą. Wygląda na długą pracę wewnętrzną na własnym stanie klienta — tej samej bazie na 2 GB. Nie możemy tego potwierdzić: Microsoft nie publikuje, co klient robi w tej fazie.
Zaobserwowaliśmy: z zewnątrz faza wygląda normalnie. Ikona w zasobniku pokazuje „Wyszukiwanie zmian" — to samo, co pokazuje podczas pięciosekundowego sprawdzenia po zwykłym porannym uruchomieniu. Nie widzieliśmy żadnego wskaźnika postępu, żadnego szacunkowego czasu ani ostrzeżenia. W standardowym interfejsie klienta nie znaleźliśmy niczego, co odróżniałoby „poczekaj 20 sekund" od „poczekaj 4 godziny".
Pliki nie chciały się otworzyć podczas sprawdzania
To zmierzone, nie na oko: sonda hydratacji działała przez cały ten czas.
| Kiedy | Próby | Nieudane | Udział |
|---|---|---|---|
| Podczas sprawdzania zmian | 45 | 44 | 98% |
| Gdy klient osiągnął stan roboczy | 9 | 0 | 0% |
Zmierzyliśmy: z 45 prób otwarcia pliku podczas tej fazy, jedna się powiodła, i zajęła 49 342 ms — niemal 50 sekund dla pliku liczącego kilkaset kilobajtów. Gdy klient osiągnął stan roboczy, te same sondy zajmowały 305–645 ms.
Błąd OneDrive 0x800701AA
Tutaj liczy się precyzja. Automatyczna sonda przerywa po 60 sekundach i zapisuje
timeout, co oznacza, że zabija wywołanie, zanim Windows zwróci kod błędu.
Zaobserwowaliśmy: kod pojawił się, gdy otworzyliśmy plik ręcznie
na początku tej samej fazy:
0x800701AA — Operacja w chmurze nie została ukończona przed upływem limitu
czasu.
Zaobserwowaliśmy: Excel zareagował na to dwukrotnie komunikatem „format pliku lub rozszerzenie pliku jest nieprawidłowe" — aplikacja dostała częściowy albo pusty strumień i wyciągnęła własny, błędny wniosek. Nasza interpretacja: tak właśnie rodzą się skonfliktowane kopie i „uszkodzone" dokumenty. Użytkownik widzi błąd formatu, zapisuje plik pod inną nazwą, a łańcuch ciągnie się dalej bez udziału OneDrive.
Czy to zdarza się po każdym restarcie?
Zamienienie 238 minut w regułę byłoby nieuczciwe. Przeprowadziliśmy trzeci test — cykle restartu i logowania na tej samej maszynie z tą samą biblioteką. Zapisano cztery przebiegi; trzy uchwyciły pełny cykl.
| Cykl | Wyzwalacz | Do „Utworzono kopię zapasową i zsynchronizowano" |
|---|---|---|
| 1 | Czysty restart | 36,6 s (129,6 s od rozruchu) |
| 2 | Logowanie, maszyna włączona 11 godzin | 20,7 s |
| 3 | Logowanie, 74 minuty po rozruchu | 35,8 s |
Zmierzyliśmy: na stałej podstawie rozrzut wyniósł 20,7–36,6 sekundy. Sonda hydratacji działała 12 razy z 12 sukcesami, a sześć z tych sond wylądowało dokładnie w stanie „Wyszukiwanie zmian" — wszystkie udane, w 707–2572 ms. W spoczynku proces zajmował 1507–2187 MB pamięci: na bibliotece z milionem elementów, od półtora do dwóch gigabajtów RAM jest zajętych na stałe.
[11:20:31] state -> LookingForChanges z trzema kolejnymi udanymi sondami (2212,
707 i 1062 ms). Ta sama nazwa stanu co w 238-minutowej fazie, i przeciwne zachowanie.
Zastrzeżenie: nie możemy twierdzić, że klient wykonywał tę samą ilość pracy w tych cyklach. Długa faza była pierwszym logowaniem po pierwszej synchronizacji; trzy kolejne już nie były. Nie mierzyliśmy, jak często to się zdarza.
Nasza interpretacja: to właśnie czyni to problemem operacyjnym. Zdarzenie, które jest rzadkie i nieprzewidywalne, a mimo to trwa godzinami i wygląda normalnie, jest trudniejsze do zarządzania niż jawny błąd — błąd pojawia się w monitoringu, a to nie.
Co milion plików oznacza na setkach komputerów
Nasza interpretacja: wszystko w tej sekcji to wniosek wyciągnięty z doświadczenia wdrożeniowego, nie zmierzona liczba.
Zasoby mnożą się przez liczbę maszyn. 6,6 GB dysku w spoczynku i do 21 GB w szczycie — na każdym urządzeniu. Baza usługi na 2 GB, którą trzeba odczytywać i zapisywać przy każdym sprawdzaniu zmian. Szczyt RAM na 3,6 GB: na maszynach z 8 GB to już konkuruje z aplikacjami, w których ludzie pracują, a minimum 16 GB od Microsoftu nie jest formalnością.
Rzadkie zdarzenie przestaje być rzadkie na dużej flocie. Nie wiemy, jak często występuje patologiczna faza, i nie wymyślimy liczby, ale arytmetyka skali jest jednoznaczna: na setkach maszyn nawet rzadki, sporadyczny problem przestaje być problemem jednego użytkownika — jego skalę wyznacza liczba urządzeń i częstotliwość takich zdarzeń.
Użytkownicy nie czekają. 52 minuty pochodziły z bezczynnej, idealnej maszyny; na roboczym laptopie każdy otwarty plik i każde uruchomienie Excela konkuruje z synchronizacją o ten sam dysk i CPU.
Drugie urządzenie to drugi identyczny przebieg. Limit jest zdefiniowany na instancję synchronizacji na urządzenie: ktoś z laptopem i komputerem stacjonarnym przechodzi przez cały cykl dwa razy.
Co pokazał test
Lepiej, niż się spodziewano. Pierwsza synchronizacja miliona elementów jest szybka, przewidywalna i tania w zasobach: 52 minuty, 2 GB ruchu, 2 rdzenie z 16, zero błędów usługi, zero tłumienia. Jako inżynieria, to poważny wynik.
Co stało się problemem w naszym teście. Po pierwszej synchronizacji klient spędził 238 minut na „Wyszukiwaniu zmian", a 44 z 45 prób otwarcia pliku przekroczyło limit czasu. Trzy kolejne cykle logowania nie powtórzyły tego zachowania.
Praktyczne wskazówki:
- Do 300 000 elementów — synchronizacja OneDrive pozostaje sensownym wyborem, a nasze dane nie przeczą zaleceniu Microsoftu.
- Między 300 000 a 1 000 000 — zadziała, ale tylko na maszynach spełniających wymagania wersji zapoznawczej, i ze świadomością, że jesteś w terytorium „obsługiwane", nie „zalecane".
- Flota setek maszyn — budżetuj koszt utrzymania stanu ustabilizowanego, nie czasu pierwszej synchronizacji.
- VDI — limit 1 000 000 elementów Cię nie dotyczy.
Musisz pracować z dużą biblioteką SharePoint bez synchronizowania jej lokalnie?
OneMount montuje SharePoint i OneDrive jako dysk Windows: pliki zostają w chmurze, a ludzie pracują z nimi w Eksploratorze plików — bez pierwszej synchronizacji dużej biblioteki i bez lokalnego indeksu miliona elementów.
Wypróbuj OneMount →Jak pracować z dużą biblioteką SharePoint
Podziel bibliotekę
Rozbij korpus na kilka bibliotek lub witryn, tak by każde urządzenie synchronizowało mniej niż 300 000 elementów. Działa, ale wymaga restrukturyzacji, przeuczenia ludzi i psuje istniejące linki — często droższe organizacyjnie niż technicznie.
Synchronizacja selektywna
„Wybierz foldery" pozwala uniknąć pobierania całego drzewa. Ale limit liczy to, co zaznaczono, użytkownicy w końcu zaznaczają więcej niż potrzebują, a to nie oszczędza fazy sprawdzania zmian na tym, co się synchronizuje.
Trzymaj ludzi w przeglądarce
Najbezpieczniejsza opcja z punktu widzenia klienta i najgorsza z punktu widzenia nawyku: tam, gdzie ludzie od lat pracowali z literą dysku, powrót do interfejsu webowego spotyka się z oporem, a część zespołu znajdzie obejścia.
Zamontuj SharePoint jako dysk bez synchronizacji
To kierunek, który obraliśmy — i tu powtarzamy ujawnienie konfliktu interesów: budujemy OneMount, więc nie jesteśmy stroną neutralną.
Logika jest prosta. Każda liczba w tym artykule — 52 minuty, baza na 2 GB, 149 GB operacji dyskowych, 238 minut sprawdzania — to koszt utrzymywania lokalnej kopii stanu miliona elementów. Bez tej kopii koszt znika: nie ma czego weryfikować po zalogowaniu, nie ma bazy rosnącej liniowo z liczbą elementów, nie ma szczytu 21 GB na dysku systemowym. W zamian przyjmujesz inne kompromisy: wymagane jest połączenie, a szybkość otwierania dokumentu zależy od łącza, nie od lokalnego dysku.
Nasza interpretacja: dla bibliotek, gdzie większość korpusu to rzadko dotykane archiwum — w naszej testowej bibliotece dotknięto około 2% plików w 30 dni — utrzymywanie pełnego lokalnego indeksu miliona elementów na każdym urządzeniu wygląda na wysoką cenę za małą korzyść. Ale to nasza ocena, a Twój profil użycia może być inny.
FAQ: OneDrive i 1 000 000 plików
Ile plików może zsynchronizować OneDrive?
Do 1 000 000 elementów na instancję synchronizacji na urządzenie w wersji zapoznawczej, pod warunkiem spełnienia wymagań. Limit liczy elementy, czyli pliki i foldery razem.
Czy limit OneDrive to 300 000 czy 1 000 000 plików?
Oba. 300 000 to zalecenie Microsoftu dla optymalnej wydajności, a 1 000 000 to górna granica wsparcia w wersji zapoznawczej. Jedno nie zastąpiło drugiego.
Ile czasu zajmuje synchronizacja 1 miliona plików?
W naszym teście 52 minuty dla 997 392 elementów na maszynie z Core i9, 32 GB RAM, dyskiem NVMe SSD i łączem 99 Mb/s. Średnie tempo w fazie aktywnej wyniosło 351 elementów/sek. Na słabszej maszynie, albo przy innej pracy w tle, zajmie to dłużej.
Czy OneDrive może zsynchronizować 1 milion plików na Windows 11?
W wersji zapoznawczej Microsoft obsługuje do 1 000 000 elementów na instancję synchronizacji, pod warunkiem spełnienia wymagań dotyczących Windows, RAM, SSD i klienta OneDrive. W naszym teście Windows 11 Pro 25H2 z 32 GB RAM i dyskiem NVMe SSD zsynchronizował 997 392 elementy w około 52 minuty.
Dlaczego OneDrive utyka na „Wyszukiwaniu zmian"?
Zarejestrowaliśmy dwa tryby ukryte pod jedną nazwą w interfejsie: krótki (20,7–36,6 sekundy, pliki dostępne) i długi (238 minut, z 44 z 45 prób otwarcia pliku przekraczającymi limit czasu). Nie ustaliliśmy, co powoduje przełączenie, i nic w standardowym interfejsie nie odróżnia tych dwóch.
Dlaczego OneDrive wolno synchronizuje dużą bibliotekę?
Według naszych pomiarów wąskim gardłem nie jest ani sieć, ani dysk, lecz opóźnienie komunikacji z usługą i przetwarzanie metadanych. Znamiennie, tempo utrzymuje się na 402–469 elementów/sek. tylko przez pierwszą połowę biblioteki, po czym spada do stałych 297 i już się nie podnosi.
Ile RAM-u zużywa OneDrive?
Szczyt podczas pierwszej synchronizacji wyniósł 3579 MB. W spoczynku, gdy nic się nie dzieje, proces zajmował 1507–2187 MB. Podczas długiej fazy sprawdzania zmian zużycie wzrosło z 936 MB do 2501 MB w ciągu dwóch godzin obserwacji.
Ile miejsca na dysku zajmuje synchronizacja miliona elementów?
6,57 GB w spoczynku przy wszystkich plikach tylko-w-chmurze, ze szczytem 20,62 GB podczas przebiegu. Z tego 2036 MB to własna baza danych silnika synchronizacji — mniej więcej 2,1 KB na element.
Czy do synchronizacji OneDrive potrzebny jest szybki internet?
Według naszych pomiarów nie — nie jeśli masz już około 100 Mb/s. OneDrive wykorzystywał średnio 5,9% łącza i nigdy nie zbliżył się do jego nasycenia.
Czym jest błąd OneDrive 0x800701AA?
„Operacja w chmurze nie została ukończona przed upływem limitu czasu" — żądanie pobrania treści pliku w chmurze nie skończyło się w dozwolonym czasie. W naszym teście zobaczyliśmy ten kod podczas długiej fazy sprawdzania zmian; poza nią żadna próba otwarcia pliku się nie powiodła.
Czy OneDrive obsługuje 1 milion plików na VDI?
Nie. Microsoft wprost stwierdza, że VDI nie jest obsługiwane w tej wersji zapoznawczej.
Jak pracować z dużą biblioteką SharePoint bez synchronizacji?
Są cztery opcje: podzielić bibliotekę, synchronizować selektywnie, trzymać ludzi w przeglądarce, albo zamontować bibliotekę jako dysk Windows bez lokalnej kopii stanu. Ostatnia opcja usuwa każdy koszt zmierzony w tym artykule, ale wymaga stałego połączenia — więcej szczegółów w jak pracować z dużą biblioteką SharePoint.
Praktyczna strona — jak zmapować SharePoint jako literę dysku, jakie metody istnieją i które z nich wytrzymują obciążenie: mapowanie SharePoint jako dysku sieciowego w Windows →
Jeśli przeszedłeś tę drogę i rozpoznajesz objawy — nasza historia roku spędzonego na walce z synchronizacją na bibliotece o rozmiarze jednego terabajta →
Źródła
- Microsoft — ograniczenia w OneDrive i SharePoint: zalecenie 300 000 elementów.
- Microsoft Learn — obsługa klienta synchronizacji na VDI.
- Microsoft — synchronizacja OneDrive utknięta na „przetwarzaniu zmian".
- Własne pomiary SkylFlow, 19–20 września 2026: trzy testy na fizycznej maszynie, pełne logi w CSV i JSON.
Odtwarzalność. Każda liczba tutaj pochodzi z naszego własnego skryptu pomiarowego, który odczytuje bazę danych silnika synchronizacji OneDrive na żywo i tylko do odczytu oraz zbiera dane o obciążeniu przez CIM. Skrypt, protokół testu i surowe pliki CSV są przygotowywane do publikacji — napisz do nas, jeśli chcesz powtórzyć test na własnej bibliotece.