OneDrive синхронізував 1 000 000 файлів за 52 хвилини. Потім перевіряв їх майже 4 години

OneDrive 1 000 000 файлів: що ми перевірили

Почнемо з результату, а не з вимог Microsoft.

1 000 000 — це межа підтримки, а не гарантія комфортної роботи.

Первинна синхронізація нас приємно здивувала. Вона виявилася швидшою, ніж ми очікували, і рівно нічого в системі не «лягло»: процесор був зайнятий на 2,1 ядра з 16, мережа — на 5,9% каналу, диск ніколи не мав черги. Якщо ви шукали відповідь на питання «чи витягне OneDrive мільйон файлів» — витягне.

Проблема почалася після. Ми вийшли з системи й зайшли знову — те, що робить будь-який користувач щоранку. Клієнт перейшов у стан «Looking for changes» і пробув у ньому 3 години 58 хвилин. У цей час 44 з 45 спроб відкрити тестовий файл із бібліотеки завершились помилкою тайм-ауту.

Далі — вся методика, всі цифри й межі того, що ми можемо стверджувати.

Розкриття: ми розробляємо OneMount — інструмент, який підключає бібліотеки SharePoint як диск Windows без синхронізації. Тобто в нас є очевидний конфлікт інтересів. Саме тому цей матеріал побудований так: спочатку цифри й методика, і тільки після вердикту — про наш продукт. Скрипт вимірювання та сирі дані ми публікуємо, щоб тест можна було повторити.

Про повноту: ми не знайшли опублікованого незалежного benchmark, який вимірював би саме таку конфігурацію на мільйоні реальних елементів. Якщо він існує — надішліть, ми з радістю порівняємо методологію.

Що Microsoft змінила в лімітах OneDrive

Microsoft заявила клієнт синхронізації OneDrive у публічному превʼю підтримує до 1 000 000 елементів на один екземпляр синхронізації на пристрої. Функція розгортається через Insider-кільце клієнта.

І тут важлива деталь, яку легко прочитати неправильно.

Microsoft заявила 300 000 елементів залишаються рекомендацією для оптимальної продуктивності. Ліміт 1 000 000 — це межа підтримки в режимі превʼю, а не нова рекомендація. Microsoft не замінила 300 000 на 1 000 000: обидва числа живуть одночасно й означають різні речі.

Вимоги до машини

Microsoft заявила для превʼю на 1 000 000 елементів:

• Windows 11 або Windows Server 2022 і новіші;
• мінімум 16 ГБ RAM, рекомендовано 32 ГБ;
• SSD — не HDD;
• процесор рівня Intel Core i5 / AMD Ryzen 5 або кращий;
• клієнт у кільці Insiders;
• VDI не підтримується.

Останній пункт вартий окремої уваги. Якщо ваша інфраструктура побудована на віртуальних робочих столах, ліміт 1 000 000 вас поки що не стосується взагалі. Наш тест тому й проводився на фізичній машині.

Тестова бібліотека: 997 392 елементи SharePoint

Ми не генерували синтетичне дерево. Бібліотека — реальна, робоча, з живою історією: документи, експорти, скани, проєктні теки за багато років, із типовими для такого корпусу довгими назвами й глибокою вкладеністю.

Ми виміряли точну кількість елементів ми взяли не з клієнта, а з REST API самої бібліотеки, до початку синхронізації: 997 392 елементи. Із них 890 191 файл — решта, 107 201, це папки (різниця двох чисел, а не окремий вимір). Важливо: ліміт 300 000 / 1 000 000 рахує саме елементи, тобто папки враховуються нарівні з файлами.

Стенд

Тобто це машина рівня «кращий за рекомендований». Якщо десь і мало все пройти гладко — тут.

Слабших конфігурацій ми не вимірювали, тому всі числа нижче стосуються тільки цього стенду. Наше очікування, що на машині з меншою памʼяттю й повільнішим диском буде гірше, — припущення, а не вимір.

Як ми знімали метрики

Обходити дерево файлів під час синхронізації не можна: сам обхід втручається у стан файлів — запити метаданих, можлива гідратація — і спотворив би те, що ви вимірюєте. Тому ми його не робили. Прогрес натомість читається прямо з бази рушія синхронізації OneDrive (SyncEngineDatabase.db, SQLite) — наживо, тільки на читання. Звідти беруться:

