Costo delle prestazioni della creazione di profili di un'applicazione Web in produzione

Question

Sto tentando di risolvere i problemi di prestazioni con un'applicazione Web Tomcat Java grande e complessa. Il problema più grande al momento è che, di volta in volta, l'utilizzo della memoria aumenta e l'applicazione non risponde. Ho risolto tutto ciò che posso correggere con i profiler di registro e l'analisi bayesiana dei file di registro. Sto pensando di eseguire un profiler sul server tomcat di produzione.

Nota per il lettore con delicata sensibilità:

Comprendo che alcuni potrebbero trovare offensiva l'idea stessa di creare un profilo di un'app di produzione. Ti assicuriamo che ho esaurito la maggior parte delle altre opzioni. Il motivo per cui sto considerando questo è che non ho le risorse per duplicare completamente la nostra configurazione di produzione sul mio server di prova e non sono stato in grado di causare i guasti di interesse sul mio server di prova.

Domande:

Sto cercando risposte che funzionano sia per un'applicazione Web Java in esecuzione su Tomcat, sia per rispondere a questa domanda in modo agnostico in termini di lingua.

• Quali sono i costi di performance della profilazione?
• Qualche altro motivo per cui è una cattiva idea connettere e profilare in remoto un'applicazione Web in produzione (strane modalità di errore, problemi di sicurezza, ecc.)?
• Quanto ha effetto la profilazione sulla stampa del foot memory?
• In particolare, esistono strumenti di profilazione Java che hanno costi di prestazione molto bassi?
• Qualche strumento di profilazione java progettato per la profilazione di applicazioni web?
• Qualcuno ha benchmark sui costi di performance della profilazione con visualVM?
• Su quali dimensioni applicazioni e set di dati è possibile ridimensionare visualVM?

Answer 1

OProfile e il suo antenato DPCI sono stati sviluppati per la profilazione dei sistemi di produzione. Il sovraccarico per questi è molto basso e profilano il tuo sistema completo , incluso il kernel, quindi puoi trovare problemi di prestazioni nella VM e nel kernel e nelle librerie.

Per rispondere alle tue domande:

