La velocità di copia SMB diminuisce con migliaia di piccoli file: cosa dovresti testare per primo?
Verifica se il numero di file, e non la velocità del collegamento, è il fattore scatenante prima di modificare le impostazioni SMB o di rete.
Su un NAS domestico, migliaia di piccoli file costringono il client e il server a ripetere la ricerca del percorso, i controlli di autorizzazione, le aperture, le creazioni, gli aggiornamenti dei metadati, le chiusure e la scansione lato applicazione per ogni oggetto. Un collegamento gigabit o 2.5GbE può rimanere per lo più inattivo mentre la copia procede lentamente, quindi il primo passo utile è un test A/B che mantiene simili i byte totali ma cambia il numero di oggetti, seguito da test su storage, client e strumenti di copia in un ordine fisso.
Confronta Un File Grande Con Gli Stessi Byte in Piccoli File
Crea due set di test sulla stessa memoria di origine: un file grande e una cartella contenente migliaia di piccoli file con dimensione totale approssimativamente uguale. Copia entrambi nella stessa condivisione NAS usando lo stesso client, percorso SMB e finestra temporale.
Un report di un utente TrueNAS mostra il tipico schema di rallentamento SMB con piccoli file mentre i file grandi mantenevano una velocità di rete quasi normale. Questo contrasto è più utile di un singolo valore di velocità perché dimostra che la forma del carico di lavoro cambia il collo di bottiglia.
Registra il tempo trascorso, il numero totale di file, i byte totali, i file al secondo, la media MB/s e se il rallentamento inizia immediatamente o solo dopo che la cache si riempie. Se entrambi i set sono lenti, indaga prima il percorso generale di rete o storage; se rallenta solo il set di piccoli file, continua con test focalizzati sui metadati.
Separa la Capacità di Rete Dal Lavoro Per File
Esegui un test di rete memoria-a-memoria tra lo stesso client e il NAS, poi confrontalo con il risultato SMB del file grande. Un test di rete pulito e una copia veloce di file grandi mostrano che il collegamento può trasportare dati anche se il carico di lavoro con piccoli file non riesce a mantenerlo pieno.
I piccoli file trasformano la copia in un lavoro ripetuto di richiesta e risposta. Eclectic Light ha documentato come i backup SMB pesanti di metadati possano richiedere tempi inaspettatamente lunghi anche quando si spostano pochi dati effettivi.
Non rispondere a questo risultato modificando prima MTU, duplex o aggregazione del collegamento. Monitora invece i file al secondo e la latenza caricata; la domanda utile successiva è se il lavoro ripetuto stia aspettando la sorgente, la destinazione NAS o l’ispezione lato client.
Testa Separatamente la Latenza dei Metadati di Sorgente e Destinazione
Copia il set di piccoli file dalla sorgente in un’altra cartella locale sul client, poi crea o estrai lo stesso set localmente sul NAS. Questi due test isolano le letture di origine e le creazioni sul NAS senza che SMB si interponga.
Una discussione diretta su Unraid ha misurato operazioni lente per file che non erano visibili durante i trasferimenti di file grandi. Il segnale importante è se la creazione locale di destinazione è già lenta prima che la rete entri in gioco.
Se la copia locale client è lenta, ispeziona il disco di origine, il filesystem, la crittografia e la disposizione dei file. Se la creazione locale NAS è lenta, ispeziona il pool di destinazione, il livello cache, il percorso di parità, la frammentazione dello spazio libero, il dispositivo metadati e il comportamento di scrittura sincrona prima di ottimizzare SMB.
Misura la Scansione di Sicurezza e l’Indicizzazione su Entrambi i Punti
Antivirus, protezione endpoint, generazione di miniature, indicizzazione dei contenuti, watcher di sincronizzazione e scanner multimediali possono ispezionare ogni nuovo file. Il loro costo fisso per oggetto può dominare un carico di lavoro che crea migliaia di elementi rapidamente.
Esegui un test controllato escludendo temporaneamente la scansione e l’indicizzazione in tempo reale solo per la cartella di test dedicata, poi ripristina immediatamente la protezione. Lo scopo non è lasciare la sicurezza disabilitata, ma determinare se il rallentamento segue l’ispezione per file.
Se i file al secondo aumentano drasticamente, crea un’esclusione a lungo termine più sicura solo per l’area di staging backup affidabile o i dati cache generati, oppure programma la scansione dopo il trasferimento. Se il risultato non cambia, ripristina le impostazioni originali e passa al comportamento dello strumento di copia invece di accumulare eccezioni inspiegate.
Confronta Strumenti di Copia e Concorrenza Senza Cambiare il Dataset
File Explorer, Finder, Robocopy, rsync, client di backup e strumenti di archivio possono usare diverse profondità di coda, chiamate ai metadati, regole di ritentativo e parallelismo. Confronta due strumenti sullo stesso albero di origine e destinazione invece di confrontare carichi di lavoro non correlati.
La discussione di Resilio su scansioni con un gran numero di file illustra perché un lavoro può rimanere vincolato ai metadati anche quando cambia poco contenuto. Più thread possono nascondere parte della latenza, ma possono anche sovraccaricare il NAS con creazioni concorrenti.
Aumenta la concorrenza un passo alla volta e fermati quando i file al secondo smettono di migliorare, la latenza aumenta drasticamente o il NAS inizia a mettere in coda le scritture. Mantieni l’impostazione che migliora costantemente il carico reale, non il valore più alto consentito dallo strumento.
Usa il Modello di Risultato per Scegliere la Correzione Minima
La diagnosi dovrebbe indicare una fase dominante: capacità di rete, letture di origine, creazioni NAS, scansione endpoint, comportamento delle richieste SMB o strumento di copia. Non combinare tutte le possibili ottimizzazioni in un unico esperimento perché la variazione finale di velocità non spiegherà più la causa.
La spiegazione di ZimaSpace su come il numero di file aumenta il lavoro del NAS fornisce la ragione fondamentale per cui i file al secondo possono contare più degli MB/s per questo carico di lavoro.
Accetta la correzione solo quando lo stesso set di piccoli file migliora in esecuzioni ripetute senza danneggiare la velocità dei file grandi, i permessi, il comportamento di ripristino o la reattività del NAS. Quando il recupero individuale non è necessario, impacchettare piccoli file immutabili in un archivio può ridurre l’overhead degli oggetti, ma questa è una decisione di flusso di lavoro e non una riparazione universale SMB.
Prodotti consigliati
Supporto e consigli
Altro da leggere
Plex può condividere una GPU con un altro container Docker?
Plex e un altro container possono spesso accedere alla stessa GPU, ma è necessario testare il supporto dei driver, la mappatura dei dispositivi, il...
Come capire se un errore di Plex proviene dal client o dal server
Riproduci lo stesso elemento su un altro client, confronta il percorso della sessione, quindi raccogli le prove dal server solo dopo che l’ambito ti...
Come configurare la cache di Plex e l’archiviazione temporanea per la transcodifica
Proteggi lo stato persistente di Plex collocando i file temporanei di transcodifica su un’unità locale adatta, quindi verifica la pulizia, lo spazio libero e...