• кількість елементів, зареєстрованих рушієм синхронізації;
• розподіл «тільки в хмарі / завантажено локально»;
• секунди тротлінгу з боку сервісу і HTTP-коди відповідей;
• кількість гідратацій.

Інтерпретація ми виходимо з того, що саме ці записи й формують величину, до якої застосовується ліміт 300 000 / 1 000 000 — але методики підрахунку Microsoft не публікує, тож це наше припущення, а не підтверджений факт.

Навантаження (процесор, памʼять, диск, черга до диска, мережа) знімається через CIM, де імена властивостей не залежать від мови ОС. Окремо працює проба гідратації: скрипт із заданим інтервалом намагається відкрити невеликий хмарний файл із бібліотеки з жорстким тайм-аутом, фіксує результат і тривалість, після чого повертає файл у хмарний стан, щоб пробу можна було повторити. Саме ця проба дала найцікавіші дані.

Скільки часу займає синхронізація 1 000 000 файлів OneDrive

Спершу домовимось про годинник, бо інакше числа не зійдуться. Заміри стартували о 17:01:48, коли бібліотека ще не була підключена. Кнопку Sync натиснуто о 17:06:53. Лічильник елементів почав рости о 17:07:18. Усі віхи нижче рахуються від старту заміру.

Швидкості на відрізках обчислені з посемплових даних, а не з різниці округлених значень у колонці часу, тому вони можуть не збігатися з тим, що дасть калькулятор по сусідніх рядках. Причина проста: опитування бази йшло з інтервалом близько 11 секунд, і віха фіксувалася на першому семплі, який її перетнув, — наприклад, позначку «100 000» зафіксовано на семплі, де вже було 131 536 елементів.

Ми виміряли на перших двох відрізках клієнт тримав 402 і 469 елем./с. Далі швидкість опустилася до 297 елем./с — і залишилася там до кінця: 297,1, потім 296,5, потім 297,4. Три останні відрізки вкладаються в один елемент за секунду один від одного.

Тобто це не поступова деградація, а перехід на рівне плато приблизно на середині бібліотеки. Середнє по активній фазі — 351 елем./с, зафіксований пік — 590 елем./с.

Інтерпретація причину ми назвати не можемо. Тротлінгу з боку сервісу не було взагалі — нуль вікон, нуль секунд. Мережа, диск і процесор у другій половині були навантажені не більше, ніж у першій. Рівність плато радше вказує на якусь сталу межу — наприклад, розмір пакета запиту чи кількість паралельних потоків, — ніж на накопичувану вартість. Але це гіпотеза, а не вимір.

Перший мільйон елементів синхронізується не рівномірно: після приблизно половини швидкість стає вдвічі нижчою і далі не змінюється. Це варто закладати в оцінку часу міграції.

OneDrive синхронізував 1 013 795 елементів за 52 хвилини

Ми виміряли фінальні числа:

Про ці 13 елементів варто сказати чесно: це різниця між двома числами, знятими в різні моменти на живій бібліотеці, а не список файлів, які ми знайшли й перевірили. Які саме це елементи — і чи існують вони взагалі — ми не встановлювали.

Головне ж інше: клієнт зробив рівно те, що обіцяв. Він побудував повне дерево з майже мільйона елементів, не завантажуючи вміст. На диску зʼявилися placeholder-и, а не файли — 99,9997% залишилися хмарними.

Чесна примітка про кінець забігу. Скрипт зафіксував зупинку лічильника о 52,8 хв і перейшов у фазу перевірки, чи це справді кінець. Ми зупинили заміри вручну на цій фазі, побачивши «Backed up and synced» у треї — тому в підсумковому JSON стоїть completed_cleanly: false. Число 52 хвилини — це момент, коли ріст лічильника припинився, а не формальне «завершено» від скрипта.

Скільки RAM, CPU, диска та трафіку потребує OneDrive

Це та частина, заради якої варто було все вимірювати. Коротка відповідь: значно менше, ніж очікуєш від мільйона файлів — крім одного показника.

Три числа, на які варто дивитися окремо

