ASP.NET CPU elevata Porta i server in ginocchio

8

Ok, la nostra nuova build prevede picchi di CPU del 100% su ciascun server a intervalli casuali. Per lunghi periodi di tempo, il sito non risponde completamente: ciò avverrà nelle ore di punta, poiché persone di diversi paesi accedono al sito, ecc.

Abbiamo esaminato perfmom, profiler di memoria, profiler CLR, profiler sql, profiler Red gate ants, provato i test di carico in UAT, ma non siamo nemmeno riusciti a riprodurre il problema. Ciò potrebbe significare che solo migliaia di utenti che colpiscono il sito live lo fanno accadere.

Un modello che abbiamo notato è che il nuovo codice - la build non funzionante - utilizza effettivamente notevolmente meno thread.

Stiamo anche usando la molla per IOC - ha una reputazione da letto?

A peggiorare le cose, non possiamo implementare per vivere a causa dell'impatto sul business, quindi non possiamo restringere il problema al sottoinsieme delle nuove funzionalità che abbiamo aggiunto.

Siamo veramente distrutti: qualcuno ha delle cicatrici da battaglia che potrebbero salvarci qualche vita?

Cosa segnalano i sensori di temperatura? Mi chiedo se il tuo alimentatore non può tenere il passo. (Non

— ho

2

Quando dici di far cadere il server puoi aggiungere ulteriori dettagli, è BSOD? Vuoi dire che si riavvia o forse un riavvio del dominio dell'app.

Non è affatto possibile che un " picco del 100% della CPU " possa "abbattere" il server. Dovrebbe essere ancorato al 100% per un bel po 'di tempo, insieme a problemi con la dissipazione del calore.

— Andrew Barber,

1

Cosa sta facendo?? Quale processo utilizza la CPU al picco? Questa è la domanda più importante

— Aliostad,

Ho aggiornato la mia domanda: è meglio? Grazie per -1 :)

3

Suggerisco di fare dump della memoria e analizzarli in WinDdg con Sos. Ho risolto alcuni problemi sulla nostra produzione che probabilmente non sarei in grado di diagnosticare senza WinDbg.

Tess Fernandez ha un ottimo blog in cui puoi imparare come analizzare i dump della memoria.

quel blog è una risorsa eccellente e lo stiamo usando. Il nostro problema è che non possiamo ricreare nuovamente il problema e ottenere i dump.

1

Per ricreare il problema, è possibile martellare il sistema di test con jmeter ( jmeter.apache.org ) e ab ( httpd.apache.org/docs/2.0/programs/ab.html ). Con questi, multicore, una LAN veloce e alcuni colleghi, dovresti essere in grado di stressare il server abbastanza.

— Romano,

1

Ciò è in genere causato dalla pulizia di oggetti di lunga durata nel GC ( stackoverflow ha riscontrato questo problema, vedere collegamento ). Stai memorizzando molte raccolte di oggetti nella cache o nella sessione?

Assault di GC

Ti consiglio anche di creare e configurare un nuovo server in produzione da testare. Se hai una follia casuale e non sai perché e non riesci a riprodurla, vorrei puntare il dito sull'hardware o sulla configurazione, non sul codice.

— Rick Schott
fonte

Non possiamo pubblicare alcun nuovo codice perché aggiunge funzionalità di notizie. Quando il codice era attivo, l'utilizzo del GC era lo stesso, incluso per la generazione 2. Grazie, però, hai altri suggerimenti?

Non è impossibile, ma l'hardware e la configurazione sono quasi uguali all'ultima distribuzione a cui siamo tornati e sta funzionando con successo.

1

È un server virtuale con risorse condivise o un server fisico? Se è il primo, forse potresti guardare dedicando risorse a questo server. In bocca al lupo...

— Nigel Findlater
fonte

0

Prova a usare a cache servercome frontend come Apache Traffic Server (ATS).

Anche se questo non risolverà il problema, potrebbe essere utile identificarlo perché allo stesso tempo sposterai il carico potenzialmente dannoso dal back-end (vedendo se anche il front-end ha problemi) e renderai le cose meno riscaldate sul back-end, quindi sarà più facile vedere cosa c'è che non va.

— Gil
fonte

0

Cercare di indovinare l'errore senza i dati è inutile. Sì, qualcuno su StackOverflow o nel tuo team di ingegneri potrebbe essere fortunato, ma questa è solo una cattiva ingegneria e non puoi pianificare il tempo che impiegherai a provare ogni ipotesi e se anche il tuo troverebbe il problema.

Devi riproporre il problema. Jmeter è un buon inizio per la sua ampiezza, ma non possiamo raccomandare lo strumento giusto senza conoscere la nostra architettura.
La registrazione specialmente nel tuo livello di applicazione è un must. È possibile abilitare le tracce IIS per prestazioni lente, ma i muppet di Microsoft lo hanno fatto in modo da non poter catturare l'intero flusso della pipeline quando è lento. Se è così difficile replicare, ti piacerebbe davvero alcuni registri che ti aiutino a restringere il punto in cui si trova il problema. (come oh, è ogni volta che chiamiamo questo proc memorizzato).

La CPU al 100% è un po 'sospetta, nel senso che è improbabile che sia I / O (a condizione che il db sia un'altra scatola, un database lento non dovrebbe causare una CPU al 100% sui server web). Devi guardare più vicino a casa.

— M Afifi
fonte