Dichiarazione SELECT remota lenta a causa del lungo "tempo di elaborazione del client", ma veloce localmente

Mentre è collegato al nostro server di produzione (SQL Server 2008, macchina molto potente), questa istruzione SELECT richiede 2 secondi , restituendo tutti i campi (4 MB di dati in totale).

SELECT TOP (30000) *
FROM person
WITH(NOLOCK);

Da qualsiasi altra casella sulla stessa rete (connessione mediante autenticazione SQL o Autenticazione Windows), la stessa query richiede 1 minuto, 8 secondi .

Sto testando con questa semplicissima affermazione per illustrare che non si tratta di un problema di indicizzazione o di una query. (Abbiamo problemi di prestazioni con tutte le query al momento ...)

Le file arrivano in pezzi, e non tutte in una volta. Ricevo immediatamente le mie prime file e quindi aspetto più di 1 minuto affinché arrivino i batch di righe.

Ecco le statistiche del client della query, quando viene eseguita dalla casella remota:

Query Profile Statistics
  Number of INSERT, DELETE and UPDATE statements 0
  Rows affected by INSERT, DELETE, or UPDATE statements 0
  Number of SELECT statements  2
  Rows returned by SELECT statements 30001
  Number of transactions 0

Network Statistics
  Number of server roundtrips 3
  TDS packets sent from client        3
  TDS packets received from server 1216
  Bytes sent from client         266
  Bytes received from server 4019800

Time Statistics
  Client processing time 72441 ms (72 seconds)
  Total execution time   72441 ms
  Wait time on server replies 0

Possiamo vedere che il "Tempo di elaborazione del client" è uguale al tempo di esecuzione totale.

Qualcuno sa quali passi posso fare per diagnosticare perché il trasferimento dei dati effettivi sta impiegando molto tempo?

Esiste un parametro di configurazione SQL che limita o limita la velocità di trasferimento dei dati tra computer?

Il tuo problema è sicuramente legato alla rete, in base alle tue informazioni. Come tale, deve essere trattato con i professionisti della rete (non sono io).

Cose che potrebbero aiutare:

• Schede NIC più veloci (su server SQL).
• Aggiunta di una scheda / subnet NIC allocata / specifica tra i server (web server e SQL Server).

Il web server è nella stessa sottorete del server SQL?

Ci sono router / ponti ecc. Tra loro?

Non ci sono molte modifiche possibili sul server SQL:

