Parametri di avvio di Tomcat 5.5 appropriati per ottimizzare JVM per un'applicazione Web heap a domanda estremamente elevata e di grandi dimensioni?

Question

Di recente abbiamo migrato un'applicazione Web di grandi dimensioni e molto richiesta su Tomcat 5.5 da Tomcat 4 e abbiamo notato alcuni comportamenti di rallentamento peculiari che sembrano essere correlati alle pause JVM. Al fine di eseguire la nostra applicazione e supportare un aumento del carico nel tempo su Tomcat 4, molti parametri JVM non così standard sono stati impostati e ottimizzati come indicato di seguito, e spero che qualcuno con esperienza di tuning Tomcat JVM possa commentare qualsiasi cosa che potrebbe essere dannosa a un'installazione Tomcat 5.5. Si noti inoltre che alcuni di questi potrebbero essere riportati dalle versioni precedenti di Java (stavamo eseguendo Tomcat 4 su Java 1.6 con questi parametri con successo per qualche tempo, ma alcuni potrebbero essere stati introdotti per aiutare la garbage collection su Java 1.4 che era la base di la nostra installazione di Tomcat 4 da molto tempo e ora potrebbe fare più male che bene).

Alcune note:

• L'impronta della memoria dell'applicazione è circa 1 GB, probabilmente leggermente oltre.
• La CPU non è un problema: tutte le macchine     al servizio dell'app (bilanciamento del carico)     lt &; CPU del 30%
• Un sacco di headroom sulla memoria fisica delle macchine.
• -XX: MaxPermSize = 512m era l'unico parametro aggiunto come parte dell'aggiornamento 5.5 ed era reattivo a un problema di spazio permgen esterno (che ha risolto).
• In esecuzione su Java 1.6, sistema operativo Solaris

-server -Xms1280m -Xmx1280m -XX: MaxPermSize = 512m -XX: ParallelGCThreads = 20 -XX: + UseConcMarkSweepGC -XX: + UseParNewGC -XX: SurvivorRatio = 8 -XX: TargetSurvivorRatio = 75 -XX: 70 XX: + AggressiveOpts -XX: + PrintGCDetails -XX: + PrintGCTimeStamps -XX: -TraceClassUnloading -Dsun.io.useCanonCaches = false -Dsun.net.client.defaultConnectTimeout = 60000 -Dsun.net.client.defaultReadTimeout = 60000

Answer 1

Uno dei campioni di Java, il blog di Kirk Pepperdine: http: //kirk.blog-city. com / how_to_cripple_gc_ergonomics.htm .
Citazione 1 " la documentazione GC ti dirà cosa influisce sull'impostazione, ma spesso senza dire quale sarà l'effetto. Il più grande indizio che hai preso la forcella sbagliata sulla strada è quando imposti esplicitamente un valore e poi dai un suggerimento all'ergonomia GC. Un altro indizio è se non hai una valida ragione per regolare un'impostazione. E solo perché alcuni cosiddetti esperti dicono che questa impostazione funziona meglio è solo il rumore, non il suono e certamente non un motivo. & Quot;

Citazione 2 " Come ho già detto in un precedente post sul blog, non toccare le manopole a meno che tu non abbia un'ottima ragione per farlo. Se devi toccare le manopole, prova leggermente usando solo quelle che aiutano l'ergonomia e non quelle che bloccano le cose paralizzando la capacità ergonomica di soddisfare i tuoi tempi di pausa e gli obiettivi di rendimento. & Quot;

Quindi, suggerirei di tornare alla pianura
-server -Xms1280m -Xmx1280m -XX: MaxPermSize = 512m -XX: + UseConcMarkSweepGC -XX: + PrintGCDetails -XX: + PrintGCTimeStamps -XX: -TraceClassUnloading -Dsun.io.useCanonCaches = false -Dsun =Confault_Confond = 600000000 -Dsun.net.client.defaultReadTimeout = 60000

Scopri se questo ti dà prestazioni migliori. Se sì, attenersi ad esso
A proposito, -XX: MaxPermSize = 378m ha avuto problemi?
Java 1.6 ha un'ergonomia molto migliore di 1.4. Potresti voler accordare meno di 1,4
A proposito, hai provato Tomcat 6? Tomcat 6 funziona molto meglio su Java 6 rispetto a Tomcat 5.5.

P.S: Sto usando Tomcat da un po 'di tempo e di solito provo a dare il regno libero di Sun JDK con poca sintonia qua e là.

Answer 2

ho appena trovato un webinar degli sviluppatori tomcat sull'ottimizzazione di tomcat: http://springsource.com/node/555 . un seguito al webinar: http://blog.springsource.com/2008/10/14/optimising-and-tuning-apache-tomcat-part-2/

BR,
~ A

Answer 3

Come qualcuno che è nel bel mezzo anche di questo, sicuramente non ho risposte definitive, soprattutto vista la specificità di questo genere di cose. Un buon riferimento, che probabilmente hai visto, è qui:

http://java.sun.com/javase/technologies /hotspot/gc/gc_tuning_6.html

Tuttavia, è un elenco piuttosto lungo di parametri jvm, il che suggerisce che probabilmente ci sono parametri non necessari impostati, soprattutto dato che hai diverse opzioni di debug su (PrintGCDetails, PrintGCTimeStamps, TraceClassUnloading) che non possono essere buone su un'app di produzione. 60 secondi di timeout potrebbero anche consumare risorse. & Quot; & Server quot; è predefinito ma non farà alcun danno.

Come funziona l'applicazione con parametri di ottimizzazione minimi (dimensione jvm, MaxPermSize)?

Answer 4

Potresti anche dare un'occhiata alla modifica del numero minimo / massimo di thread che Tomcat utilizzerà per gestire le richieste in conf/server.xml:

<Connector port="8080" maxThreads="150" minSpareThreads="25" maxSpareThreads="75" ...

Una regola empirica che avevo sentito in un precedente lavoro era che maxThreads dovrebbe essere uguale alla quantità di connessioni simultanee che ti aspetti di gestire. Non sono sicuro di quanto sia scientifica questa affermazione, anche se certamente penso che abbia senso dato che non vuoi che i clienti vengano bloccati in attesa che un thread si liberi per gestire la loro richiesta.

Answer 5

Potrebbe anche valere la pena sperimentare una JVM alternativa (come JRockit) per vedere se le differenze nel modello di garbage collection si adattano bene alla tua applicazione.