Windows Server 2025 Indexation on REFS partition and search performance

testowa skrzynka 0 Punkty reputacji
2026-07-21T12:23:08.5366667+00:00

Hi,
we have AD joined Windows Server 2025 as fileserver. Users are mapping disk K: from fileserver via GPO.
FileServer contains ~9milions of files and folders - ~7TB of data. Shared folders are on ~11TB REFS partition.
FileServer is virtualized on Windows Server 2025 which works on NVMe disks, fileserver is using 20-50% RAM and vCPUs depending on users activity.
I started Indexing on fileserver(Windows Search service) only filenames. After 5,5m of files its slow down from ~100k files per hour to ~100k per day.

Windows dla firm | Windows Server | Usługi katalogowe | Inne
Komentarze: 0 Brak komentarzy

1 odpowiedź

Sortuj według: Najbardziej pomocne
  1. Hoang Le 6,275 Punkty reputacji Niezależny doradca
    2026-07-21T12:39:14.3533333+00:00

    Cześć,

    To, na co napotykasz, to znane wąskie gardło przy indeksowaniu Windows Search na dużą skalę, zwłaszcza na bardzo dużych zbiorach danych z dziesiątkami milionów elementów. Początkowe indeksowanie wykonuje się szybko, ponieważ to głównie sekwencyjna enumeracja metadanych, ale gdy katalog przekracza kilka milionów wpisów, indekser zaczyna napotykać wewnętrzne ograniczanie i narzut transakcyjny w bazie danych Windows Search (C:\ProgramData\Microsoft\Search\Data\Applications\Windows\Windows.edb). Na woluminach REFS to spowolnienie jest jeszcze bardziej widoczne, ponieważ operacje metadanych REFS są cięższe niż NTFS, a usługa wyszukiwania nie jest zoptymalizowana pod kątem REFS w ten sam sposób.

    Fakt, że przepustowość spada z ~100k/godzinę do ~100k/dzień po 5,5 miliona plików, jest zgodny z problemami indeksera z fragmentacją bazy danych i commitami checkpointów. Możesz to potwierdzić, monitorując SearchIndexer.exe I/O i sprawdzając dziennik aplikacji pod kątem identyfikatorów zdarzeń 3036 lub 1008, które często wskazują na blokady crawlowania. Kolejną przydatną kontrolą jest uruchomienie esentutl /g na Windows.edb w celu weryfikacji stanu bazy danych.

    Najlepszą praktyką w środowiskach o takiej skali jest unikanie pełnego indeksowania treści na serwerach plików z dziesiątkami milionów elementów. Jeśli potrzebujesz tylko wyszukiwania po nazwach plików, możesz wyłączyć indeksowanie treści i ograniczyć indekser do konkretnych udziałów zamiast całego wolumínu. Alternatywnie, można przenieść wyszukiwanie do dedykowanego rozwiązania indeksacyjnego, takiego jak Microsoft Search w SharePoint lub Azure Cognitive Search, które są przeznaczone dla zbiorów danych o tej wielkości. Serwery plików oparte na DFSR na bazie lokalnie z NTFS nadal działają lepiej w Windows Search niż w REFS.

    Jeśli musisz zachować Windows Search, możesz spróbować zresetować indeks (Indexing Options → Advanced → Rebuild) po wykluczeniu niepotrzebnych ścieżek i upewnić się, że usługa ma wystarczającą ilość pamięci RAM i CPU. Ale realistycznie rzecz biorąc, spowolnienie, które widzisz, jest architektoniczne, a nie błędne ustawienie. Dla plików 9 milionów+ Windows Search nie jest odpowiednim narzędziem do trwałej wydajności indeksowania.

    Mam nadzieję, że znalazłeś tu coś przydatnego. Jeśli pomoże ci to lepiej zrozumieć problem, wdzięcznie zaakceptuj odpowiedź. Jeśli masz więcej pytań, śmiało zostaw wiadomość. Miłego dnia!

    Hoang Le.

    Czy ta odpowiedź była pomocna?

    Komentarze: 0 Brak komentarzy

Twoja odpowiedź

Odpowiedzi mogą być oznaczone jako „Zaakceptowane” przez autora pytań i „Proponowane” przez moderatorów, co pomaga użytkownikom poznać odpowiedź rozwiązującą problem autora.