База на 2 ГБ. Ми виміряли рушій синхронізації витрачає близько 2,1 КБ на кожен елемент власної службової бази. У піку вона доходила до 2 318 МБ і осіла на 2 036 МБ. Ця база лежить у профілі користувача й читається та пишеться при кожній перевірці змін — запамʼятайте це, воно знадобиться в наступному розділі.

149 ГБ дискових операцій на 2 ГБ трафіку. Клієнт прочитав 69,3 ГБ і записав 79,3 ГБ, щоб завантажити близько двох гігабайтів метаданих. Інтерпретація це приблизно 75-кратне підсилення запису відносно обсягу, отриманого з мережі. На NVMe це непомітно. На SATA SSD початкового рівня або — тим паче — на HDD це буде зовсім інша історія, і саме тому Microsoft ставить SSD у вимоги.

20,62 ГБ піку проти 6,57 ГБ підсумку. Ми виміряли вільне місце на томі впало з 253,93 ГБ до мінімуму 233,31 ГБ — це сталося на 51,6-й хвилині, коли було проіндексовано 994 247 елементів. Тобто тимчасова потреба в місці була у 3,1 раза більшою за те, що залишилося по завершенні.

Інтерпретація це має практичний наслідок: машина, на якій вільно близько 10 ГБ, впаде посеред синхронізації — хоча кінцевий стан помістився б на ній без проблем. Якщо плануєте розгортання на парку з тісними системними дисками, орієнтуйтесь на пікове число, а не на фінальне.

Чому швидкий інтернет не прискорив синхронізацію

Ми запускали тест на каналі 99 Мбіт/с саме для того, щоб відповісти на питання, яке постійно ставлять при міграціях: чи варто купувати швидший інтернет заради синхронізації.

Ми виміряли:

Майже половину активної фази мережа фактично мовчала. Весь трафік, який клієнт узагалі завантажив, на цьому каналі передається за неповних три хвилини — а забіг тривав 52.

У нашому тесті канал не був вузьким місцем. Швидший інтернет не скоротив би цей забіг.

Вердикт, який винесла сама методика заміру, дослівно:

Інтерпретація вузьке місце — не пропускна здатність, а кількість службових звернень до сервісу й обробка метаданих. Мільйон елементів — це мільйон записів, які треба отримати, розібрати й покласти у власну базу. Ширший канал не зменшує кількість цих операцій.

Практичний висновок для планування: якщо у вас уже є стабільні 100 Мбіт/с, гроші на апгрейд каналу заради швидшої синхронізації витрачати не варто. Вони більше допоможуть у RAM і NVMe. Нижче 100 Мбіт/с ми не вимірювали, тому не стверджуємо, де саме починається вплив каналу.

Що відбувається з OneDrive після повторного входу

Тут історія повертає в інший бік.

Після завершення синхронізації ми зробили найбуденнішу річ у світі: вийшли з сеансу Windows і зайшли знову. Ніяких змін у бібліотеці, ніякого перезавантаження — просто вихід і вхід.

Ми виміряли процес OneDrive стартував о 18:18:03. Стан «Backed up and synced» зʼявився о 22:15:39.

Методична чесність: наш скрипт спостереження був запущений не з першої секунди, тому детальні заміри навантаження охоплюють 116,9 хвилини з 237,6. Повна тривалість рахується від часу старту процесу OneDrive до появи статусу — ці дві точки зафіксовані надійно.

Що відбувалося в ці спостережувані дві години:

Тут варто зупинитися, бо це найдивніша частина всього тесту.

Ми виміряли лічильник елементів не змінився жодного разу за всю спостережувану фазу: 1 013 795 на кожному семплі, від початку й до переходу в робочий стан. Два нові елементи зʼявилися о 22:16:12 — через 33 секунди після того, як клієнт показав «Backed up and synced».

Ми виміряли те саме зі зверненнями до сервісу. За майже дві години фази клієнт зробив 14 викликів, з них лише два EnumChanges. Решта 17 EnumChanges із загальних 19 припали на чверть години після завершення фази. Тобто сама фаза була майже повністю мовчазною.

Інтерпретація це не схоже на завантаження даних і навіть не схоже на активний діалог із сервісом. Це схоже на довгу внутрішню роботу з власним станом — з тією самою базою на 2 ГБ, про яку йшлося вище. Але підтвердити це ми не можемо: OneDrive не публікує, що саме він робить у цій фазі.

