Thanks Andrea,

I have several gzipped data dumps, I'll send you an sftp login info to get them 
shortly.

I used Eclipse Memory Analyzer (http://eclipse.org/mat/),  which tries to 
identify potential leak suspects based on a heap dump.

Here is the current result of jmap,  PS  Old Gen is at this time about 75% full:

-histo:live
num     #instances         #bytes  class name
----------------------------------------------
   1:         26627      496999424  [B
   2:       3656028      152263424  [C
   3:       4329868      138555776  java.lang.String
   4:       1828746       96256040  [Ljava.lang.Object;
   5:       2323575       92943000  org.apache.xerces.dom.AttrNSImpl
   6:       2226851       71259232  org.apache.xerces.dom.TextImpl
   7:       1437451       57498040  
org.eclipse.emf.ecore.util.EObjectContainmentEList
   8:        419811       57094296  
org.eclipse.xsd.impl.XSDElementDeclarationImpl
   9:        538143       43051440  javax.imageio.metadata.IIOAttr
  10:        600818       38452352  org.apache.xerces.dom.ElementNSImpl
  11:        420048       36964224  org.eclipse.xsd.impl.XSDParticleImpl
  12:        906590       36263600  
org.eclipse.emf.ecore.util.EDataTypeUniqueEList
  13:        893506       35740240  
org.eclipse.emf.ecore.util.EDataTypeUniqueEList$Unsettable
  14:        192649       30271176  <constMethodKlass>
  15:        535819       30005864  javax.imageio.metadata.IIOMetadataNode
  16:       1214128       29139072  java.util.ArrayList
  17:        192649       23142600  <methodKlass>
  18:        961124       23066976  
org.eclipse.xsd.impl.XSDConcreteComponentImpl$XSDContentsEList
  19:         19030       22289344  <constantPoolKlass>
  20:        227148       20226896  [Ljava.util.HashMap$Entry;
  21:        478857       19154280  org.eclipse.emf.ecore.util.EObjectEList
  22:        572791       18329312  java.util.Vector

-heap

Server compiler detected.
JVM version is 17.1-b03

using thread-local object allocation.
Parallel GC with 8 thread(s)

Heap Configuration:
   MinHeapFreeRatio = 40
   MaxHeapFreeRatio = 70
   MaxHeapSize      = 3221225472 (3072.0MB)
   NewSize          = 1310720 (1.25MB)
   MaxNewSize       = 17592186044415 MB
   OldSize          = 5439488 (5.1875MB)
   NewRatio         = 2
   SurvivorRatio    = 8
   PermSize         = 268435456 (256.0MB)
   MaxPermSize      = 536870912 (512.0MB)

Heap Usage:
PS Young Generation
Eden Space:
   capacity = 550895616 (525.375MB)
   used     = 195447488 (186.39324951171875MB)
   free     = 355448128 (338.98175048828125MB)
   35.478134572775396% used
>From Space:
   capacity = 192806912 (183.875MB)
   used     = 0 (0.0MB)
   free     = 192806912 (183.875MB)
   0.0% used
To Space:
   capacity = 196214784 (187.125MB)
   used     = 0 (0.0MB)
   free     = 196214784 (187.125MB)
   0.0% used
PS Old Generation
   capacity = 2147483648 (2048.0MB)
   used     = 1672784152 (1595.2912826538086MB)
   free     = 474699496 (452.7087173461914MB)
   77.8950821608305% used
PS Perm Generation
   capacity = 268435456 (256.0MB)
   used     = 142182176 (135.59548950195312MB)
   free     = 126253280 (120.40451049804688MB)
   52.96698808670044% used




From: Andrea Aime 
<andrea.a...@geo-solutions.it<mailto:andrea.a...@geo-solutions.it>>
Date: Sat, 28 Jan 2012 12:28:55 -0500
To: Gabriel Roldán <grol...@opengeo.org<mailto:grol...@opengeo.org>>
Cc: Matt Bertrand 
<mbertr...@cga.harvard.edu<mailto:mbertr...@cga.harvard.edu>>, Justin 
Deoliveira <jdeol...@opengeo.org<mailto:jdeol...@opengeo.org>>, 
"geoserver-users@lists.sourceforge.net<mailto:geoserver-users@lists.sourceforge.net>"
 
<geoserver-users@lists.sourceforge.net<mailto:geoserver-users@lists.sourceforge.net>>
Subject: Re: [Geoserver-users] Geoserver memory usage - possible GWC leak?

On Fri, Jan 27, 2012 at 8:50 PM, Gabriel Roldan 
<grol...@opengeo.org<mailto:grol...@opengeo.org>> wrote:

I will try with a profiling session later today.

@Justin: any advice on what kind of care should be taken to minimize
the proliferation of XSDSchemaImpl and GridCoverageReader instances?


Normally too many XSDSchemaImpl (hundreds of MB, a few tens is unfortunately
normal) is normally indication of a memory leak in the WFS/schema subsystem.

GridCoverageReader are cached in ResourcePool, as opening them is expensive,
however per se they do not hold much memory, if they do it's via the
raster metadata,
normally caused my many ill structured raster files, like large and
striped geotiffs
(no inner tiling structure).

Bertrand, could you provide more details on your memory analysis?
Do you have a memory dump we can look into, or the output of jmap,
something like:

jmap -histo:live <jvm pid> | head -25

Cheers
Andrea

--
-------------------------------------------------------
Ing. Andrea Aime
GeoSolutions S.A.S.
Tech lead

Via Poggio alle Viti 1187
55054  Massarosa (LU)
Italy

phone: +39 0584 962313
fax:      +39 0584 962313
mob:    +39 339 8844549

http://www.geo-solutions.it
http://geo-solutions.blogspot.com/
http://www.youtube.com/user/GeoSolutionsIT
http://www.linkedin.com/in/andreaaime
http://twitter.com/geowolf

-------------------------------------------------------



------------------------------------------------------------------------------
Try before you buy = See our experts in action!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-dev2
_______________________________________________
Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users

Reply via email to