Hello,
after a long time to search where the 100% percent cpu consumtion come from
i had found it out.
Our backend is a Oracle 10g database which is bounded by Oracle NG Plugin to
geoserver.
After a long period of WFS-Requests the java heap runs into a extensive GC.
The printout of jmap show full memory in Edge and old Generations:
./jmap -heap 7881
Attaching to process ID 7881, please wait...
Debugger attached successfully.
Server compiler detected.
JVM version is 19.1-b02
using thread-local object allocation.
Parallel GC with 2 thread(s)
Heap Configuration:
MinHeapFreeRatio = 40
MaxHeapFreeRatio = 70
MaxHeapSize = 629145600 (600.0MB)
NewSize = 1048576 (1.0MB)
MaxNewSize = 4294901760 (4095.9375MB)
OldSize = 4194304 (4.0MB)
NewRatio = 2
SurvivorRatio = 8
PermSize = 16777216 (16.0MB)
MaxPermSize = 67108864 (64.0MB)
Heap Usage:
PS Young Generation
Eden Space:
capacity = 137101312 (130.75MB)
used = 137101312 (130.75MB)
free = 0 (0.0MB)
100.0% used
From Space:
capacity = 34340864 (32.75MB)
used = 0 (0.0MB)
free = 34340864 (32.75MB)
0.0% used
To Space:
capacity = 36306944 (34.625MB)
used = 0 (0.0MB)
free = 36306944 (34.625MB)
0.0% used
PS Old Generation
capacity = 419430400 (400.0MB)
used = 419430400 (400.0MB)
free = 0 (0.0MB)
100.0% used
PS Perm Generation
capacity = 46137344 (44.0MB)
used = 46061712 (43.92787170410156MB)
free = 75632 (0.0721282958984375MB)
99.83607205477628% used
After the GC had run the Old generation will only reduced to
99.99998664855957% used and new will stay unchanged by 100.0% used.
It looks like that the Oracle NG Plugin has a memory leak. I expect that
there a many active referenced
objects in memory which are not needed to run the aktive programm state.
If i print the thread info, there is one thread (not the specific GC
threads) that use a lot of time to make
PSMarkSweep GC:
thread information for 7888:
PID (TID) (PPID) : 7881 (7888) (1)
Process status : Running, Multi Threaded
Running Time : Tue May 24 08:34:06 2011 (02:37:43)
CPU Time : 00:39:48
CPU usage : 25.2%
Process flags : Forked but no Exec
User:Group : geoserver(1001):geoserver(1002) (-M)
Priority : 0
Last System Function: - (-)
CPU ID : 1
Instruction Pointer : 0xb77d02f0
Stack Pointer : 0x8a33bdf4
Stack Bottom : 0xbfff7b30
Additional Info : Environment (-e), Stack Trace (-S), Registers (-R),
Signals (-g)
---------------- Stack Trace --------------
#0 0xb75c9118 in instanceKlass::oop_adjust_pointers () from
/usr/java/jdk1.6.0_24/jre/lib/i386/server/libjvm.so
#1 0xb7821728 in PSMarkSweepDecorator::adjust_pointers () from
/usr/java/jdk1.6.0_24/jre/lib/i386/server/libjvm.so
#2 0xb7821041 in PSMarkSweep::mark_sweep_phase3 () from
/usr/java/jdk1.6.0_24/jre/lib/i386/server/libjvm.so
#3 0xb781ff52 in PSMarkSweep::invoke_no_policy () from
/usr/java/jdk1.6.0_24/jre/lib/i386/server/libjvm.so
#4 0xb782a82e in PSScavenge::invoke () from
/usr/java/jdk1.6.0_24/jre/lib/i386/server/libjvm.so
#5 0xb77f1639 in ParallelScavengeHeap::failed_mem_allocate () from
/usr/java/jdk1.6.0_24/jre/lib/i386/server/libjvm.so
#6 0xb7922a1c in VM_ParallelGCFailedAllocation::doit () from
/usr/java/jdk1.6.0_24/jre/lib/i386/server/libjvm.so
#7 0xb79310e6 in VM_Operation::evaluate () from
/usr/java/jdk1.6.0_24/jre/lib/i386/server/libjvm.so
#8 0xb7930593 in VMThread::evaluate_operation () from
/usr/java/jdk1.6.0_24/jre/lib/i386/server/libjvm.so
#9 0xb7930800 in VMThread::loop () from
/usr/java/jdk1.6.0_24/jre/lib/i386/server/libjvm.so
#10 0xb79302f0 in VMThread::run () from
/usr/java/jdk1.6.0_24/jre/lib/i386/server/libjvm.so
#11 0xb77dfa6e in java_start () from
/usr/java/jdk1.6.0_24/jre/lib/i386/server/libjvm.so
#12 0xb7f4b34b in start_thread () from /lib/libpthread.so.0
#13 0xb7ed565e in clone () from /lib/libc.so.6
It's a reproducable case.
I had test it with POSTGIS and MYSQL but there the memory management by GC
is running clean.
Only by Oracle NG the memory is running full after about 140.000
WFS-Requests.
Is there a known memory leak or a bug in this plugin.
It will help a lot. I try to repair this error since a long time.
Thanks to all and greetings,
2StepForward
--
View this message in context: http://osgeo-org.1803224.n2.nabble.com/jira-Created-GEOS-3873-GeoServer-binary-distribution-might-use-100-constantly-due-to-a-bug-in-the-JVM-tp6128411p6398297.html
Sent from the GeoServer - Dev mailing list archive at Nabble.com.