Застереження до цифри трафіку: наш лічильник мережі підсумовує байти по всіх активних інтерфейсах машини, а не по процесу OneDrive. Тому 22 МБ — це верхня межа для всього компʼютера, а не вимір трафіку OneDrive. Дискові ж числа зняті з лічильників самого процесу й стосуються саме його.

OneDrive завис на «Looking for changes» майже на 4 години

Найважливіше в цій фазі — не її тривалість, а те, що ззовні вона виглядає абсолютно нормально. Іконка в треї не показує помилки. Вона показує «Looking for changes» — рівно те саме, що показує п'ятисекундна перевірка після звичайного ранкового ввімкнення.

Ми спостерігали жодного індикатора прогресу, жодної оцінки часу, що залишився, жодного попередження. У штатному інтерфейсі клієнта — значок у треї й панель активності — ми не знайшли жодної ознаки, яка відрізняла б «зачекай 20 секунд» від «зачекай 4 години».

Інтерпретація для служби підтримки це найгірший можливий сценарій: стан не є помилкою, тому його немає в жодному моніторингу, і єдиний сигнал — дзвінок користувача, який скаже «в мене нічого не відкривається», а ви побачите в нього на екрані «все синхронізовано».

Файли не відкривалися під час перевірки

Це вже не спостереження на око, а вимір. Проба гідратації в цей час працювала постійно: скрипт намагався відкрити невеликий хмарний файл із бібліотеки й фіксував результат.

Ми виміряли з 45 спроб відкрити файл під час фази вдалася одна. Вона зайняла 49 342 мс — майже 50 секунд на файл розміром у сотні кілобайтів. Після виходу клієнта в робочий стан ті самі проби займали 305–645 мс.

Що саме зафіксували проби. Тут потрібна точність. Автоматична проба обриває спробу на 60-й секунді й записує результат timeout — тобто вона припиняє виклик раніше, ніж Windows устигає повернути код помилки. Тому в 44 записах коду помилки немає, там стоїть «немає відповіді за 60 с».

Ми спостерігали код зʼявився тоді, коли ми відкрили файл вручну на початку тієї самої фази:

Ми спостерігали Excel двічі відреагував на цю ситуацію повідомленням «file format or file extension is not valid» — тобто застосунок отримав частковий або порожній потік і зробив із цього власний хибний висновок.

Інтерпретація ось тут і народжуються конфліктні копії та «зіпсовані» документи. Користувач бачить помилку формату, закриває файл, відкриває ще раз, пересохраняє під іншим імʼям — і далі ланцюжок розгортається вже без участі OneDrive.

Червоні значки помилки на файлах, які клієнт вважає синхронізованими

Окремо ми розібрали ще одну річ, яку часто зустрічають на великих бібліотеках: у Провіднику частина папок і файлів має червоний значок помилки, а сам клієнт OneDrive каже «Backed up and synced» і жодної проблеми не показує.

Ми виміряли значок керується властивістю оболонки System.FileOfflineAvailabilityStatus. У корені бібліотеки її значення було «Помилка» для 22 з 28 елементів, включно з усіма 14 папками. У ширшій вибірці по дереву — 42 з 388 перевірених елементів, тобто 10,8%.

Ми виміряли при цьому власна база OneDrive не знає про жодну помилку: усі таблиці збоїв порожні, а в SyncDiagnostics.log на момент написання статті нульові всі лічильники — і невдалих вивантажень, і невдалих завантажень.

Ми спостерігали причину виникнення цього стану ми не встановили. Ми перевірили й відкинули чотири гіпотези, але назвати тригер чесно не можемо. Що можна сказати впевнено: значок помилки в Провіднику й реальний стан синхронізації — це два різні джерела, які можуть розходитися, і покладатися на іконку як на діагностику не варто.

OneDrive 1 000 000 файлів: проблема не в первинній синхронізації

Було б нечесно зупинитися на 238 хвилинах і зробити з них правило. Ми провели третій тест — кілька циклів перезавантаження й входу в сеанс на тій самій машині з тією самою бібліотекою. Записалося чотири прогони; три з них захопили повний цикл синхронізації, четвертий обірвався на 22-й секунді без переходу статусу й у підрахунок не йде.

Ми виміряли на однаковій основі — від першого зчитаного статусу до «Backed up and synced» — розкид склав 20,7–36,6 секунди. Проба гідратації за ці три цикли виконалась 12 разів із 12 успішно.

