You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@servicemix.apache.org by Rob de Jong <ro...@urbidata.nl> on 2008/04/08 17:35:28 UTC
Memoryissue, locking mechanism
Hello there,
While pursuing a particularly nasty memory issue
in a custom component, I stumbled upon some
findings regarding the standard servicemix
components. It shows signs of a memory leak.
I'd like to know if these are the result of a
known issue or (if it isn't), what is required
to get bug confirmation? Provided it is indeed
a bug, of course.
Also, it'd be very useful to find out of if a
workaround is possible in this matter. The issue
is rather a showstopper.
Regards,
Rob
Tested using:
- Servicemix 2.2
- Java 5 update 15, Java 6 update 5
- Windows XP, Windows 2003 Server
- YourKit 7.0.11
The synopsis:
- Running Servicemix with (only) standard binding
components under hotdeploy, results in a steady,
continuous increase of the number of objects of
the type:
java.util.concurrent.locks.
AbstractQueuedSynchronizer$Node
The increasing object count results in a slow
drain on the VM's resources, until it runs out
of heap space.
Details:
- My tests were mostly limited to the following
components: File, HTTP, Lightweight, JSR181 and
EIP. Brief checks shows most or all of the other
standard components show the same behaviour.
- The size of an object (in this case both the
shallow and retained sizes), is 32 bytes.
- It seems there's a generation of roughly one
object per second. (Or rather 1<=X<=1.1)
- When we make a rough calculation, this equals
to about half an MB of memory every hour when
five components are deployed.
- Almost all of these objects are not Gcable.
- The increase starts even when no assemblies are
deployed. (Only the BC's and SMX Shared).
It is unknown to me which part of the code is
responsible for these objects' generation.
How to reproduce:
- Just use a (clean) install of servicemix, and
deploy Servicemix Shared and one or several of
the servicemix components. Monitor the memory
use.
Notes:
- The following Java bugreport might be
relevant:
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6490770
RE: Memoryissue, locking mechanism
Posted by Rob de Jong <ro...@urbidata.nl>.
-- Guillaume Nodet:
> Are you able to know where these objects are created ?
> It sounds like it comes from the auto deployer ...
No, I've not been able to deduce this. My suspicion is
that it might be part of a locking mechanism during a
poll sequence that's defined in one of the basic
component classes, but I've absolutely nothing but a
gut feeling to base this sucpicion on. Hopefully, I'll
have more time to test soon.
Rob
> > Tested using:
> > - Servicemix 2.2
> > - Java 5 update 15, Java 6 update 5
> > - Windows XP, Windows 2003 Server
> > - YourKit 7.0.11
> >
> > The synopsis:
> > - Running Servicemix with (only) standard binding components
> > under hotdeploy, results in a steady, continuous increase of
> > the number of objects of the type:
> >
> > java.util.concurrent.locks.
> > AbstractQueuedSynchronizer$Node
> >
> > The increasing object count results in a slow drain on the
> > VM's resources, until it runs out of heap space.
> >
> >
> > Details:
> > - My tests were mostly limited to the following
> > components: File, HTTP, Lightweight, JSR181 and EIP. Brief
> > checks shows most or all of the other standard components
> > show the same behaviour.
> > - The size of an object (in this case both the shallow and
> > retained sizes), is 32 bytes.
> > - It seems there's a generation of roughly one object per
> > second. (Or rather 1<=X<=1.1)
> > - When we make a rough calculation, this equals to about
> > half an MB of
> > memory every hour when five components are deployed.
> > - Almost all of these objects are not Gcable.
> > - The increase starts even when no assemblies are
> > deployed. (Only the BC's and SMX Shared).
> >
> > It is unknown to me which part of the code is responsible
> > for these objects' generation.
> >
> >
> > How to reproduce:
> > - Just use a (clean) install of servicemix, and deploy
> > Servicemix Shared and one or several of the servicemix
> > components. Monitor the memory use.
> >
> >
> > Notes:
> > - The following Java bugreport might be
> > relevant:
> > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6490770
Re: Memoryissue, locking mechanism
Posted by Guillaume Nodet <gn...@gmail.com>.
Are you able to know where these objects are created ?
It sounds like it comes from the auto deployer ...
On Tue, Apr 8, 2008 at 5:35 PM, Rob de Jong <ro...@urbidata.nl> wrote:
> Hello there,
>
> While pursuing a particularly nasty memory issue
> in a custom component, I stumbled upon some
> findings regarding the standard servicemix
> components. It shows signs of a memory leak.
>
> I'd like to know if these are the result of a
> known issue or (if it isn't), what is required
> to get bug confirmation? Provided it is indeed
> a bug, of course.
>
> Also, it'd be very useful to find out of if a
> workaround is possible in this matter. The issue
> is rather a showstopper.
>
> Regards,
> Rob
>
>
> Tested using:
> - Servicemix 2.2
> - Java 5 update 15, Java 6 update 5
> - Windows XP, Windows 2003 Server
> - YourKit 7.0.11
>
> The synopsis:
> - Running Servicemix with (only) standard binding
> components under hotdeploy, results in a steady,
> continuous increase of the number of objects of
> the type:
>
> java.util.concurrent.locks.
> AbstractQueuedSynchronizer$Node
>
> The increasing object count results in a slow
> drain on the VM's resources, until it runs out
> of heap space.
>
>
> Details:
> - My tests were mostly limited to the following
> components: File, HTTP, Lightweight, JSR181 and
> EIP. Brief checks shows most or all of the other
> standard components show the same behaviour.
> - The size of an object (in this case both the
> shallow and retained sizes), is 32 bytes.
> - It seems there's a generation of roughly one
> object per second. (Or rather 1<=X<=1.1)
> - When we make a rough calculation, this equals
> to about half an MB of memory every hour when
> five components are deployed.
> - Almost all of these objects are not Gcable.
> - The increase starts even when no assemblies are
> deployed. (Only the BC's and SMX Shared).
>
> It is unknown to me which part of the code is
> responsible for these objects' generation.
>
>
> How to reproduce:
> - Just use a (clean) install of servicemix, and
> deploy Servicemix Shared and one or several of
> the servicemix components. Monitor the memory
> use.
>
>
> Notes:
> - The following Java bugreport might be
> relevant:
> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6490770
>
>
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/