Un backlog, non un bug
L'indicizzatore segue il journal delle modifiche USN di NTFS, quindi ogni evento di massa sui file diventa lavoro di indicizzazione. Un aggiornamento di funzionalità di Windows che riparsa il volume di sistema, una sincronizzazione di OneDrive o Teams che scarica migliaia di file, un backup ripristinato o un fresco node_modules da sviluppatore possono mettere in coda centinaia di migliaia di elementi ciascuno. Indicizzare un singolo elemento costa poco; indicizzarne qualche centinaio di migliaia prende ore — ed è esattamente quello che guardi in Gestione attività.
L'altro classico è Outlook: un archivio .pst o .ost voluminoso viene indicizzato voce per voce nello stesso pipeline, e un archivio di posta da 20 GB può tenere occupato l'indicizzatore per la maggior parte di una giornata lavorativa. Apri Opzioni di indicizzazione e leggi la riga di stato — un contatore enorme di «elementi rimanenti» con il totale indicizzato in crescita significa un indicizzatore sano che smaltisce una coda. Un contatore che non si muove, o un database che si gonfia fino all'assurdo con la CPU alta, punta invece a un indice corrotto che si ricostruisce in loop — l'unico scenario in cui serve davvero il pulsante «Ricompila».
- Outlook classico con file .pst o .ost di grandi dimensioni — indicizzazione voce per voce attraverso lo stesso servizio
- OneDrive, Teams o un ripristino di backup che sincronizzano migliaia di file sulla macchina
- Un aggiornamento di funzionalità di Windows che riparsa il volume di sistema e riverifica l'indice
- Alberi da sviluppatore: node_modules, output di build e cartelle .git con decine di migliaia di file piccoli
- Strumenti di scansione file che toccano i metadati di tutto, rimettendo in coda l'intero disco
- Un indice Windows.edb o Windows.db corrotto che si ricostruisce, si gonfia e si ricostruisce di nuovo
Domare l'indicizzatore senza rompere la ricerca
La mossa ad alto rendimento è il controllo dell'ambito, non del servizio. In Opzioni di indicizzazione premi Modifica e togli la spunta a ogni albero in cui non cerchi mai — cartelle di build, archivi multimediali, la fossa dei download — e lascia che il cambiamento si assesti. Per gli archivi di Outlook classico, indicizza solo gli archivi in cui cerchi davvero anziché ogni .pst staccato mai montato; e dopo ogni modifica di ambito concedi all'indicizzatore una notte: una coda che alle sei di sera sembra infinita spesso è finita entro mattina.
Non disabilitare il servizio di ricerca per risolvere un picco di CPU. La ricerca di Esplora risorse nelle posizioni indicizzate, i risultati del menu Start e la ricerca di Outlook ricadono tutte in modalità di scansione lenta quando l'indice è spento, e il servizio riavvia comunque il backlog nel momento in cui viene riattivato. Se l'indice è davvero corrotto — il sintomo del rebuild in loop — usa Avanzate e Ricompila in Opzioni di indicizzazione per cancellare e far ricrescere il database una volta: costa qualche ora di CPU una tantum e chiude il loop. Sui server con molti utenti simultanei ricorda che l'indicizzatore gira per utente: più istanze di SearchIndexer.exe sono più backlog separati.
Domande e risposte
Perché SearchIndexer.exe usa così tanta CPU?
Sta smaltendo un backlog di indicizzazione — un nuovo archivio di Outlook, una sincronizzazione OneDrive, un aggiornamento che riparsa il volume — e Opzioni di indicizzazione mostra la dimensione della coda direttamente.
Devo disabilitare Windows Search per fermare l'uso di CPU?
No: la ricerca in Esplora risorse, Start e Outlook rallenta fino a strisciare, e il backlog torna quando il servizio viene riattivato; meglio ridurre l'ambito indicizzato o ricostruire un indice corrotto.
Scopri cosa include la licenza prima dell'acquisto.
La prova singola di 30 minuti include gli strumenti essenziali. Le funzioni PRO restano bloccate finché non attivi una licenza a pagamento.
Da leggere dopo
Scrivici: [email protected]