Розкладемо проби за станом клієнта, бо саме це важливо:

Шість проб припали саме на стан «Looking for changes» — той самий, у якому двома днями раніше провалилися 44 спроби з 45. Усі шість завершились успішно за секунди.

Ми виміряли у сталому стані процес OneDrive тримав від 1 507 до 2 187 МБ памʼяті — тобто на мільйонній бібліотеці півтора-два гігабайти RAM зайняті постійно, навіть коли нічого не відбувається.

Це принципово важливий результат, і він працює проти простої версії історії.

І ще одне застереження, щоб не видати бажане за виміряне: ми не можемо стверджувати, що в цих трьох циклах клієнт виконував той самий обсяг роботи. Довга фаза була першим входом після первинної синхронізації мільйона елементів, наступні три — ні. Можливо, це і є відповідь; можливо, ні. Ми цього не перевірили.

Так само три нормальні цикли поспіль не доводять, що патологічний режим більше не повториться — як і одна його поява не доводить, що він буде щоразу. Ми не вимірювали частоту й не станемо її вигадувати.

Інтерпретація і саме в цьому проблема з точки зору експлуатації. Подія, яка трапляється рідко й непередбачувано, але триває годинами й виглядає як норма, керується гірше, ніж відверта помилка. Помилку видно в моніторингу. Це — ні.

Питання не в тому, чи може OneDrive синхронізувати мільйон файлів. Він може. Питання — що відбувається після цього.

Довгі шляхи OneDrive: 400 символів проти обмежень Windows

Ще одна річ, яка на великих бібліотеках перестає бути теоретичною. Після синхронізації шлях до файла отримує локальний префікс виду C:\Users\<користувач>\<Тенант>\<Сайт> - <Бібліотека>\.

Ми виміряли на робочому ПК цей префікс зʼїдає 70 символів із 260. Структура папок, яка на мережевому диску S:\ мала цілком помірний шлях, після синхронізації може вийти за межу.

Тут працюють три різні ліміти, і вони не збігаються:

Ми виміряли на робочій машині з 16 427 елементів 17 шляхів вийшли за 260 символів, найдовший — 328. LongPathsEnabled у реєстрі стояв у 0. Для одного з таких шляхів [System.IO.File]::Exists() повернув False — тобто навіть .NET без спеціального префікса файла не бачить, хоча Провідник його показує.

Інтерпретація формулювання тут має бути обережним: SharePoint може прийняти довший шлях, ніж деякі застосунки Windows зможуть нормально відкрити після синхронізації. Це не три абсолютні закони, а три різні рівні з різними правилами, і сервіс ніде не попереджає про розбіжність.

Що з цим робити практично:

• LongPathsEnabled=1 знімає обмеження Win32, але не знімає обмеження Office;
• скорочувати назви бібліотек і верхніх папок, а не нижніх — виграш множиться на все піддерево;
• перевіряти корпус до міграції, а не після.

Що станеться, якщо синхронізувати мільйон файлів на сотнях ПК

Усе вище — це один комп'ютер, кращий за рекомендований, у чистому профілі, на стабільному каналі, без жодного стороннього навантаження. Тепер перенесіть це на парк.

Інтерпретація усе, що далі в цьому розділі, — наші висновки з досвіду впровадження, а не виміряні числа.

Перше: помножте ресурси на кількість машин

6,6 ГБ на диску в сталому стані й до 21 ГБ на піку — на кожному пристрої. 2 ГБ службової бази, яку треба читати й писати при кожній перевірці змін. 3,6 ГБ RAM на піку — на машинах із 8 ГБ це вже конкуренція з робочими застосунками. Вимога Microsoft у 16 ГБ мінімум і 32 ГБ рекомендовано — не формальність.

Друге: рідкісна подія на великому парку перестає бути рідкісною

Ми не знаємо частоти патологічної фази перевірки й не будемо її вигадувати. Але логіка масштабу працює однозначно: на сотнях машин навіть рідкісна епізодична проблема перестає бути проблемою одного користувача — її масштаб визначається кількістю пристроїв і частотою таких подій. Один випадок на 4 години простою — це керована незручність. Той самий випадок на парку — це навантаження на підтримку, яке треба закладати в бюджет.

