Cosa causa la perdita di pacchetti solo durante le scritture di grandi dimensioni su NAS domestici?
La perdita di pacchetti durante scritture di grandi dimensioni su NAS di solito evidenzia una debolezza nel percorso di rete client-NAS sotto carico sostenuto, non solo nei dischi.
Un ping breve o una navigazione in una directory possono risultare puliti perché generano poco traffico, mentre una scrittura SMB di più gigabyte mantiene il client in trasmissione continua, riempie le code dello switch, mette alla prova il cavo a velocità di linea e costringe la NIC e la CPU del NAS a ricevere continuamente. La diagnosi dovrebbe quindi confrontare misurazioni a riposo e sotto carico, seguire la direzione della scrittura hop per hop e modificare un cavo, una porta, una funzione del driver o una condizione del mittente alla volta.
Dimostrare che la Perdita Compare Solo Durante il Carico di Scrittura
Eseguire un ping continuo e piccolo dal client che scrive al NAS prima della copia, durante una scrittura sostenuta di file di grandi dimensioni e dopo che la copia si ferma. Contemporaneamente, registrare la velocità SMB, la latenza sotto carico, le ritrasmissioni e i contatori di errori delle interfacce su entrambi gli endpoint.
Il test della perdita di pacchetti dovrebbe combinare ping, iperf e statistiche delle interfacce perché un singolo ping di quattro pacchetti può non rilevare un guasto breve scatenato dal carico. Il modello utile è se la perdita o gli errori iniziano con la scrittura e scompaiono quando la scrittura si ferma.
Se aumenta solo la latenza mentre i pacchetti alla fine tornano, indagare su code e bufferbloat prima di considerarlo perdita di pacchetti. Se lo storage NAS si blocca ma ping e contatori delle interfacce restano puliti, il collo di bottiglia è più probabilmente nel percorso di scrittura, filesystem, flush della cache, parità o applicazione piuttosto che nella consegna Ethernet.
Seguire la Direzione della Scrittura Prima di Sostituire l’Hardware
Durante una scrittura client-NAS, la NIC del client è il trasmettitore, lo switch inoltra verso la porta NAS e la NIC del NAS è il ricevitore. Questa direzione indica quali contatori e sostituzioni possono isolare effettivamente il guasto.
Un contatore di trasmissione NAS pulito non esclude problemi sul lato ricezione NAS, e un contatore di ricezione client pulito dice poco sui frame in uscita dal client. Confrontare errori e scarti TX client, contatori ingressi e uscite dello switch, errori e scarti RX NAS e ritrasmissioni TCP nello stesso intervallo di test.
Azzerare o registrare i contatori prima di ogni test, trasferire lo stesso file grande, quindi calcolare quale contatore aumenta solo durante il guasto. Il primo dispositivo che registra errori fisici, scarti di coda, pacchetti persi o scarti di ricezione diventa il prossimo punto di test.
Verificare se gli Errori Fisici Aumentano a Velocità di Linea Sostenuta
Un cavo, connettore, transceiver o porta switch marginale può passare traffico leggero ma accumulare errori CRC, frame, carrier o simbolo durante una scrittura lunga. I trasferimenti grandi non “sovraccaricano” un cavo negoziato correttamente; semplicemente creano abbastanza frame per rivelare rapidamente un percorso fisico debole.
Casi reali di troubleshooting di trasferimenti file mostrano che gli errori di interfaccia durante copie grandi indicano il cavo, la NIC, la porta o l’equipaggiamento intermedio piuttosto che la dimensione del file stessa.
Sostituire un solo componente per test: prima il cavo patch, poi la porta switch, infine l’adattatore client o la porta NAS quando possibile. Una diagnosi a livello fisico è supportata quando la crescita degli errori segue un componente o scompare dopo quella singola sostituzione.
Verificare se il Ricevitore NAS Scarta Frame Prima che SMB li Possa Processare
La rete può essere elettricamente pulita mentre l’host ricevente perde ancora pacchetti perché le code della sua NIC, il driver, la gestione delle interruzioni, la CPU o lo switch virtuale non riescono a gestire la velocità di arrivo. Questo è particolarmente plausibile su un piccolo NAS che esegue crittografia, container, indicizzazione o lavoro di parità durante la scrittura.
Un caso diretto di Ethernet ad alta velocità descrive il sovraccarico di elaborazione pacchetti dell’host anche senza una rete multi-hop congestionata. La distinzione chiave è che i contatori di scarti RX o pacchetti persi dell’host aumentano mentre i contatori CRC del cavo restano puliti.
Ripetere la scrittura con i servizi NAS non essenziali messi in pausa, quindi testare un carico di rete memoria-memoria che elimina le scritture su disco. Se gli scarti di ricezione persistono senza I/O di storage, concentrarsi sul driver NIC, profondità delle code, distribuzione delle interruzioni, switch virtuale e CPU host piuttosto che sul filesystem.
Cercare Microburst su una Porta di Uscita Più Lenta o Condivisa
La perdita di pacchetti può verificarsi all’interno dello switch quando un client più veloce invia verso una porta NAS più lenta, più client scrivono contemporaneamente o il traffico da più porte di ingresso converge su una coda di uscita. L’utilizzo medio può sembrare sicuro anche se un breve burst supera la capacità della coda.
Un esempio di scrittura su storage con perdita di pacchetti da microburst mostra come due mittenti ad alta velocità possano richiedere brevemente più larghezza di banda e spazio buffer di uscita di quanto la porta di destinazione fornisca.
Testare un mittente attraverso uno switch, quindi confrontare una connessione diretta o un percorso con velocità di collegamento uguali. Se la perdita scompare rimuovendo mittenti concorrenti, un uplink più lento o lo switch intermedio, ispezionare gli scarti di uscita e il comportamento delle code invece di sostituire i dischi NAS.
Testare EEE e Offload Solo Dopo Aver Localizzato il Guasto
Energy Efficient Ethernet, checksum offload, large-send offload, flow control e interrupt moderation possono influenzare combinazioni specifiche di NIC e driver, ma disabilitare tutte le funzioni contemporaneamente distrugge le prove necessarie per identificare la causa reale.
Un problema documentato di Ethernet su Raspberry Pi ha scoperto che disabilitare Energy Efficient Ethernet ha fermato gravi perdite di pacchetti per quel controller e partner di collegamento. Questo è un test A/B utile solo dopo che contatori o sostituzioni indicano l’endpoint piuttosto che il cavo o la coda dello switch.
Modificare una funzione, ripetere la stessa scrittura grande e ripristinare l’impostazione originale se il risultato non cambia. Una soluzione temporanea a livello driver dovrebbe essere documentata con modello adattatore, versione driver, porta switch e sintomo esatto in modo che un aggiornamento futuro possa essere testato invece di lasciare una regolazione inspiegata.
Usare il Modello di Risultato per Scegliere la Riparazione Successiva
La diagnosi finale dovrebbe spiegare perché il traffico piccolo resta pulito e le scritture sostenute falliscono. Errori fisici indicano un problema nel percorso del segnale; scarti di uscita dello switch indicano pressione sulle code; scarti RX NAS indicano sovraccarico del ricevitore; e contatori di rete puliti con una copia bloccata indicano comportamento dello storage o dell’applicazione.
La spiegazione di ZimaSpace su come la perdita di pacchetti riduce la velocità utile aiuta a interpretare perché il collegamento negoziato può rimanere a piena velocità mentre la scrittura SMB rallenta, si blocca o ritrasmette ripetutamente.
Non dichiarare il problema risolto finché la stessa scrittura grande non si completa ripetutamente con latenza stabile, zero nuovi errori fisici, nessun aumento di scarti di ricezione o scarti di uscita e checksum di destinazione intatto. Se le prove non distinguono tra rete e percorso di storage, smettere di cambiare impostazioni e ripetere il test rimuovendo l’I/O disco.
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...