• I dati di output vengono inviati da SQL Server con "protocollo TDS" proprietario MS.
• La dimensione predefinita del buffer TDS è 4 KB. Vedi in MSDB: "Opzione dimensione pacchetto di rete"
• La compressione dei dati (con SQL Server o un'applicazione esterna) - dipende dalla natura dei dati.

Stai utilizzando una dimensione predefinita: vedi le tue statistiche: "Pacchetti TDS ricevuti dal server 1216" (4 MB / 1 KB = 4KB). Sì, la dimensione del buffer TDS può essere modificata: vedi in google: "Dimensione batch protocollo TDS"

Buona discussione sull'argomento: "la dimensione dei pacchetti di rete di sql determina davvero il traffico di andata e ritorno?"

Tuttavia, la modifica delle dimensioni del pacchetto TDS avrà (inevitabilmente) effetti imprevedibili e dovrebbe essere utilizzata nella produzione solo in casi eccezionali.

Anche il cambiamento dell'architettura o l'introduzione della memorizzazione nella cache dei dati di livello intermedio sarebbe di aiuto.

Questo problema è ora risolto.

Si è verificato un problema di rete e la casella SQL utilizzava una scheda NIC da 100 MB / s , anziché una scheda NIC da 10 GB / s ...

Una modifica della configurazione di rete per utilizzare la scheda di rete corretta ha risolto il problema. Ora stiamo ottenendo prestazioni simili per tutte le query dalla casella SQL di produzione e da altre caselle sulla rete.

Grazie a tutti per il vostro aiuto.

Alla lettura iniziale sembra che tu stia riscontrando alcuni problemi di latenza della rete. Hai guardato alcuni dei contatori di Network Perfmon? Questi potrebbero darti qualche indicazione su cosa sta succedendo con la rete.

Citazione da quali contatori Perfmon dovrei monitorare e cosa significano ciascuno di essi?

RETE IO

Per misurare l'I / O di rete, è possibile utilizzare i seguenti contatori:

Interfaccia di rete Bit totale / sec

Soglia: valori sostenuti di oltre l'80 percento della larghezza di banda della rete.

Significato: questo contatore indica la velocità con cui i byte vengono inviati e ricevuti su ciascuna scheda di rete. Questo contatore consente di sapere se il traffico sulla scheda di rete è saturo e se è necessario aggiungere un'altra scheda di rete. La velocità con cui è possibile identificare un problema dipende dal tipo di rete in uso e dalla condivisione della larghezza di banda con altre applicazioni.

Interfaccia di rete Bit ricevuti / sec

Questo contatore indica la velocità con cui i byte vengono ricevuti su ciascuna scheda di rete. È possibile calcolare la velocità dei dati in entrata come parte della larghezza di banda totale. Questo ti aiuterà a sapere che devi ottimizzare i dati in arrivo dal client o che devi aggiungere un'altra scheda di rete per gestire il traffico in entrata.

Interfaccia di rete Bit inviati / sec

Questo contatore indica la velocità con cui i byte vengono inviati su ciascuna scheda di rete. È possibile calcolare la velocità dei dati in entrata come parte della larghezza di banda totale. Questo ti aiuterà a sapere che devi ottimizzare i dati inviati al client o devi aggiungere un'altra scheda di rete per gestire il traffico in uscita.

ServerBytes Totale / sec

Questo valore non dovrebbe essere superiore al 50 percento della capacità di rete.

Questo contatore indica il numero di byte inviati e ricevuti sulla rete. Valori più alti indicano la larghezza di banda della rete come collo di bottiglia. Se la somma di byte totali / sec per tutti i server è approssimativamente uguale alle velocità di trasferimento massime della rete, potrebbe essere necessario segmentare la rete.

% Tempo di interruzione processore

Questo contatore indica la percentuale di tempo che il processore impiega a ricevere e riparare gli interrupt di processo. Questo valore è un indicatore indiretto dell'attività dei dispositivi che generano interruzioni, come gli adattatori di rete.

Lunghezza della coda di uscita dell'interfaccia di rete (*)

Questo contatore controlla per vedere quanti thread sono in attesa sulla scheda di rete. Se ci sono molti thread in attesa sulla scheda di rete, molto probabilmente il sistema sta saturando l'I / O di rete molto probabilmente a causa della latenza della rete o della larghezza di banda della rete.

Lunghezza coda di output è la lunghezza della coda dei pacchetti di output (in pacchetti). Se questo è più lungo di due, ci sono ritardi e il collo di bottiglia dovrebbe essere trovato ed eliminato, se possibile. Poiché le richieste sono accodate da Network Driver Interface Specification (NDIS) in questa implementazione, sarà sempre 0.

Alcune domande preliminari: 1) Il server ha un client SQL su Prod. macchina server impostata, giusto? Quindi, se fai la stessa query dal client che si trova sullo stesso computer, verrà completata in 2 secondi? Hai provato a farlo? Sono davvero 2 secondi? 2) Hai detto che la configurazione del tuo ambiente di produzione è stata modificata (o che il server di produzione è stato spostato su un'altra rete / ricostruzione del server totale eseguita), giusto? Qual è stato il tempo di consumo delle query nel vecchio ambiente di produzione?

Da qualsiasi altra casella sulla stessa rete ... la stessa query richiede 1 minuto, 8 secondi. 3) Stai dicendo che la query ritorna e viene consumata dal client, che si trova su qualsiasi macchina nella rete data (espandi la tua macchina specifica) in circa 70 secondi? Ho capito bene? 3.1 Per inciso, quali sono i tempi per il consumo di questa query, accettabili dall'azienda? 4) Tuttavia, si sta specificando che per un computer client specifico che si sta utilizzando il tempo di consumo dell'output della query è: Tempo di esecuzione client 15:30: 48 15 minuti? (e questa volta non è chiaramente accettabile)? Corretta? 5) quindi il problema è limitato a un singolo computer client? O a QUALSIASI macchina client / di livello intermedio ecc. (In un nuovo ambiente)? 6) qual è il ritardo mostrato dal ping? dal computer client al server? 7) Tu (o l'amministratore di rete) hai eseguito tracert in entrambi i modi (da client a server, da server a client)? Quanti luppoli? Qual è il tempo combinato? 8) La vecchia rete di produzione è viva? Puoi confrontare usando Ping e Traceroute - qual era il tempo e il luppolo tra client e server lì?

Per curiosità: questo è un esempio della query? o la formulazione esatta della query? La query NON contiene davvero la clausola WHERE? Concordo con me sul fatto che sia molto insolito. La tabella ha un indice cluster o è un heap? La tabella contiene quante righe tutto sommato? Il tavolo è fortemente frammentato? Per curiosità: perché SELEZIONARE TOP NNN? Perché non SET ROWCOUNT NNN - quindi SELEZIONA *? Questa query viene emessa quante volte dal cliente al giorno? 1? 100? 1MLN? I dati sottostanti sono statici o dinamici e sono cambiati molto? Quanto (0,01 percento al giorno? 1 percento al giorno? 10 percento al giorno?) L'output della query viene elaborato a livello di codice? (non da un utente?) Perché non è memorizzato nella cache / non memorizzato nel livello intermedio? grazie Alexei