Третє: користувачі не чекають

Первинна синхронізація на ідеальній машині зайняла 52 хвилини. На реальному робочому ноутбуці, де людина паралельно працює, це буде довше. І людина в цей час не сидітиме склавши руки — вона відкриватиме файли, копіюватиме теки, запускатиме Excel. Кожна така дія конкурує з синхронізацією за ті самі диск і процесор.

З нашого досвіду впроваджень: час від часу на частині машин починається повторна синхронізація або тривалий пошук змін. Бували випадки, коли синхронізація не завершувалася — не вистачало диска чи памʼяті, або користувач навантажував систему під час забігу. Залишити комп'ютер на ніч допомагало не завжди. На потужніших машинах було відчутно краще, але не бездоганно.

Четверте: другий пристрій — це другий такий самий забіг

Ліміт сформульований як «на екземпляр синхронізації на пристрої». Людина з ноутбуком і стаціонарним ПК проходить увесь цикл двічі, з усіма ресурсами й усіма ризиками.

Чи варто синхронізувати бібліотеку SharePoint на 1 000 000 файлів?

Наш вердикт після всіх трьох тестів.

1 000 000 — це межа підтримки, а не гарантія комфортної роботи.

Практично це означає:

• Якщо ваша бібліотека до 300 000 елементів — синхронізація OneDrive залишається розумним вибором. Це рекомендація Microsoft, і наші дані їй не суперечать.
• Якщо між 300 000 і 1 000 000 — технічно це працюватиме, але тільки на машинах, що відповідають вимогам превʼю, і з розумінням, що ви на території «підтримується», а не «рекомендується».
• Якщо це парк із сотень машин — оцінюйте не час первинної синхронізації, а вартість супроводу сталого стану. Саме там живуть реальні витрати.
• Якщо у вас VDI — ліміт 1 000 000 вас не стосується.

Що робити з великою бібліотекою SharePoint

Варіантів, чесно кажучи, небагато, і жоден не ідеальний.

Розділити бібліотеку

Найпряміший шлях: розбити корпус на кілька бібліотек або сайтів так, щоб кожен пристрій синхронізував менше 300 000 елементів. Працює, але вимагає перебудови структури, переучування людей і ламає посилання. Часто організаційно дорожче, ніж технічно.

Синхронізувати вибірково

Опція «Вибрати папки» дозволяє не тягнути все дерево. Але кількість елементів усе одно рахує те, що ви вибрали, а користувачі рано чи пізно вмикають зайве. І це не рятує від фази перевірки змін для того, що таки синхронізується.

Залишити людей у браузері

Найбезпечніший з точки зору клієнта варіант і найгірший з точки зору звички. Наш досвід простий: там, де люди роками працювали з буквою диска, повернення до вебінтерфейсу сприймається як крок назад, і частина команди знайде обхідні шляхи.

Підключити бібліотеку як диск, не синхронізуючи

Це напрямок, у якому пішли ми — і тут маємо повторити розкриття конфлікту інтересів: ми розробляємо OneMount, тому не є нейтральною стороною. Саме тому всі результати вище супроводжуються сирими даними й скриптом вимірювання, а не тільки нашими словами.

Логіка підходу проста. Усі числа в цій статті — 52 хвилини, 2 ГБ бази, 149 ГБ дискових операцій, 238 хвилин перевірки — це вартість утримання локальної копії стану мільйона елементів. Якщо локальної копії стану немає, немає й цієї вартості: немає що перевіряти після входу, немає бази, яка росте лінійно з кількістю елементів, немає піку в 21 ГБ на системному диску.

Натомість зʼявляються інші компроміси: потрібне зʼєднання для роботи з файлами, а затримка відкриття документа залежить від каналу, а не від локального диска. Це чесний обмін, і він підходить не всім і не для всіх сценаріїв. Офлайн-робота в потязі — не наш випадок.

Інтерпретація для великих бібліотек, де більшість корпусу — архів, до якого звертаються зрідка (у нашій тестовій бібліотеці за 30 днів торкнулися близько 2% файлів), тримати повний локальний індекс мільйона елементів на кожному пристрої виглядає як велика плата за малу користь. Але це наша оцінка, і ваш профіль використання може бути іншим.

FAQ: OneDrive і 1 000 000 файлів

