Performance Probleme während der Generierung

[a_dada]

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

[Peter_Jodeleit]

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.

[andre]

steht in top nicht eher:

CPU                            idle%

all   12.90%         86.97

somit wäre ja kaum last vorhanden!?

[a_dada]

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_HEAP	48 MB	30.308 MB	2.438 MB	31.125 MB
Par Eden Space		HEAP	1.953 GB	1.394 GB	1.953 GB	1.953 GB
Par Survivor Space		HEAP	1.953 GB	298.872 MB	1.953 GB	1.953 GB
CMS Old Gen		HEAP	9.766 GB	7.034 GB	5.859 GB	9.634 GB
CMS Perm Gen		NON_HEAP	500 MB	77.78 MB	500 MB	500 MB
Total		TOTAL	14.207 GB	8.825 GB	10.256 GB	14.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 ?

[feddersen]

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.

[SHeinrich]

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.