Help

Questions & Answers

a_dada
I'm new here
‎10-31-2012 05:48 AM

Performance Probleme während der Generierung

Hallo,

während eine Generierung läuft ist das Arbeiten in FirstSpirit bei uns sehr träge.

Teilweise dauert es 10-30 Sekunden, bis Eingaben im JavaClient angenommen werden.

Bei nährerer Untersuchung dieser Problematik haben wir festgestellt, dass FirstSpirit nur einen einzigen CPU Core verwendet und dieser permanent auf 100% läuft.

Ausgabe: mpstat -P ALL 1

12:07:30 PM  CPU    %usr   %nice    %sys %iowait    %irq   %soft  %steal  %guest   %idle
12:07:31 PM  all   12.90    0.00    0.13    0.00    0.00    0.00    0.00    0.00   86.97
12:07:31 PM    0  100.00    0.00    0.00    0.00    0.00    0.00    0.00    0.00    0.00

12:07:31 PM    1    0.00    0.00    0.00    0.00    0.00    0.00    0.00    0.00  100.00

12:07:31 PM    2    0.00    0.00    0.00    0.00    0.00    0.00    0.00    0.00  100.00

12:07:31 PM    3    0.00    0.00    0.00    0.00    0.00    0.00    0.00    0.00  100.00

12:07:31 PM    4    0.00    0.00    0.00    0.00    0.00    0.00    0.00    0.00  100.00

12:07:31 PM    5    0.00    0.00    0.00    0.00    0.00    0.00    0.00    0.00  100.00

12:07:31 PM    6    0.00    0.00    0.00    0.00    0.00    0.00    0.00    0.00  100.00

12:07:31 PM    7    0.00    0.00    1.00    0.00    0.00    0.00    0.00    0.00   99.00

Warum nutzt FS4 nicht mehrere Cores ?

Viele Grüße,

Andreas Dada

Labels
0 Kudos
5 Replies
Peter_Jodeleit
Crownpeak employee
Crownpeak employee
‎10-31-2012 08:08 AM

Warum nutzt FS4 nicht mehrere Cores ?

Das muss ein Konfigurationsproblem in eurer Umgebung sein.

Ich vermute, das "single threaded garbage collecting" eingeschaltet ist und der Server zu wenig Speicher hat, so dass der garbage collector ständig läuft.

Peter
0 Kudos
andre
I'm new here
‎10-31-2012 08:20 AM

steht in top nicht eher:

CPU                            idle%

all   12.90%         86.97

somit wäre ja kaum last vorhanden!?

0 Kudos
a_dada
I'm new here
In response to Peter_Jodeleit
‎11-01-2012 04:42 AM

Der Server hat 48GB RAM und 8 Cores (Intel XEON E5507) und es laufen darauf zwei Projekte (16GB und 27GB Speicherplatz).

Hier die Zahlen aus dem Monitoring zum VM Speicher:

Code Cache


NON_HEAP48 MB30.308 MB2.438 MB31.125 MB
Par Eden Space


HEAP1.953 GB1.394 GB1.953 GB1.953 GB
Par Survivor Space


HEAP1.953 GB298.872 MB1.953 GB1.953 GB
CMS Old Gen


HEAP9.766 GB7.034 GB5.859 GB9.634 GB
CMS Perm Gen


NON_HEAP500 MB77.78 MB500 MB500 MB
Total


TOTAL14.207 GB8.825 GB10.256 GB14.059 GB

Hier mal ein Auszug aus unserer fs-wrapper.conf

# Java command (JDK needed, not JRE)

# absolute path or just "java" when environment variable PATH is set correctly

wrapper.java.command=/usr/java/jdk1.6.0_23/bin/java

# Maximum Java Heap Size

#   set in MByte with maxmemory=MBYTESNUMBER

#   set in percent of total physical RAM with maxmemory.percent=PERCENTNUMBER

wrapper.java.maxmemory=16000

# Initial Java Heap Size.

# Same syntax as Maximem Java Heap Size.

# Set to value of about 75% of Maximum Java Heap Size.

wrapper.java.initmemory=12000

# Java parameters.

# Continuous enumeration is needed!

# Empty values after the "=" sign are allowed.

wrapper.java.additional.1=-Djava.awt.headless=true

wrapper.java.additional.2=-Djava.security.auth.login.config=conf/fs-jaas.conf

wrapper.java.additional.3=-Djava.security.policy=conf/fs-server.policy

wrapper.java.additional.4=-Dfile.encoding=UTF-8

wrapper.java.additional.5=-Xshare:off

wrapper.java.additional.6=-Djava.net.preferIPv4Stack=true

wrapper.java.additional.7=

wrapper.java.additional.8=

wrapper.java.additional.9=

# Select 64bit VM on Solaris with -d64:

#wrapper.java.additional.10=-d64

wrapper.java.additional.10=

# Java parameters for garbage collection

# value of -Xmn should be set to 50% of wrapper.java.initmemory

wrapper.java.additional.11=-Xmn6000m

wrapper.java.additional.12=-XX:PermSize=500m

wrapper.java.additional.13=-XX:MaxPermSize=500m

wrapper.java.additional.14=-XX:+DisableExplicitGC

wrapper.java.additional.15=-XX:SoftRefLRUPolicyMSPerMB=20

wrapper.java.additional.16=-XX:+UseParNewGC

wrapper.java.additional.17=-XX:+UseConcMarkSweepGC

wrapper.java.additional.18=-XX:+CMSIncrementalMode

wrapper.java.additional.19=-XX:+CMSParallelRemarkEnabled

wrapper.java.additional.20=-XX:+CMSClassUnloadingEnabled

wrapper.java.additional.21=-XX:SurvivorRatio=1

wrapper.java.additional.22=-XX:TargetSurvivorRatio=80

wrapper.java.additional.23=-XX:InitialTenuringThreshold=15

wrapper.java.additional.24=-XX:-UseLargePages

wrapper.java.additional.25=-Djava.rmi.dgc.leaseValue=3600000

wrapper.java.additional.26=-Dsun.rmi.dgc.server.gcInterval=3600000

wrapper.java.additional.27=-Dsun.rmi.dgc.client.gcInterval=3600000

wrapper.java.additional.28=

wrapper.java.additional.29=

wrapper.java.additional.30=

wrapper.java.additional.31=

Das Verwenden von "UseParNewGC" hat anscheinend eine Verbesserung gebracht.

Im Admin-Handbuch steht, dass man bei Werten für maxmemory > 10GB vorsichtig sein sollte.

Welche Optimierungen können noch vorgenommen werden ?

0 Kudos
feddersen
Community Manager
Community Manager
In response to a_dada
‎11-22-2012 12:41 PM

Sie können das Garbage-Collection-Log (gc-log) aktivieren und dieses dann analysieren. Sofern es längere GC-Pausen zeigt, sind sicherlich noch Optimierungen möglich. Ggf. kann da auch unser Helpdesk bzw. Professional Service unterstützen.

0 Kudos
SHeinrich
Returning Observer
In response to feddersen
‎01-29-2014 04:44 AM

Im gleichen Zusammenhang:

Was genau ist der "CMS OLD GEN"? Hat bestimmt was mit ´Generierung zu tun. Ist es normal, dass dieser stetig wächst? Wir hatten jetzt den Server paar Mal so träge, dass wir ein Neustart durchführen mussten. Dabei war dieser Speicher voll.

0 Kudos