Скільки часу займає синхронізація 1 000 000 файлів у OneDrive?

У нашому тесті — 52 хвилини для 997 392 елементів бібліотеки SharePoint на машині з Core i9, 32 ГБ RAM, NVMe SSD і каналом 99 Мбіт/с. Середня швидкість активної фази — 351 елемент/с. На слабшій машині або з паралельним навантаженням буде довше.

Microsoft скасувала ліміт 300 000 файлів?

Ні. 300 000 залишаються рекомендацією для оптимальної продуктивності. 1 000 000 — це верхня межа підтримки в публічному превʼю. Обидва числа діють одночасно.

Чи потрібен швидкий інтернет для синхронізації великої бібліотеки?

За нашими вимірами — ні, якщо у вас уже близько 100 Мбіт/с. OneDrive використав у середньому 5,9% каналу, жодного разу не наблизившись до насичення. Вузьке місце — затримка звернень до сервісу й обробка метаданих, а не пропускна здатність.

Скільки RAM використовує OneDrive на мільйоні файлів?

Пік під час первинної синхронізації — 3 579 МБ. У сталому стані, коли нічого не відбувається, процес тримав 1 507–2 187 МБ. У фазі тривалої перевірки змін споживання зростало з 936 МБ до 2 501 МБ за дві години спостереження.

Скільки місця на диску займає синхронізація мільйона елементів?

6,57 ГБ у сталому стані при повністю хмарних файлах, з піком до 20,62 ГБ під час самого забігу. З них 2 036 МБ — службова база рушія синхронізації, приблизно 2,1 КБ на елемент.

Чому OneDrive довго шукає зміни після перезавантаження?

Ми зафіксували два різні режими з однаковою назвою в інтерфейсі: короткий (20,7–36,6 секунди, файли доступні) і довгий (238 хвилин, 44 з 45 спроб відкрити файл завершились тайм-аутом). Причину переходу в довгий режим ми не встановили. У штатному інтерфейсі клієнта немає ознаки, яка б розрізняла ці стани.

Що означає помилка 0x800701AA в OneDrive?

«The cloud operation was not completed before the time-out period expired» — запит на завантаження вмісту хмарного файла не вклався у відведений час. У нашому тесті ми побачили цей код під час тривалої фази перевірки змін; поза нею жодна спроба відкрити файл не завершилася помилкою.

Чому файли позначені червоним значком помилки, якщо OneDrive каже, що все синхронізовано?

Значок керується властивістю оболонки System.FileOfflineAvailabilityStatus, і вона може розходитися з реальним станом у базі OneDrive. У нашому тесті 22 з 28 елементів у корені мали значення «Помилка», тоді як власні журнали клієнта не містили жодного збою. Причину ми не встановили — але значок у Провіднику не є надійним джерелом діагностики.

Чи працює ліміт 1 000 000 елементів на віртуальних робочих столах?

Ні. Microsoft прямо вказує, що VDI не підтримується в цьому превʼю.

---

Якщо ви зараз плануєте міграцію великої бібліотеки й хочете практичний бік питання — як саме підключити SharePoint буквою диска, які методи існують і що з них справді витримує навантаження: підключення SharePoint як мережевого диска у Windows — методи, реальні ліміти й що справді працює →

А якщо ви вже пройшли цей шлях і впізнаєте симптоми — ось наша історія про рік боротьби з синхронізацією терабайтної бібліотеки →

---

Джерела

• Microsoft — обмеження та ліміти в OneDrive і SharePoint: рекомендація 300 000 елементів, ліміт шляху 400 символів.
• Microsoft Learn — підтримка клієнта синхронізації у VDI.
• Microsoft — синхронізація OneDrive застрягла на «processing changes».
• Microsoft Learn — обмеження MAX_PATH і LongPathsEnabled.
• Власні заміри SkylFlow, 19–20 вересня 2026: три тести на фізичній машині, повний лог у CSV і JSON.

Методика та відтворюваність. Усі числа отримані власним скриптом вимірювання, який читає базу рушія синхронізації OneDrive наживо й тільки на читання, а навантаження знімає через CIM. Скрипт, протокол тесту й сирі CSV ми готуємо до публікації — напишіть нам, якщо хочете повторити тест на своїй бібліотеці, і ми надішлемо їх раніше.