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.

LiczbaCo oznacza
do 300 000 elementówZalecenie Microsoftu dla optymalnej wydajności. Liczba, wokół której warto planować.
do 1 000 000 elementówGó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.

Ustawienia OneDrive, zakładka Informacje, pokazująca przełącznik programu OneDrive Insider
Przełącznik wersji zapoznawczej znajduje się w Ustawienia OneDrive → Informacje → Program OneDrive Insider. Zrzut ekranu pokazuje stan przed przełączeniem: kompilacja 26.163.0823.0004, przełącznik wyłączony. Po włączeniu i restarcie klient zaktualizował się do 26.168.0830.0004 — kompilacji, na której przeprowadzono cały test.

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.

Centrum administracyjne SharePoint, zakładka Aktywność dla witryny zawierającej 890 191 plików
Centrum administracyjne SharePoint: 890 191 plików, 1,38 TB z 1,50 TB wykorzystane. W ciągu 30 dni wyświetlono lub edytowano 21 231 plików — mniej więcej 2% korpusu jest w aktywnym użyciu.

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

CPUIntel Core i9-11900K, 8 rdzeni / 16 wątków
Pamięć32 GB — górne zalecenie Microsoftu
DyskDysk NVMe SSD zawierający profil użytkownika
SystemWindows 11 Pro 25H2, kompilacja 26200.9457
OneDrive26.168.0830.0004, kompilacje zapoznawcze włączone
PołączenieNominalnie 99/100 Mb/s; zmierzone przed przebiegiem: 98,57 / 99,63 Mb/s, ping 2 ms
ProfilCzyste, osobne konto Windows
Właściwości systemu Windows 11: Intel Core i9-11900K, 32 GB RAM
Fizyczna maszyna, nie maszyna wirtualna: Core i9-11900K, 32 GB RAM, Windows 11 Pro 25H2 — konfiguracja powyżej zalecenia Microsoftu, nie tylko na jego poziomie.

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.

Ustawienia OneDrive, zakładka Konto, pokazująca nowo podłączoną bibliotekę
Punkt startowy: biblioteka właśnie została podłączona i wciąż pokazuje 0 KB. Skrypt już działa i zapisuje swój snapshot bazowy — dlatego wyniki mają „przed" i „po".

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.

Konsola skryptu pokazująca kamienie milowe 900 000 i 1 000 000 elementów oraz ikonę OneDrive w zasobniku z napisem Utworzono kopię zapasową i zsynchronizowano
Milionowy element: konsola pokazuje 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ądzeniu1 013 795 (905 313 plików + 108 482 foldery)
Dodane w tym przebiegu997 379 — biblioteka SharePoint
Obecne przed startem16 418 — osobisty OneDrive tego samego konta
Tylko w chmurze905 310 z 905 313 plików (99,9997%)
Pobrane lokalnie3 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ń milowyMin od startuTempo w segmencie
100 0008,8—
300 00016,5402 elementy/sek.
500 00023,1469 elementów/sek.
700 00034,2297 elementów/sek.
900 00046,3296 elementów/sek.
1 000 00051,8297 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óbZmierzono
RAM, szczyt3579 MB
RAM po zakończeniu2790 MB
CPU, średnia w fazie aktywnej2,1 z 16 rdzeni (13,1%)
CPU, szczyt2,35 rdzenia (14,7%)
Sieć, pobraneok. 2 GB
Dysk, odczyt / zapis69,3 GB / 79,3 GB
Kolejka dysku, 95. percentyl1 (szczyt 4)
Baza silnika synchronizacji2036 MB na koniec, 2318 MB w szczycie
Zużyte miejsce na dysku, na koniec6,57 GB
Szczytowe wymagane wolne miejsce20,62 GB
Tłumienie usługi0 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ść pobierania5,87 Mb/s — 5,9% łącza
95. percentyl12,34 Mb/s — 12,5% łącza
Próbki z wykorzystaniem łącza ≥ 80%0
Próbki fazy aktywnej poniżej 0,1 Mb/s45,1%
Czysty czas transferu całego ruchuok. 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ługi14 — dwa z nich to EnumChanges; zero błędów
Pobraneok. 22 MB (górna granica dla całej maszyny)
Dysk, proces OneDrive0,50 GB odczyt / 0,17 GB zapis
Baza silnika synchronizacjibez zmian
Zmiana liczby elementówzero — ani jednego rekordu
CPUśrednio 1,03 rdzenia, szczyt 1,79
RAMwzró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.

KiedyPróbyNieudaneUdział
Podczas sprawdzania zmian454498%
Gdy klient osiągnął stan roboczy900%

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.
OneDrive pokazujący 1 przerwaną czynność i błąd 0x800701AA
Co widzi użytkownik: 1 przerwana czynność — Operacja w chmurze nie została ukończona przed upływem limitu czasu. [Błąd 0x800701AA] dla pliku o rozmiarze 291 KB. Ikona w zasobniku w tym momencie pokazuje Wyszukiwanie zmian.

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.

CyklWyzwalaczDo „Utworzono kopię zapasową i zsynchronizowano"
1Czysty restart36,6 s (129,6 s od rozruchu)
2Logowanie, maszyna włączona 11 godzin20,7 s
3Logowanie, 74 minuty po rozruchu35,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.

Log skryptu pokazujący stan LookingForChanges i trzy udane sondy hydratacji
[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.
Faza „Wyszukiwanie zmian" sama w sobie niczego nie blokuje. W interfejsie pod jedną nazwą kryją się co najmniej dwa tryby: krótki, liczony w sekundach, w którym pliki są dostępne, i długi, liczony w godzinach, w którym nie są. Nic w standardowym interfejsie ich nie odróżnia.

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.

Planujemy przepuścić tę samą bibliotekę przez tę samą metodę z OneMount i opublikować liczby obok siebie — także tam, gdzie przegrywamy.

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

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.