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.

------------------------------------------------------------------------------
vRanger cuts backup time in half-while increasing security.
With the market-leading solution for virtual backup and recovery, 
you get blazing-fast, flexible, and affordable data protection.
Download your free trial now. 
http://p.sf.net/sfu/quest-d2dcopy1
_______________________________________________
Geoserver-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

Reply via email to