1. Overhead: si tratta di campionati profiler, ovvero generano timer o contatore delle prestazioni si interrompe a intervalli regolari e danno un'occhiata al codice attualmente in esecuzione. Lo usano per creare un istogramma di dove trascorri il tuo tempo e l'overhead è molto basso (l'1-8% è ciò che rivendicano ) per intervalli di campionamento ragionevoli.

   Dai un'occhiata a questo grafico della frequenza di campionamento rispetto alle spese generali per OProfile. Puoi regolare la frequenza di campionamento per un sovraccarico più basso se le impostazioni predefinite non sono di tuo gradimento.

2. Utilizzo in produzione: L'unica avvertenza nell'uso di OProfile è che dovrai installarlo sul tuo computer di produzione. Credo che ci sia il supporto del kernel in Red Hat da RHEL3, e sono abbastanza sicuro che altre distribuzioni lo supportino.

3. Memoria: non sono sicuro di quale sia l'esatta impronta di memoria di OProfile, ma credo che mantenga buffer relativamente piccoli e li scarichi per registrare i file di tanto in tanto.

4. Java: OProfile include agenti di profilazione che supportano Java e sono a conoscenza del codice in esecuzione in JIT. Quindi sarai in grado di vedere le chiamate Java, non solo le chiamate C nell'interprete e JIT.

5. App Web: OProfile è un profiler a livello di sistema, quindi non è a conoscenza di cose come sessioni, transazioni, ecc. che un'app Web avrebbe.

   Detto questo, si tratta di un sistema completo , quindi se il tuo problema di prestazioni è causato da cattive interazioni tra il sistema operativo e JIT, o se si trova in una libreria di terze parti, " Sarò in grado di vederlo, poiché OProfile profila il kernel e le librerie. Questo è un vantaggio per i sistemi di produzione, poiché è possibile rilevare problemi dovuti a configurazioni errate o particolari dell'ambiente di produzione che potrebbero non esistere nel proprio ambiente di test.

6. VisualVM: non sono sicuro di questo, poiché non ho esperienza con VisualVM

Ecco un tutorial sull'uso di OProfile per trovare colli di bottiglia delle prestazioni .

Answer 2

Ho usato YourKit per profilare le app in un ambiente di produzione ad alto carico e, sebbene ci fosse sicuramente un impatto, era facilmente accettabile. Yourkit fa molto di poterlo fare in modo non -invasivo, come disattivare selettivamente alcune funzionalità di profilazione che sono più costose (è una scala mobile, in realtà).

Il mio aspetto preferito è che puoi eseguire la VM con l'agente YourKit in esecuzione e non ha alcun impatto sulle prestazioni. è solo quando colleghi la GUI e inizi a creare profili che ha un effetto.

Answer 3

Non c'è niente di sbagliato nel profilare le app di produzione. Se lavori su applicazioni distribuite, ci sono momenti in cui si verifica un'eccezione outofmemory in uno scenario di probabilità davvero unico che è molto difficile da riprodurre in un ambiente dev / stage / uat.

Puoi provare a usare i profiler personalizzati ma se hai fretta e collegare / impostare un profiler su una scatola di produzione richiederà tempo, puoi anche usare jvm per eseguire un dump della memoria (il dump della memoria jvms ti dà anche thread discarica)

1. È possibile attivare la generazione automatica dalla riga di comando JVM, utilizzando la seguente opzione: -XX: + HeapDumpOnOutOfMemoryError

2. Il progetto Eclipse Memory Analyzer ha una funzione molto potente chiamata "raggruppa per valore", che consente di creare una query oggetto e raggruppare le istanze per un valore di campo. Ciò è utile nel caso in cui ci siano molte istanze che contengono un set più piccolo di valori possibili e si può vedere quali valori vengono maggiormente utilizzati. Questo mi ha davvero aiutato a capire alcuni dump di memoria complessi, quindi ti consiglio di provarlo.

Answer 4

Puoi anche prendere in considerazione l'utilizzo di uno dei moderni HotSpot JVM - Java Flight Recorder e Java Mission Control . È un insieme di strumenti che consente di raccogliere informazioni di runtime di basso livello con un sovraccarico della CPU di circa il 5% (non posso comunque dimostrare l'ultima affermazione, questa è la dichiarazione dell'ingegnere Oracle che ha presentato la funzionalità e la demo live).

È possibile utilizzare questo strumento purché l'applicazione esegua 1_7u40 JVM o versione successiva. Per abilitare la raccolta di informazioni di runtime, è necessario avviare JVM con flag particolari:

  

Per impostazione predefinita, JFR è disabilitato nella JVM. Per abilitare JFR, è necessario avviare l'applicazione Java con l'opzione -XX: + FlightRecorder . Poiché JFR è una funzione commerciale, disponibile solo nei pacchetti commerciali basati su piattaforma Java, Standard Edition (Oracle Java SE Advanced e Oracle Java SE Suite), è inoltre necessario abilitare le funzionalità commerciali utilizzando -XX: + UnlockCommercialFeatures opzioni.

(Citato http: // docs. oracle.com/javase/8/docs/technotes/guides/jfr/about.html#sthref7 )

Ho aggiunto questa risposta in quanto questa è un'opzione praticabile per la profilazione nell'IMO di produzione.

Inoltre è presente un Plug-in Eclipse che supporta JFR e JMC e in grado di visualizzare informazioni di facile utilizzo.

Answer 5

Gli strumenti sono notevolmente migliorati nel corso degli anni. Al giorno d'oggi, la maggior parte delle persone che hanno esigenze come queste utilizzano uno strumento che si collega all'API di strumentazione Java anziché all'API di profilazione. Sicuramente ci sono altri esempi, ma NewRelic e AppDynamics viene in mente. Le soluzioni basate sulla strumentazione di solito vengono eseguite come agenti nella JVM e raccolgono costantemente dati. Riferiscono i dati a un livello superiore (transazione commerciale, transazione web, transazione di database) rispetto al vecchio approccio di profilazione e consentono di scavare più a fondo (fino al metodo o alla linea) se necessario. Puoi persino impostare il monitoraggio e gli avvisi, in modo da poter monitorare / avvisare metriche come i tempi di caricamento della pagina e le prestazioni rispetto agli SLA. Con questi fantastici strumenti, non dovresti davvero avere motivo di gestire un profiler in produzione più a lungo. Il costo per eseguirle è trascurabile.