2015-02-24 10 views
6

Sto utilizzando Jmeter per iniettare il carico di lavoro a un'applicazione distribuita su un'istanza AWS EC2. Il test deve essere molto ampio: dura 10 ore e il profilo del carico di lavoro ha una forma bimodale con un pitch di circa 2600 richieste in 5 minuti. In realtà, ho un'istanza m3.xlarge in cui è distribuita l'applicazione e 8 istanze m3.xlarge ciascuna che esegue un'istanza jmeter. Con uno script python il carico di lavoro da iniettare viene diviso tra le 8 istanze del client, così, ad esempio, se il carico di lavoro originale da iniettare 800 richieste, ogni istanza di jmeter inietterà 100 richieste. Il test completo, come ho detto, dura 10 ore ed è diviso in timestep di 5 minuti ciascuno. Ogni 5 minuti viene applicata una piccola variazione del carico di lavoro. In realtà ottengo da ogni istanza di jmeter java.lang.OutOfMemoryError: il limite di sovraccarico di GC ha superato l'errore immediatamente dopo l'avvio del test e nessuna richiesta arriva all'applicazione. Ho letto un sacco on-line e su StackOverflow, e ho concluso il possibile errore potrebbe essere:Jmeter java.lang.OutOfMemoryError: limite di overhead GC superato

  • JMV dimensione heap troppo bassa> Ho risolto impostando la seguente nei file jmeter.bat in ogni istanza jmeter:

    set MUCCHIO = -Xms4g -Xmx4g

    NOVITÀ = -XX: newSize = 4g XX: MaxNewSize = 4g

  • alcuni errori nel codice che si traduce in un uso continua inutile del garbage collector. Quindi rimuovo dal mio test tutti gli ascoltatori jmeter. In particolare stavo usando TableVisualizer, ViewResultsFullVisualizer, StatVisualizer e GraphVisualizer.

Ad ogni modo il problema persiste. Non ho davvero idea di come risolverlo. So che 10 ore di test con 2600 richieste di pitch potrebbero essere un test molto pesante, ma penso che ci dovrebbe essere un modo per farlo. Sto usando l'istanza di EC2 m3.xlarge in modo che potrei anche aumentare la dimensione dell'heap a 8G se potrebbe essere utile, o dividere il carico di lavoro tra un numero ancora maggiore di client poiché sto usando istanze spot, quindi non pagherò molto di più, ma dal momento che ho già raddoppiato il numero di istanze client da 4 a 8 per risolvere il problema e non funziona, sono un po 'confuso e desidero conoscere i suggerimenti prima di continuare ad ottenere sempre più risorse. Grazie mille in anticipo.

+0

Sì, JMeter è un noto gobbler delle risorse. Arresta definitivamente tutti i componenti che accumulano dati durante l'esecuzione della sessione di test. Dagli tutto il mucchio che puoi. –

+0

È corretto modificare bot i parametri HEAP e NEW in jmeter.bat su 2/4/8g? –

+0

I parametri 'NEW' sembrano la cosa sbagliata da fare.Se stai ricevendo OOME, significa che ci sono molti * vecchi * oggetti da conservare, e quei parametri 'NEW' impongono alla JVM di trattare tutto come nuovi oggetti. Ciò significa che i GC minori saranno molto lenti. Lasciare che la JVM ridimensioni dinamicamente le generazioni è solitamente l'opzione migliore. –

risposta

5

Le impostazioni heap guardano storto: set MUCCHIO = -Xms4g -Xmx4g set NUOVO = -XX: newSize = 4g XX: MaxNewSize = 4g

Il nuovo è uguale alla dimensione heap, questo è sbagliato. Commenta NUOVA parte prima.

Si può fare un ps -eaf | grep java e mostrare l'output?

e di controllare anche rispettare queste raccomandazioni:

infine, mostrano una panoramica del vostro programma di test e, il numero di thread che si avvia.