java - last - www tomcat




Parametri di avvio appropriati di Tomcat 5.5 per ottimizzare JVM per applicazioni Web di grandi dimensioni e di grandi dimensioni? (4)

Di recente, Tomcat 4 ha migrato un'applicazione Web di grandi dimensioni e molto richiesta a Tomcat 5.5 e abbiamo notato alcuni comportamenti peculiari di rallentamento che sembrano essere correlati alle pause JVM. Per poter eseguire la nostra applicazione e supportare un carico maggiore nel tempo su Tomcat 4, molti parametri JVM non standard sono stati impostati e ottimizzati come di seguito, e spero che qualcuno con l'esperienza di tuning JVM di Tomcat possa commentare qualsiasi cosa che potrebbe essere dannosa a un'installazione di Tomcat 5.5. Si noti inoltre che alcuni di questi potrebbero essere trasferiti 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 alla base di la nostra installazione di Tomcat 4 per un lungo periodo di tempo e potrebbe causare più danni che benefici).

Alcune note:

  • Il footprint della memoria dell'applicazione è di circa 1 GB, probabilmente leggermente superiore.
  • La CPU non è un problema: tutte le macchine che servono l'app (bilanciate dal carico) sono <30% della CPU
  • Un sacco di spazio sulla memoria fisica sulle macchine.
  • -XX: MaxPermSize = 512m è stato l'unico parametro aggiunto come parte dell'aggiornamento 5.5 ed è stato reattivo a un problema permgen spazio outofmemory (che ha risolto).
  • Funzionante 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: MaxTenuringThreshold = 0 -XX: + AggressiveOpts -XX: + PrintGCDetails -XX: + PrintGCTimeStamps -XX: -TraceClassUnloading -Dsun.io.useCanonCaches = false -Dsun.net.client.defaultConnectTimeout = 60000 -Dsun.net.client.defaultReadTimeout = 60000


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


Potresti anche dare un'occhiata al cambiamento del numero minimo / massimo di thread che Tomcat userà 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 il maxThreads doveva essere uguale alla quantità di connessioni simultanee che ci si aspetta di gestire. Non sono sicuro di quanto scientifica sia questa affermazione, anche se certamente penso che abbia senso non volere che i client siano bloccati in attesa che una discussione si liberi di gestire la loro richiesta ..


Uno dei Java Champions, il blog di Kirk Pepperdine: http://kirk.blog-city.com/how_to_cripple_gc_ergonomics.htm .
Quota 1 "La documentazione GC ti dirà che cosa influisce l'impostazione, ma spesso senza dire quale sarà l'effetto. Il più grande indizio che hai preso la forcella sbagliata è quando imposti un valore in modo esplicito e poi dai un suggerimento a GC ergonomia Un altro indizio è che se non si ha un valido motivo per regolare un'impostazione e solo perché alcuni cosiddetti esperti dicono che questa impostazione funziona meglio è solo rumore, non suono e sicuramente non una ragione. "

Citazione 2 "Come ho affermato in un post precedente, non toccare le manopole a meno che non si abbia una buona ragione per farlo: se si devono toccare le manopole, trarle leggermente usando solo quelle che aiutano l'ergonomia e non quelle che annulla la capacità di ergonomia paralizzante per soddisfare i tuoi tempi di pausa e gli obiettivi di throughput ".

Quindi, ti suggerirei di tornare in chiaro
-server -Xms1280m -Xmx1280m -XX: MaxPermSize = 512m -XX: + UseConcMarkSweepGC -XX: + PrintGCDetails -XX: + PrintGCTimeStamps -XX: -TraceClassUnloading -Dsun.io.useCanonCaches = false -Dsun.net.client.defaultConnectTimeout = 60000 -Dsun.net.client.defaultReadTimeout = 60000

Scopri se ti dà prestazioni migliori. Se sì, attenersi ad esso
BTW, did -XX: MaxPermSize = 378m ha qualche problema?
Java 1.6 ha un'ergonomia molto migliore di 1.4. Potresti volerlo accordare meno di 1.4
A proposito, hai provato Tomcat 6? Tomcat 6 funziona molto meglio su Java 6 di Tomcat 5.5.

PS: Sto usando Tomcat da un po 'di tempo e di solito cerco di dare il regno libero di JDK del sole con poca accordatura qua e là.






performance