Diagnostica di elaborazione lenta di dati su un VM

Stiamo cercando di diagnosticare un VM apparentemente in esecuzione lentamente, dall'interno della VM.

La situazione:

  • Come faccio a rimuovere un piano difettoso specifico dalla cache di query di SQL Server?
  • Come get la richiesta url di visualizzazione apache in Top e PS?
  • Come aggiornare Windows Server 2008 R2 Core e verificarlo?
  • Prestazione lenta con authentication di base di IIS
  • W2K8 DNS - Ho impostato correttamente l'invio condizionale?
  • IIS 7 su SBS 2008 - il logging sta andando haywire
    • Abbiamo un'applicazione ospitata da IIS su Windows Server 2008R2 in esecuzione su una macchina virtuale a 6 core e da 12 GB.
    • Abbiamo un database in esecuzione su un cluster SQL Server 2008R2 SP3 (16 core,> 16 GB di RAM)
    • L'applicazione sta elaborando una coda di messaggi contro questo database. L'elaborazione consiste in gran parte di query / fetch e update, forse una dozzina di giro per un messaggio. A questo carico di lavoro viene assegnato un numero limitato di thread (3), che è sincrono, per cui i thread bloccano le risposte del database.
    • Il database è apparentemente leggero: solo pochi per cento del carico massimo della CPU.
    • A nostra conoscenza, sia il database che l'host VM sono nello stesso datacentre.

    Il database riport molto tempo trascorso in attesa della networking asynchronous IO, vale a dire. in attesa che l'applicazione consumi i dati. Anche l'applicazione VM è apparentemente leggermente caricata: ~ 20% di CPU. L'infrastruttura non è di properties; di noi e il nostro unico accesso è via RDP alla macchina virtuale e SQL Management Studio al cluster di database. Non abbiamo sufficienti privilegi per eseguire un profiler, anche se registriamo i contatori delle performance sia per il database che per la VM.

    Poche settimane fa, la velocità di elaborazione dei messaggi è scesa bruscamente dal 70-80%. Per quanto sappiamo, nulla è cambiato: l'applicazione non è stata modificata o riconfigurata ei contatori delle performance non indicano alcuna modifica delle caratteristiche di carico. I proprietari dell'infrastruttura hanno dichiarato che niente è cambiato alla loro fine.

    Come parte di un process di riavvio, è stata eseguita l'applicazione per ricaricare la coda dei messaggi. Ciò comport un semplice SELECT di poche centinaia di migliaia di righe che vengono poi lette in strutture di memory. Il database ha servito il SELECT in pochi secondi ma poi ha aspettato ~ 10 minuti sull'applicazione di leggere i risultati. Si tratta di un'operazione a filettatura singola che comport una semplice deserializzazione e non richiede più di un paio di minuti su questo hardware.

    La mia teoria attuale è che la latenza di networking è aumentata in qualche modo, ma ping solo riferisce '<1ms' e in each caso non abbiamo una linea di base. hrPing riport i tempi tra 0,5 e 2 ms dal server dell'applicazione al database.

    Un'altra possibilità è che la vera capacità della CPU del VM abbia in qualche modo diminuito, ma mi aspetto che questo possa manifestarsi come un aumento del carico "apparente".

    Ci sono altre vie di indagine disponibili?

    2 Solutions collect form web for “Diagnostica di elaborazione lenta di dati su un VM”

    Io non sono esperto quello che mai, ma qui sono i miei 2 centesimi:

    1) Eliminare il dubbio:

    Effettuate 2 grandi trasferimenti di cartelle dal DB al server App e l'altra direzione intorno a 500 MB. 1 La cartella deve contenere un singolo file binario di 500 MB. La seconda cartella deve contenere migliaia / milioni di file tutti in 1KB o less e vedere le performance di networking per each caso. Il primo vi mostrerà una simulazione di basso stream di payload con un basso numero di pacchetti, il secondo (che imiterà le transactions DB) vi mostrerà una simulazione di stream payload basso con un basso costo di pacchetti. Questo vi darà un'idea di quale tipo di ambiente di networking esistono e se le tue preoccupazioni di networking sono vere. Tieni presente che la capacità di commutazione non è solo la velocità della port. 10 MB / s in 10 pacchetti NON è lo stesso carico sull'interruttore (utilizzo dell'utilizzo CPU) come 10 MB / s arrivano in 100.000 pacchetti … L'interruttore deve trasferire each singolo pacchetto indipendentemente dal carico utile e si potrebbe get la saturazione della networking facilmente se non hai abbastanza capacità di commutazione (pacchetti al secondo). Ora che probabilmente (99,9%) non sarà il caso in un centro dati, ma non saprai mai sicuro finché non provate

    2) Configurazione dell'applicazione secondo punto:

    Spero che tu sia la tua applicazione e lo hai configurato correttamente, se non, la maggior parte dei driver JDBC ha Batch Transactions, che talvolta se non esplicitamente definito nel tuo provider di persistenza, può causare un comportmento simile a quello che hai sperimentato (l'applicazione in attesa di un determinato importo di scrive prima di effettivamente commettere una transazione o in attesa di un numero di letture prima di eseguire la query). Anche allora, queste operazioni batch hanno timeout che sono nell'ordine di un secondo o 2, quindi commettono le transactions se la coda di batch se piena o less

    3) Terzo punto Cloud Contract Fine Print:

    Ora poiché questo è un provider di nubi, controlla la printing fine. Il tipo di transazione che si sta riferendo comporterà un numero elevato di transactions sul bus host. La maggior parte dei fornitori ora limita l'utilizzo del bus per VM, ma non esattamente lo pubblicizza (trovenetworking un limite sui gt / s). Quindi, quando i dati arrivano, c'è un enorme impatto che lo trasferisce dall'Interfaccia di networking attraverso il bus alla RAM di VMs (tenete presente che i VM non sono abbinati alle risorse in modo da non stare le stesse parti e come tale un semplice il carico di lavoro della networking varia). Un buon indicatore che si sta limitando è quello di avere una connessione 1G, cercando di trasferire un file binario contiguo a livello locale senza carico e mai raggiungere 50 ~ 60 MB / s (450-480 Mbps)

    Comunque spero che aiuta

    Grazie per tutti i suggerimenti! La situazione è stata definitivamente risolta, anche se non ci è stato detto se fosse l'host VM o la networking che non funzionava correttamente, né esattamente quello che è stato fatto per risolvere il problema.

    Nel process di risoluzione dei problemi abbiamo scritto una semplice applicazione per profilare determinate operazioni di database e cercare di individuare il modo esatto in cui la piattaforma non era sana:

    https://github.com/BluewireTechnologies/db-latency

    In sostanza, il statistics time del database ha richiesto 0ms trascorso mentre occasionalmente il client SQL era abbastanza sicuro che avrebbe passato qualche centinaio di millisecondi in attesa di eseguire ExecuteReader () per tornare, indicando un problema di networking o forse un VM affamato di timeslices. Questi picchi affliggerebbero circa il 5% dei viaggi di andata del database e dare alle operazioni normalmente istantanee un'elevata probabilità di prendere più secondi per completare.

    Una delle persone tecniche del cliente ha compilato e utilizzato lo strumento stesso. Ha confermato le nostre scoperte e li ha trasmessi alla squadra appropriata, e poche ore dopo il problema è stato risolto.

    Sembra probabile che sia stato, come tutti sospettati, un problema di networking!

    Suggerimenti per Linux e Windows Server, quali Ubuntu, Centos, Apache, Nginx, Debian e argomenti di rete.