You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@wicket.apache.org by Quan Zhou <be...@gmail.com> on 2008/05/09 09:15:11 UTC
Why Localizer Retained so many heapsize?
Hello everyone.
I recently develop my App use Wicket1.3.3. It's my first time to use this
framework and I feel it's really really a perfect framework for me.
My app support both Simplified Chinese , Traditional Chinese, I implement
this with Wicket i18n feature.
With the load increasing these days, I found my app would become very lag
abount every 24 hours ,so that i would only restart it
without any choice.
when I found the lag, My log records many Exceptions like :
"after 1 minute the Pagemap null is still locked by:
Thread[http-8080-321,5,main], giving
up trying to get the page for path xxx"
I check the JVM status with jstat -gc , It tells that the Heapsize is full
even after full GC.
My VM paraemter is "-Xms2000m -Xmx2000m -XX:MaxNewSize=250m
-XX:MaxPermSize=250m"
My deploy server has 2*CPU and 4G memory, Redhat AS4 OS + tomcat 6.0.
There're 2000 sessions on the day while the timeout threshold is 15 minutes.
So i dump the whole heapsize with the command " jmap
-dump:live,format=b,file=3.dump.hprof processid"
and i truely get a 2G size dump files. I use SAP Memory Analyer to see
what're stored in HeapMemory.
and I found a strange number of Retained Heap usage:
Classname
ShallowHeap RetainHeap
RetainedHeap%
-org.apache.wicket.Localizer@0x78..
16
1,755,070,352 87.64%
-org.apache.wicket.util.concurrent.ConcurrentHashMap@0x79...
48 1,755,070,336 87.69%
-org.apache.wicket.util.concurrent.ConcurrentHaspMap$Entry@0xd....
33,554,448
1,755,069,632 87.69%
- org.apache.wicket.util.concurrent.ConcurrentHaspMap$Entry@0xd....
24 3928
0.00%
- org.apache.wicket.util.concurrent.ConcurrentHaspMap$Entry@0xd....
24 3928
0.00%
- org.apache.wicket.util.concurrent.ConcurrentHaspMap$Entry@0xd....
24 3928
0.00%
- org.apache.wicket.util.concurrent.ConcurrentHaspMap$Entry@0xd....
24 3928
0.00%
- org.apache.wicket.util.concurrent.ConcurrentHaspMap$Entry@0xd....
24 3928
0.00%
- org.apache.wicket.util.concurrent.ConcurrentHaspMap$Entry@0xd....
24 3928
0.00%
+ 2,863,659 more...
Is that means that the Localizer Object used most of the heap size?
or Is this number normal for Wicket App?
I wonder whether I forget to release the memory by my mis-using of i18n
feature?
Is there any attentions I must pay to when dealing with Localizer?
This problem annoys me more the 2 weeks. I really need some help. Thanks .
Re: Why Localizer Retained so many heapsize?
Posted by James Carman <ja...@carmanconsulting.com>.
On Mon, May 12, 2008 at 8:42 AM, Jan Kriesten <ja...@renitence.de> wrote:
>
> hi martijn,
>
>
>
> > md5sum for the concatenated string? Though the calculation may be
> > costly and there could be false cache hits.
> >
>
> looking at the length of the strings and their composition... i doubt that
> md5 would lead to false cache hits...
There's always the chance.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Why Localizer Retained so many heapsize?
Posted by Jan Kriesten <ja...@renitence.de>.
hi martijn,
> md5sum for the concatenated string? Though the calculation may be
> costly and there could be false cache hits.
looking at the length of the strings and their composition... i doubt that md5
would lead to false cache hits...
regards, --- jan.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Why Localizer Retained so many heapsize?
Posted by Martijn Dashorst <ma...@gmail.com>.
md5sum for the concatenated string? Though the calculation may be
costly and there could be false cache hits.
Martijn
On 5/12/08, Johan Compagner <jc...@gmail.com> wrote:
> a reall UUID?
>
> that cant be
> then all the keys would change constantly...
> The point is that the paths of components on a page class are quite stable
> and for those the keys are stored
> If we use UUID for those then every key would be different for the "same"
> component on a page class
>
> The thing is that it must be stable for a page.component... (and re
> occuring)
>
> johan
>
>
> On Mon, May 12, 2008 at 2:22 PM, Jan Kriesten <ja...@renitence.de>
> wrote:
>
> >
>
> > hi johan,
> >
> > and that would walk over the hierarchy.. how would that help?
> > >
> >
> > no, not walk the hierarchy, that wouldn't be that better (but at least it
> > wouldn't be recompiled every access).
> >
> > but you could just use a static getNextUid like you do at other places as
> > well (and that could be used as a stable id for repeaters as well btw).
> >
> > also getInputName is a bit smarter. That can stop with the first form it
> > > finds. Because an input name only have to be unique for the form.
> > >
> >
> > actually, on genereated forms this really get sick long ids as well which
> > doen't look nice in the html output at all. i can show you... ;-)
> >
> > best regards, --- jan.
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> > For additional commands, e-mail: users-help@wicket.apache.org
> >
> >
>
--
Buy Wicket in Action: http://manning.com/dashorst
Apache Wicket 1.3.3 is released
Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.3
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Why Localizer Retained so many heapsize?
Posted by Igor Vaynberg <ig...@gmail.com>.
its not the listitem itself but any direct child of the repeater, that
is why i factored out an AbstractRepeater class that all other
repeaters extend.
-igor
On Tue, May 27, 2008 at 4:14 AM, Johan Compagner <jc...@gmail.com> wrote:
> I already fixed the page issue
> But you are right about the repeaters that still can generate multiply per
> key
> I guess ListItem should be jumped over in that generation
>
> Can you make a jira issue?
>
> johan
>
>
> On Tue, May 27, 2008 at 12:42 PM, badaud <vc...@sneakemail.com> wrote:
>
>>
>> I think I noticed a bigger issue in the generation of cache keys: they seem
>> to be always unique, as they use the id of components:
>> Component< ? > cursor = component;
>> while (cursor != null)
>> {
>>
>> buffer.append("-").append(cursor.getClass().getName());
>> buffer.append(":").append(cursor.getId());
>> cursor = cursor.getParent();
>> }
>>
>> But this is an issue, as each time a page is generated, it has a different
>> id (and the same kind of stuff happens in repeaters).
>>
>> As I just mentioned on the ##wicket IRC channel:
>> [12:12] <Badaud> Helloo, helloo
>> [12:13] <Badaud> I have question regarding the wicket localizer which seems
>> to be related to, I think, a bug (or an erroneous behaviour) in the
>> getCacheKey() method
>> [12:13] <Badaud> I just noticed that the cache variable is always
>> increasing
>> in size in the localizer
>> [12:15] <Badaud> even when I just do a simple refresh of a page
>> [12:16] <Badaud> This seems to be linked to the fact that the getCacheKey
>> add the ID of components in the component tree
>> [12:16] <Badaud> when building the key
>> [12:16] <Badaud> but the id for pages change all the time
>> [12:16] <Badaud> which means that every time a new page is loaded
>> [12:17] <Badaud> sorry
>> [12:17] <Badaud> every time the same page is loaded
>> [12:17] <Badaud> a new set of ids is generated
>> [12:17] <Badaud> this looks like a memory leak to me
>> [12:19] <Badaud> I think that the id of the component shouldn't be part of
>> the path (or it shouldn't be used when the component cursor is on a page...
>> but wouldn't this be the case also in List views?)
>> [12:21] <Badaud> I mean, in repeaters?
>> [12:24] <Badaud> Like this:
>> [12:24] <Badaud>
>>
>> label.allStates-org.apache.wicket.markup.html.basic.Label:state-org.apache.wicket.markup.repeater.Item:14-...........-com.mycompany.SomePage:18-en-null
>>
>> --
>> View this message in context:
>> http://www.nabble.com/Why-Localizer-Retained-so-many-heapsize--tp17142582p17487594.html
>> Sent from the Wicket - User mailing list archive at Nabble.com.
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Why Localizer Retained so many heapsize?
Posted by Johan Compagner <jc...@gmail.com>.
I already fixed the page issue
But you are right about the repeaters that still can generate multiply per
key
I guess ListItem should be jumped over in that generation
Can you make a jira issue?
johan
On Tue, May 27, 2008 at 12:42 PM, badaud <vc...@sneakemail.com> wrote:
>
> I think I noticed a bigger issue in the generation of cache keys: they seem
> to be always unique, as they use the id of components:
> Component< ? > cursor = component;
> while (cursor != null)
> {
>
> buffer.append("-").append(cursor.getClass().getName());
> buffer.append(":").append(cursor.getId());
> cursor = cursor.getParent();
> }
>
> But this is an issue, as each time a page is generated, it has a different
> id (and the same kind of stuff happens in repeaters).
>
> As I just mentioned on the ##wicket IRC channel:
> [12:12] <Badaud> Helloo, helloo
> [12:13] <Badaud> I have question regarding the wicket localizer which seems
> to be related to, I think, a bug (or an erroneous behaviour) in the
> getCacheKey() method
> [12:13] <Badaud> I just noticed that the cache variable is always
> increasing
> in size in the localizer
> [12:15] <Badaud> even when I just do a simple refresh of a page
> [12:16] <Badaud> This seems to be linked to the fact that the getCacheKey
> add the ID of components in the component tree
> [12:16] <Badaud> when building the key
> [12:16] <Badaud> but the id for pages change all the time
> [12:16] <Badaud> which means that every time a new page is loaded
> [12:17] <Badaud> sorry
> [12:17] <Badaud> every time the same page is loaded
> [12:17] <Badaud> a new set of ids is generated
> [12:17] <Badaud> this looks like a memory leak to me
> [12:19] <Badaud> I think that the id of the component shouldn't be part of
> the path (or it shouldn't be used when the component cursor is on a page...
> but wouldn't this be the case also in List views?)
> [12:21] <Badaud> I mean, in repeaters?
> [12:24] <Badaud> Like this:
> [12:24] <Badaud>
>
> label.allStates-org.apache.wicket.markup.html.basic.Label:state-org.apache.wicket.markup.repeater.Item:14-...........-com.mycompany.SomePage:18-en-null
>
> --
> View this message in context:
> http://www.nabble.com/Why-Localizer-Retained-so-many-heapsize--tp17142582p17487594.html
> Sent from the Wicket - User mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
Re: Why Localizer Retained so many heapsize?
Posted by badaud <vc...@sneakemail.com>.
I think I noticed a bigger issue in the generation of cache keys: they seem
to be always unique, as they use the id of components:
Component< ? > cursor = component;
while (cursor != null)
{
buffer.append("-").append(cursor.getClass().getName());
buffer.append(":").append(cursor.getId());
cursor = cursor.getParent();
}
But this is an issue, as each time a page is generated, it has a different
id (and the same kind of stuff happens in repeaters).
As I just mentioned on the ##wicket IRC channel:
[12:12] <Badaud> Helloo, helloo
[12:13] <Badaud> I have question regarding the wicket localizer which seems
to be related to, I think, a bug (or an erroneous behaviour) in the
getCacheKey() method
[12:13] <Badaud> I just noticed that the cache variable is always increasing
in size in the localizer
[12:15] <Badaud> even when I just do a simple refresh of a page
[12:16] <Badaud> This seems to be linked to the fact that the getCacheKey
add the ID of components in the component tree
[12:16] <Badaud> when building the key
[12:16] <Badaud> but the id for pages change all the time
[12:16] <Badaud> which means that every time a new page is loaded
[12:17] <Badaud> sorry
[12:17] <Badaud> every time the same page is loaded
[12:17] <Badaud> a new set of ids is generated
[12:17] <Badaud> this looks like a memory leak to me
[12:19] <Badaud> I think that the id of the component shouldn't be part of
the path (or it shouldn't be used when the component cursor is on a page...
but wouldn't this be the case also in List views?)
[12:21] <Badaud> I mean, in repeaters?
[12:24] <Badaud> Like this:
[12:24] <Badaud>
label.allStates-org.apache.wicket.markup.html.basic.Label:state-org.apache.wicket.markup.repeater.Item:14-...........-com.mycompany.SomePage:18-en-null
--
View this message in context: http://www.nabble.com/Why-Localizer-Retained-so-many-heapsize--tp17142582p17487594.html
Sent from the Wicket - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Why Localizer Retained so many heapsize?
Posted by Jan Kriesten <ja...@renitence.de>.
hi johan,
> a reall UUID?
> that cant be
> then all the keys would change constantly...
right, didn't took that into account.
still, having a a component-id calculated on the path information and e.g. using
a md5 only once for that would shorten things (with the benefit of "don't repeat
yourself" in different locations of wicket...
regards, --- jan.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Why Localizer Retained so many heapsize?
Posted by Johan Compagner <jc...@gmail.com>.
a reall UUID?
that cant be
then all the keys would change constantly...
The point is that the paths of components on a page class are quite stable
and for those the keys are stored
If we use UUID for those then every key would be different for the "same"
component on a page class
The thing is that it must be stable for a page.component... (and re
occuring)
johan
On Mon, May 12, 2008 at 2:22 PM, Jan Kriesten <ja...@renitence.de>
wrote:
>
> hi johan,
>
> and that would walk over the hierarchy.. how would that help?
> >
>
> no, not walk the hierarchy, that wouldn't be that better (but at least it
> wouldn't be recompiled every access).
>
> but you could just use a static getNextUid like you do at other places as
> well (and that could be used as a stable id for repeaters as well btw).
>
> also getInputName is a bit smarter. That can stop with the first form it
> > finds. Because an input name only have to be unique for the form.
> >
>
> actually, on genereated forms this really get sick long ids as well which
> doen't look nice in the html output at all. i can show you... ;-)
>
> best regards, --- jan.
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
Re: Why Localizer Retained so many heapsize?
Posted by Jan Kriesten <ja...@renitence.de>.
hi johan,
> and that would walk over the hierarchy.. how would that help?
no, not walk the hierarchy, that wouldn't be that better (but at least it
wouldn't be recompiled every access).
but you could just use a static getNextUid like you do at other places as well
(and that could be used as a stable id for repeaters as well btw).
> also getInputName is a bit smarter. That can stop with the first form it
> finds. Because an input name only have to be unique for the form.
actually, on genereated forms this really get sick long ids as well which doen't
look nice in the html output at all. i can show you... ;-)
best regards, --- jan.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Why Localizer Retained so many heapsize?
Posted by Johan Compagner <jc...@gmail.com>.
and that would walk over the hierarchy.. how would that help?
also getInputName is a bit smarter. That can stop with the first form it
finds. Because an input name only have to be unique for the form.
johan
On Mon, May 12, 2008 at 1:02 PM, Jan Kriesten <ja...@renitence.de>
wrote:
>
> hi johan,
>
> So how to make those keys unique enough?
> >
> > getParent().getClass().getName() + getParent().getId() +
> > getClass().getName() + getId() + getLocale() + getStyle() ??
> >
>
> i'd suggest component implementing a lazy componentUID - that could then
> also be used by getInputName for identification purpose.
>
> this way, the whole walk-the-hierachy-to-get-me-a-component-id stuff could
> be much more friendly...
>
> regards, --- jan.
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
Re: Why Localizer Retained so many heapsize?
Posted by Jan Kriesten <ja...@renitence.de>.
hi johan,
> So how to make those keys unique enough?
>
> getParent().getClass().getName() + getParent().getId() +
> getClass().getName() + getId() + getLocale() + getStyle() ??
i'd suggest component implementing a lazy componentUID - that could then also be
used by getInputName for identification purpose.
this way, the whole walk-the-hierachy-to-get-me-a-component-id stuff could be
much more friendly...
regards, --- jan.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Why Localizer Retained so many heapsize?
Posted by Johan Compagner <jc...@gmail.com>.
yeah the current impl just generates the full path
This could be a problem if you have a lot of components in a repeater that
also hit the localizer..
the problem is that a key for a component X can return a different thing
then that same key for component Y..
So how to make those keys unique enough?
getParent().getClass().getName() + getParent().getId() +
getClass().getName() + getId() + getLocale() + getStyle() ??
Would that be unique enough?
The problem is that combination could be added to 2 different panels that
have there own properties
and then it that panel is the unique part...
But i just found a bit of leak, that is causing the problem of the first
email
The page was as far as i can see also added... Thats really wrong..
Then it would really grow and grow, but everybody should see this.. Weird..
johan
On Mon, May 12, 2008 at 11:44 AM, Iman Rahmatizadeh <
iman.rahmatizadeh@gmail.com> wrote:
> Is there any way to make getCacheKey() return smaller keys ? Those huge
> keys
> are consuming a lot of memory and also the equals/hashcode check on the
> key
> will take resources.
>
> On Mon, May 12, 2008 at 12:33 PM, Johan Compagner <jc...@gmail.com>
> wrote:
>
> > i guess you have a loads of null values somehow
> > Dont know why in your situation you have soo many of those.
> >
> > What you could do is this in the init of your application:
> >
> > Localizer localizer = new Localizer()
> > {
> > protected void putIntoCache(final String cacheKey, final String string)
> > {
> > if (string != null) super.putIntoCache(cacheKey,string);
> > }
> > };
> > getResourceSettings().setLocalizer(localizer);
> >
> > this way you dont cache null values at all, only your real values.
> > If null values are asked a lot this could be slower ofcourse..
> >
> >
> > I will also open up Localizer api a bit more so that you can override
> the
> > cache that is used:
> >
> > /**
> > * Create a new cache, override this method if you want a different
> map
> > to store the cache keys,
> > * for example a map that hold only the last X number of elements..
> > *
> > * By default it uses the {@link ConcurrentHashMap}
> > *
> > * @return cache
> > */
> > protected Map newCache()
> > {
> > return new ConcurrentHashMap();
> > }
> >
> > You could return there a map that evicts on the least recently used
> then.
> >
> > johan
> >
> >
> >
> > On Mon, May 12, 2008 at 9:41 AM, Quan Zhou <be...@gmail.com> wrote:
> >
> > > Thanks iman.
> > >
> > > I explore many CocurrentHashMap$Entry to check its key/value.
> > > I truly found two things:
> > > 1. some key is large , its length would be more than 300 if the
> > component
> > > has deep hierachy.That must be one of the reasons why Localizer is so
> > big.
> > > 2. the number of this object is large too. there're 2,863,559 entrys.
> I
> > > couldn't check the whole objects one by one.but i was wondering
> > > why there're too many Entrys. There are about 2000 java files at
> most
> > in
> > > my app, and no more than 500 wicket page/components with 2
> > > properties files , 1 html files in average. It means there are not
> > > huge
> > > properties or name that needs to retain in heapze ,so what things
> > > would those 2,863,559 entries supposed to contain?
> > >
> > > Is there any settings can control the limit of Entry size?or some
> > strategy
> > > can reduce the key name of the entry?
> > >
> > >
> > > 2008/5/12 Iman Rahmatizadeh <im...@gmail.com>:
> > >
> > > > Well actually I haven't :-) My localizer gets quite large, but it
> > hasnt
> > > > made
> > > > any problems, yet .
> > > > You see when the localizer wants to find the resource value for a
> > > specific
> > > > key, it caches the result into the localizer. Now if your component
> > has
> > > a
> > > > deep hierarchy, the generated key will be quite large. In yourkit ,
> > use
> > > > the
> > > > object explorer to explore the ConcurrentHashMap entries and see why
> > are
> > > > they so large, as I think the number of entries in the cache is
> > limited,
> > > > So
> > > > the only explanation would be to see why are the key/values taking
> so
> > > much
> > > > space. If you can give a dump of one of the bigger key/values we can
> > > help
> > > > more.
> > > > Also the DiskPageStore doesnt hold on to anything in memory, so it
> > wont
> > > > consume any memory, nothing strange about it.
> > > >
> > > > Iman
> > > >
> > > > On Mon, May 12, 2008 at 9:31 AM, Quan Zhou <be...@gmail.com>
> > wrote:
> > > >
> > > > > Thanks for your all replys.
> > > > >
> > > > > I review the dump file with both SAP MemoryAnalyzer and YourKit
> > > > > They all show the same hierachy as follows:
> > > > >
> > > > > -org.apache.wicket.settings.Settings
> > > > > - org.apache.wicket.Localizer
> > > > > - org.apache.wicket.util.concurrent.ConcurrentHashMap
> > > > > - org.apache.wicket.util.concurrent.ConcurrentHashMap$Entry
> > > > >
> > > > > Localizer Object retaind 87.84% HeapSize. while the DiskPageStore
> > only
> > > > > retained 0.71%
> > > > > That's weird,isn't it?
> > > > >
> > > > > I decrease the max heapsize settings to 50M, and make a load test
> > then
> > > > > monitor the memory allocation.
> > > > > It indeed allocated more and more char[] objects time by time.
> > > > >
> > > > > Iman,how do you solve your problem at last?
> > > > > could you share some experience with me ? Thank you very much.
> > > > >
> > > > > 2008/5/10 Iman Rahmatizadeh <im...@gmail.com>:
> > > > >
> > > > > > I've seen this before, altough it wasnt 2GB, but in a small 70MB
> > > heap
> > > > > dump
> > > > > > the cache size was around 25MB. The ConcurrentHashMap caches a
> lot
> > > of
> > > > > > unneeded string keys, where the keys are quite large, maybe
> > strings
> > > of
> > > > > size
> > > > > > 1k characters, like key :
> > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> "org.apache.wicket.extensions.markup.html.repeater.data.table.DataTable$1:rows-ir.co.meraat.avicenna.web.components.AvicennaDataTable$InnerDataTable:inner-table-ir.co.meraat.avicenna.web.components.AvicennaDataTable$1:filter-form-ir.co.meraat.avicenna.web.components.AvicennaDataTable:table-ir.co.meraat.avicenna.vita.GradesManagementPanel$1:studentSearch-ir.co.meraat.avicenna.vita.GradesManagementPanel:componentId-ir.co.meraat.avicenna.web.CompositePage:5-fa_IR-nullg.apache.wicket.markup.repeater.OddEvenItem:29-...."
> > > > > >
> > > > > > As you see the component hierarchy is dumped into the string,
> > making
> > > > it
> > > > > > very
> > > > > > large. I guess we're both localizing a lot of strings, so our
> > > problem
> > > > > could
> > > > > > be the same.
> > > > > >
> > > > > > Iman
> > > > > >
> > > > > > On Sat, May 10, 2008 at 9:38 AM, Johan Compagner <
> > > jcompagner@gmail.com
> > > > >
> > > > > > wrote:
> > > > > >
> > > > > > > Can you really see what it holds?
> > > > > > > Almost 2G in memory in localizer is extreme... Thats really a
> > lot
> > > of
> > > > > > > strings..
> > > > > > > You could try to read that dump with yourkit if your current
> one
> > > > > > > doesnt show enough.
> > > > > > >
> > > > > > > On 5/9/08, Quan Zhou <be...@gmail.com> wrote:
> > > > > > > > Hello everyone.
> > > > > > > >
> > > > > > > > I recently develop my App use Wicket1.3.3. It's my first
> time
> > to
> > > > use
> > > > > > this
> > > > > > > > framework and I feel it's really really a perfect framework
> > for
> > > > me.
> > > > > > > > My app support both Simplified Chinese , Traditional
> Chinese,
> > I
> > > > > > implement
> > > > > > > > this with Wicket i18n feature.
> > > > > > > > With the load increasing these days, I found my app would
> > become
> > > > > very
> > > > > > lag
> > > > > > > > abount every 24 hours ,so that i would only restart it
> > > > > > > > without any choice.
> > > > > > > > when I found the lag, My log records many Exceptions like :
> > > > > > > > "after 1 minute the Pagemap null is still locked by:
> > > > > > > > Thread[http-8080-321,5,main], giving
> > > > > > > > up trying to get the page for path xxx"
> > > > > > > >
> > > > > > > > I check the JVM status with jstat -gc , It tells that the
> > > Heapsize
> > > > > is
> > > > > > > full
> > > > > > > > even after full GC.
> > > > > > > > My VM paraemter is "-Xms2000m -Xmx2000m -XX:MaxNewSize=250m
> > > > > > > > -XX:MaxPermSize=250m"
> > > > > > > > My deploy server has 2*CPU and 4G memory, Redhat AS4 OS +
> > tomcat
> > > > > 6.0.
> > > > > > > > There're 2000 sessions on the day while the timeout
> threshold
> > is
> > > > 15
> > > > > > > minutes.
> > > > > > > > So i dump the whole heapsize with the command " jmap
> > > > > > > > -dump:live,format=b,file=3.dump.hprof processid"
> > > > > > > > and i truely get a 2G size dump files. I use SAP Memory
> > Analyer
> > > to
> > > > > see
> > > > > > > > what're stored in HeapMemory.
> > > > > > > > and I found a strange number of Retained Heap usage:
> > > > > > > > Classname
> > > > > > > > ShallowHeap
> > > > > RetainHeap
> > > > > > > > RetainedHeap%
> > > > > > > > -org.apache.wicket.Localizer@0x78..
> > > > > > > > 16
> > > > > > > > 1,755,070,352 87.64%
> > > > > > > > -org.apache.wicket.util.concurrent.ConcurrentHashMap@0x79.
> ..
> > > > > > > > 48 1,755,070,336
> > > > > 87.69%
> > > > > > > >
> > > -org.apache.wicket.util.concurrent.ConcurrentHaspMap$Entry@0xd.
> > > > ...
> > > > > > > > 33,554,448
> > > > > > > > 1,755,069,632
> > 87.69%
> > > > > > > > -
> > > > org.apache.wicket.util.concurrent.ConcurrentHaspMap$Entry@0xd.
> > > > > > ...
> > > > > > > > 24 3928
> > > > > > > > 0.00%
> > > > > > > > -
> > > > org.apache.wicket.util.concurrent.ConcurrentHaspMap$Entry@0xd.
> > > > > > ...
> > > > > > > > 24 3928
> > > > > > > > 0.00%
> > > > > > > > -
> > > > org.apache.wicket.util.concurrent.ConcurrentHaspMap$Entry@0xd.
> > > > > > ...
> > > > > > > > 24 3928
> > > > > > > > 0.00%
> > > > > > > > -
> > > > org.apache.wicket.util.concurrent.ConcurrentHaspMap$Entry@0xd.
> > > > > > ...
> > > > > > > > 24 3928
> > > > > > > > 0.00%
> > > > > > > > -
> > > > org.apache.wicket.util.concurrent.ConcurrentHaspMap$Entry@0xd.
> > > > > > ...
> > > > > > > > 24 3928
> > > > > > > > 0.00%
> > > > > > > > -
> > > > org.apache.wicket.util.concurrent.ConcurrentHaspMap$Entry@0xd.
> > > > > > ...
> > > > > > > > 24 3928
> > > > > > > > 0.00%
> > > > > > > > + 2,863,659 more...
> > > > > > > >
> > > > > > > > Is that means that the Localizer Object used most of the
> heap
> > > > size?
> > > > > > > > or Is this number normal for Wicket App?
> > > > > > > >
> > > > > > > > I wonder whether I forget to release the memory by my
> > mis-using
> > > of
> > > > > i18n
> > > > > > > > feature?
> > > > > > > > Is there any attentions I must pay to when dealing with
> > > Localizer?
> > > > > > > >
> > > > > > > > This problem annoys me more the 2 weeks. I really need some
> > > help.
> > > > > > Thanks
> > > > > > > .
> > > > > > > >
> > > > > > >
> > > > > > >
> > > >
> ---------------------------------------------------------------------
> > > > > > > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> > > > > > > For additional commands, e-mail: users-help@wicket.apache.org
> > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
Re: Why Localizer Retained so many heapsize?
Posted by Iman Rahmatizadeh <im...@gmail.com>.
Is there any way to make getCacheKey() return smaller keys ? Those huge keys
are consuming a lot of memory and also the equals/hashcode check on the key
will take resources.
On Mon, May 12, 2008 at 12:33 PM, Johan Compagner <jc...@gmail.com>
wrote:
> i guess you have a loads of null values somehow
> Dont know why in your situation you have soo many of those.
>
> What you could do is this in the init of your application:
>
> Localizer localizer = new Localizer()
> {
> protected void putIntoCache(final String cacheKey, final String string)
> {
> if (string != null) super.putIntoCache(cacheKey,string);
> }
> };
> getResourceSettings().setLocalizer(localizer);
>
> this way you dont cache null values at all, only your real values.
> If null values are asked a lot this could be slower ofcourse..
>
>
> I will also open up Localizer api a bit more so that you can override the
> cache that is used:
>
> /**
> * Create a new cache, override this method if you want a different map
> to store the cache keys,
> * for example a map that hold only the last X number of elements..
> *
> * By default it uses the {@link ConcurrentHashMap}
> *
> * @return cache
> */
> protected Map newCache()
> {
> return new ConcurrentHashMap();
> }
>
> You could return there a map that evicts on the least recently used then.
>
> johan
>
>
>
> On Mon, May 12, 2008 at 9:41 AM, Quan Zhou <be...@gmail.com> wrote:
>
> > Thanks iman.
> >
> > I explore many CocurrentHashMap$Entry to check its key/value.
> > I truly found two things:
> > 1. some key is large , its length would be more than 300 if the
> component
> > has deep hierachy.That must be one of the reasons why Localizer is so
> big.
> > 2. the number of this object is large too. there're 2,863,559 entrys. I
> > couldn't check the whole objects one by one.but i was wondering
> > why there're too many Entrys. There are about 2000 java files at most
> in
> > my app, and no more than 500 wicket page/components with 2
> > properties files , 1 html files in average. It means there are not
> > huge
> > properties or name that needs to retain in heapze ,so what things
> > would those 2,863,559 entries supposed to contain?
> >
> > Is there any settings can control the limit of Entry size?or some
> strategy
> > can reduce the key name of the entry?
> >
> >
> > 2008/5/12 Iman Rahmatizadeh <im...@gmail.com>:
> >
> > > Well actually I haven't :-) My localizer gets quite large, but it
> hasnt
> > > made
> > > any problems, yet .
> > > You see when the localizer wants to find the resource value for a
> > specific
> > > key, it caches the result into the localizer. Now if your component
> has
> > a
> > > deep hierarchy, the generated key will be quite large. In yourkit ,
> use
> > > the
> > > object explorer to explore the ConcurrentHashMap entries and see why
> are
> > > they so large, as I think the number of entries in the cache is
> limited,
> > > So
> > > the only explanation would be to see why are the key/values taking so
> > much
> > > space. If you can give a dump of one of the bigger key/values we can
> > help
> > > more.
> > > Also the DiskPageStore doesnt hold on to anything in memory, so it
> wont
> > > consume any memory, nothing strange about it.
> > >
> > > Iman
> > >
> > > On Mon, May 12, 2008 at 9:31 AM, Quan Zhou <be...@gmail.com>
> wrote:
> > >
> > > > Thanks for your all replys.
> > > >
> > > > I review the dump file with both SAP MemoryAnalyzer and YourKit
> > > > They all show the same hierachy as follows:
> > > >
> > > > -org.apache.wicket.settings.Settings
> > > > - org.apache.wicket.Localizer
> > > > - org.apache.wicket.util.concurrent.ConcurrentHashMap
> > > > - org.apache.wicket.util.concurrent.ConcurrentHashMap$Entry
> > > >
> > > > Localizer Object retaind 87.84% HeapSize. while the DiskPageStore
> only
> > > > retained 0.71%
> > > > That's weird,isn't it?
> > > >
> > > > I decrease the max heapsize settings to 50M, and make a load test
> then
> > > > monitor the memory allocation.
> > > > It indeed allocated more and more char[] objects time by time.
> > > >
> > > > Iman,how do you solve your problem at last?
> > > > could you share some experience with me ? Thank you very much.
> > > >
> > > > 2008/5/10 Iman Rahmatizadeh <im...@gmail.com>:
> > > >
> > > > > I've seen this before, altough it wasnt 2GB, but in a small 70MB
> > heap
> > > > dump
> > > > > the cache size was around 25MB. The ConcurrentHashMap caches a lot
> > of
> > > > > unneeded string keys, where the keys are quite large, maybe
> strings
> > of
> > > > size
> > > > > 1k characters, like key :
> > > > >
> > > > >
> > > >
> > >
> >
> "org.apache.wicket.extensions.markup.html.repeater.data.table.DataTable$1:rows-ir.co.meraat.avicenna.web.components.AvicennaDataTable$InnerDataTable:inner-table-ir.co.meraat.avicenna.web.components.AvicennaDataTable$1:filter-form-ir.co.meraat.avicenna.web.components.AvicennaDataTable:table-ir.co.meraat.avicenna.vita.GradesManagementPanel$1:studentSearch-ir.co.meraat.avicenna.vita.GradesManagementPanel:componentId-ir.co.meraat.avicenna.web.CompositePage:5-fa_IR-nullg.apache.wicket.markup.repeater.OddEvenItem:29-...."
> > > > >
> > > > > As you see the component hierarchy is dumped into the string,
> making
> > > it
> > > > > very
> > > > > large. I guess we're both localizing a lot of strings, so our
> > problem
> > > > could
> > > > > be the same.
> > > > >
> > > > > Iman
> > > > >
> > > > > On Sat, May 10, 2008 at 9:38 AM, Johan Compagner <
> > jcompagner@gmail.com
> > > >
> > > > > wrote:
> > > > >
> > > > > > Can you really see what it holds?
> > > > > > Almost 2G in memory in localizer is extreme... Thats really a
> lot
> > of
> > > > > > strings..
> > > > > > You could try to read that dump with yourkit if your current one
> > > > > > doesnt show enough.
> > > > > >
> > > > > > On 5/9/08, Quan Zhou <be...@gmail.com> wrote:
> > > > > > > Hello everyone.
> > > > > > >
> > > > > > > I recently develop my App use Wicket1.3.3. It's my first time
> to
> > > use
> > > > > this
> > > > > > > framework and I feel it's really really a perfect framework
> for
> > > me.
> > > > > > > My app support both Simplified Chinese , Traditional Chinese,
> I
> > > > > implement
> > > > > > > this with Wicket i18n feature.
> > > > > > > With the load increasing these days, I found my app would
> become
> > > > very
> > > > > lag
> > > > > > > abount every 24 hours ,so that i would only restart it
> > > > > > > without any choice.
> > > > > > > when I found the lag, My log records many Exceptions like :
> > > > > > > "after 1 minute the Pagemap null is still locked by:
> > > > > > > Thread[http-8080-321,5,main], giving
> > > > > > > up trying to get the page for path xxx"
> > > > > > >
> > > > > > > I check the JVM status with jstat -gc , It tells that the
> > Heapsize
> > > > is
> > > > > > full
> > > > > > > even after full GC.
> > > > > > > My VM paraemter is "-Xms2000m -Xmx2000m -XX:MaxNewSize=250m
> > > > > > > -XX:MaxPermSize=250m"
> > > > > > > My deploy server has 2*CPU and 4G memory, Redhat AS4 OS +
> tomcat
> > > > 6.0.
> > > > > > > There're 2000 sessions on the day while the timeout threshold
> is
> > > 15
> > > > > > minutes.
> > > > > > > So i dump the whole heapsize with the command " jmap
> > > > > > > -dump:live,format=b,file=3.dump.hprof processid"
> > > > > > > and i truely get a 2G size dump files. I use SAP Memory
> Analyer
> > to
> > > > see
> > > > > > > what're stored in HeapMemory.
> > > > > > > and I found a strange number of Retained Heap usage:
> > > > > > > Classname
> > > > > > > ShallowHeap
> > > > RetainHeap
> > > > > > > RetainedHeap%
> > > > > > > -org.apache.wicket.Localizer@0x78..
> > > > > > > 16
> > > > > > > 1,755,070,352 87.64%
> > > > > > > -org.apache.wicket.util.concurrent.ConcurrentHashMap@0x79...
> > > > > > > 48 1,755,070,336
> > > > 87.69%
> > > > > > >
> > -org.apache.wicket.util.concurrent.ConcurrentHaspMap$Entry@0xd.
> > > ...
> > > > > > > 33,554,448
> > > > > > > 1,755,069,632
> 87.69%
> > > > > > > -
> > > org.apache.wicket.util.concurrent.ConcurrentHaspMap$Entry@0xd.
> > > > > ...
> > > > > > > 24 3928
> > > > > > > 0.00%
> > > > > > > -
> > > org.apache.wicket.util.concurrent.ConcurrentHaspMap$Entry@0xd.
> > > > > ...
> > > > > > > 24 3928
> > > > > > > 0.00%
> > > > > > > -
> > > org.apache.wicket.util.concurrent.ConcurrentHaspMap$Entry@0xd.
> > > > > ...
> > > > > > > 24 3928
> > > > > > > 0.00%
> > > > > > > -
> > > org.apache.wicket.util.concurrent.ConcurrentHaspMap$Entry@0xd.
> > > > > ...
> > > > > > > 24 3928
> > > > > > > 0.00%
> > > > > > > -
> > > org.apache.wicket.util.concurrent.ConcurrentHaspMap$Entry@0xd.
> > > > > ...
> > > > > > > 24 3928
> > > > > > > 0.00%
> > > > > > > -
> > > org.apache.wicket.util.concurrent.ConcurrentHaspMap$Entry@0xd.
> > > > > ...
> > > > > > > 24 3928
> > > > > > > 0.00%
> > > > > > > + 2,863,659 more...
> > > > > > >
> > > > > > > Is that means that the Localizer Object used most of the heap
> > > size?
> > > > > > > or Is this number normal for Wicket App?
> > > > > > >
> > > > > > > I wonder whether I forget to release the memory by my
> mis-using
> > of
> > > > i18n
> > > > > > > feature?
> > > > > > > Is there any attentions I must pay to when dealing with
> > Localizer?
> > > > > > >
> > > > > > > This problem annoys me more the 2 weeks. I really need some
> > help.
> > > > > Thanks
> > > > > > .
> > > > > > >
> > > > > >
> > > > > >
> > > ---------------------------------------------------------------------
> > > > > > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> > > > > > For additional commands, e-mail: users-help@wicket.apache.org
> > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
Re: Why Localizer Retained so many heapsize?
Posted by Johan Compagner <jc...@gmail.com>.
no the api is just opened up to be able to create your own map impl
I can change it to be ICache. But the localizer currently just needs a
Map<String,String> thats a pretty common thing to have.
But i agree wit that contains call. thats just double up because if it is we
have too look it up again. I will remove it.
On Mon, May 12, 2008 at 11:39 AM, Jan Kriesten <ja...@renitence.de>
wrote:
>
> hi johan,
>
> why?
> > we just have a protected factory method now for a cache implementation
> > that
> > must be a map.
> >
>
> if you open up the api to change the implementation of the cache - there
> are other implementations than map... why limit it to map? (actually, I
> don't really understand the cache.containsKey(cacheKey) at all since it
> could just be checked for null when getting the value)...
>
>
> best regards, --- jan.
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
Re: Why Localizer Retained so many heapsize?
Posted by Jan Kriesten <ja...@renitence.de>.
hi johan,
> why?
> we just have a protected factory method now for a cache implementation that
> must be a map.
if you open up the api to change the implementation of the cache - there are
other implementations than map... why limit it to map? (actually, I don't really
understand the cache.containsKey(cacheKey) at all since it could just be checked
for null when getting the value)...
best regards, --- jan.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Why Localizer Retained so many heapsize?
Posted by Jan Kriesten <ja...@renitence.de>.
hi johan,
> we just have a protected factory method now for a cache implementation that
> must be a map.
another point to that: why not expecting a general cache implementation as you
do with MarkupCache.ICache ?
best regards, --- jan.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Why Localizer Retained so many heapsize?
Posted by Johan Compagner <jc...@gmail.com>.
why?
that cache will be used now and there in the localizer.
Because we also have support for not caching at all and then we have to test
the cache if it is null
we just have a protected factory method now for a cache implementation that
must be a map.
johan
On Mon, May 12, 2008 at 11:15 AM, Jan Kriesten <ja...@renitence.de>
wrote:
>
> hi johan,
>
> I will also open up Localizer api a bit more so that you can override the
> > cache that is used:
> >
>
> please make sure, that you also remove the direct access on the cache to
> check if it contains a certain key:
>
> // Value not found are cached as well (value = null)
> if ((cacheKey != null) && cache.containsKey(cacheKey))
>
>
> Best regards, --- Jan.
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
Re: Why Localizer Retained so many heapsize?
Posted by Jan Kriesten <ja...@renitence.de>.
hi johan,
> I will also open up Localizer api a bit more so that you can override the
> cache that is used:
please make sure, that you also remove the direct access on the cache to check
if it contains a certain key:
// Value not found are cached as well (value = null)
if ((cacheKey != null) && cache.containsKey(cacheKey))
Best regards, --- Jan.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Why Localizer Retained so many heapsize?
Posted by Johan Compagner <jc...@gmail.com>.
i guess you have a loads of null values somehow
Dont know why in your situation you have soo many of those.
What you could do is this in the init of your application:
Localizer localizer = new Localizer()
{
protected void putIntoCache(final String cacheKey, final String string)
{
if (string != null) super.putIntoCache(cacheKey,string);
}
};
getResourceSettings().setLocalizer(localizer);
this way you dont cache null values at all, only your real values.
If null values are asked a lot this could be slower ofcourse..
I will also open up Localizer api a bit more so that you can override the
cache that is used:
/**
* Create a new cache, override this method if you want a different map
to store the cache keys,
* for example a map that hold only the last X number of elements..
*
* By default it uses the {@link ConcurrentHashMap}
*
* @return cache
*/
protected Map newCache()
{
return new ConcurrentHashMap();
}
You could return there a map that evicts on the least recently used then.
johan
On Mon, May 12, 2008 at 9:41 AM, Quan Zhou <be...@gmail.com> wrote:
> Thanks iman.
>
> I explore many CocurrentHashMap$Entry to check its key/value.
> I truly found two things:
> 1. some key is large , its length would be more than 300 if the component
> has deep hierachy.That must be one of the reasons why Localizer is so big.
> 2. the number of this object is large too. there're 2,863,559 entrys. I
> couldn't check the whole objects one by one.but i was wondering
> why there're too many Entrys. There are about 2000 java files at most in
> my app, and no more than 500 wicket page/components with 2
> properties files , 1 html files in average. It means there are not
> huge
> properties or name that needs to retain in heapze ,so what things
> would those 2,863,559 entries supposed to contain?
>
> Is there any settings can control the limit of Entry size?or some strategy
> can reduce the key name of the entry?
>
>
> 2008/5/12 Iman Rahmatizadeh <im...@gmail.com>:
>
> > Well actually I haven't :-) My localizer gets quite large, but it hasnt
> > made
> > any problems, yet .
> > You see when the localizer wants to find the resource value for a
> specific
> > key, it caches the result into the localizer. Now if your component has
> a
> > deep hierarchy, the generated key will be quite large. In yourkit , use
> > the
> > object explorer to explore the ConcurrentHashMap entries and see why are
> > they so large, as I think the number of entries in the cache is limited,
> > So
> > the only explanation would be to see why are the key/values taking so
> much
> > space. If you can give a dump of one of the bigger key/values we can
> help
> > more.
> > Also the DiskPageStore doesnt hold on to anything in memory, so it wont
> > consume any memory, nothing strange about it.
> >
> > Iman
> >
> > On Mon, May 12, 2008 at 9:31 AM, Quan Zhou <be...@gmail.com> wrote:
> >
> > > Thanks for your all replys.
> > >
> > > I review the dump file with both SAP MemoryAnalyzer and YourKit
> > > They all show the same hierachy as follows:
> > >
> > > -org.apache.wicket.settings.Settings
> > > - org.apache.wicket.Localizer
> > > - org.apache.wicket.util.concurrent.ConcurrentHashMap
> > > - org.apache.wicket.util.concurrent.ConcurrentHashMap$Entry
> > >
> > > Localizer Object retaind 87.84% HeapSize. while the DiskPageStore only
> > > retained 0.71%
> > > That's weird,isn't it?
> > >
> > > I decrease the max heapsize settings to 50M, and make a load test then
> > > monitor the memory allocation.
> > > It indeed allocated more and more char[] objects time by time.
> > >
> > > Iman,how do you solve your problem at last?
> > > could you share some experience with me ? Thank you very much.
> > >
> > > 2008/5/10 Iman Rahmatizadeh <im...@gmail.com>:
> > >
> > > > I've seen this before, altough it wasnt 2GB, but in a small 70MB
> heap
> > > dump
> > > > the cache size was around 25MB. The ConcurrentHashMap caches a lot
> of
> > > > unneeded string keys, where the keys are quite large, maybe strings
> of
> > > size
> > > > 1k characters, like key :
> > > >
> > > >
> > >
> >
> "org.apache.wicket.extensions.markup.html.repeater.data.table.DataTable$1:rows-ir.co.meraat.avicenna.web.components.AvicennaDataTable$InnerDataTable:inner-table-ir.co.meraat.avicenna.web.components.AvicennaDataTable$1:filter-form-ir.co.meraat.avicenna.web.components.AvicennaDataTable:table-ir.co.meraat.avicenna.vita.GradesManagementPanel$1:studentSearch-ir.co.meraat.avicenna.vita.GradesManagementPanel:componentId-ir.co.meraat.avicenna.web.CompositePage:5-fa_IR-nullg.apache.wicket.markup.repeater.OddEvenItem:29-...."
> > > >
> > > > As you see the component hierarchy is dumped into the string, making
> > it
> > > > very
> > > > large. I guess we're both localizing a lot of strings, so our
> problem
> > > could
> > > > be the same.
> > > >
> > > > Iman
> > > >
> > > > On Sat, May 10, 2008 at 9:38 AM, Johan Compagner <
> jcompagner@gmail.com
> > >
> > > > wrote:
> > > >
> > > > > Can you really see what it holds?
> > > > > Almost 2G in memory in localizer is extreme... Thats really a lot
> of
> > > > > strings..
> > > > > You could try to read that dump with yourkit if your current one
> > > > > doesnt show enough.
> > > > >
> > > > > On 5/9/08, Quan Zhou <be...@gmail.com> wrote:
> > > > > > Hello everyone.
> > > > > >
> > > > > > I recently develop my App use Wicket1.3.3. It's my first time to
> > use
> > > > this
> > > > > > framework and I feel it's really really a perfect framework for
> > me.
> > > > > > My app support both Simplified Chinese , Traditional Chinese, I
> > > > implement
> > > > > > this with Wicket i18n feature.
> > > > > > With the load increasing these days, I found my app would become
> > > very
> > > > lag
> > > > > > abount every 24 hours ,so that i would only restart it
> > > > > > without any choice.
> > > > > > when I found the lag, My log records many Exceptions like :
> > > > > > "after 1 minute the Pagemap null is still locked by:
> > > > > > Thread[http-8080-321,5,main], giving
> > > > > > up trying to get the page for path xxx"
> > > > > >
> > > > > > I check the JVM status with jstat -gc , It tells that the
> Heapsize
> > > is
> > > > > full
> > > > > > even after full GC.
> > > > > > My VM paraemter is "-Xms2000m -Xmx2000m -XX:MaxNewSize=250m
> > > > > > -XX:MaxPermSize=250m"
> > > > > > My deploy server has 2*CPU and 4G memory, Redhat AS4 OS + tomcat
> > > 6.0.
> > > > > > There're 2000 sessions on the day while the timeout threshold is
> > 15
> > > > > minutes.
> > > > > > So i dump the whole heapsize with the command " jmap
> > > > > > -dump:live,format=b,file=3.dump.hprof processid"
> > > > > > and i truely get a 2G size dump files. I use SAP Memory Analyer
> to
> > > see
> > > > > > what're stored in HeapMemory.
> > > > > > and I found a strange number of Retained Heap usage:
> > > > > > Classname
> > > > > > ShallowHeap
> > > RetainHeap
> > > > > > RetainedHeap%
> > > > > > -org.apache.wicket.Localizer@0x78..
> > > > > > 16
> > > > > > 1,755,070,352 87.64%
> > > > > > -org.apache.wicket.util.concurrent.ConcurrentHashMap@0x79...
> > > > > > 48 1,755,070,336
> > > 87.69%
> > > > > >
> -org.apache.wicket.util.concurrent.ConcurrentHaspMap$Entry@0xd.
> > ...
> > > > > > 33,554,448
> > > > > > 1,755,069,632 87.69%
> > > > > > -
> > org.apache.wicket.util.concurrent.ConcurrentHaspMap$Entry@0xd.
> > > > ...
> > > > > > 24 3928
> > > > > > 0.00%
> > > > > > -
> > org.apache.wicket.util.concurrent.ConcurrentHaspMap$Entry@0xd.
> > > > ...
> > > > > > 24 3928
> > > > > > 0.00%
> > > > > > -
> > org.apache.wicket.util.concurrent.ConcurrentHaspMap$Entry@0xd.
> > > > ...
> > > > > > 24 3928
> > > > > > 0.00%
> > > > > > -
> > org.apache.wicket.util.concurrent.ConcurrentHaspMap$Entry@0xd.
> > > > ...
> > > > > > 24 3928
> > > > > > 0.00%
> > > > > > -
> > org.apache.wicket.util.concurrent.ConcurrentHaspMap$Entry@0xd.
> > > > ...
> > > > > > 24 3928
> > > > > > 0.00%
> > > > > > -
> > org.apache.wicket.util.concurrent.ConcurrentHaspMap$Entry@0xd.
> > > > ...
> > > > > > 24 3928
> > > > > > 0.00%
> > > > > > + 2,863,659 more...
> > > > > >
> > > > > > Is that means that the Localizer Object used most of the heap
> > size?
> > > > > > or Is this number normal for Wicket App?
> > > > > >
> > > > > > I wonder whether I forget to release the memory by my mis-using
> of
> > > i18n
> > > > > > feature?
> > > > > > Is there any attentions I must pay to when dealing with
> Localizer?
> > > > > >
> > > > > > This problem annoys me more the 2 weeks. I really need some
> help.
> > > > Thanks
> > > > > .
> > > > > >
> > > > >
> > > > >
> > ---------------------------------------------------------------------
> > > > > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> > > > > For additional commands, e-mail: users-help@wicket.apache.org
> > > > >
> > > > >
> > > >
> > >
> >
>
Re: Why Localizer Retained so many heapsize?
Posted by Quan Zhou <be...@gmail.com>.
Thanks iman.
I explore many CocurrentHashMap$Entry to check its key/value.
I truly found two things:
1. some key is large , its length would be more than 300 if the component
has deep hierachy.That must be one of the reasons why Localizer is so big.
2. the number of this object is large too. there're 2,863,559 entrys. I
couldn't check the whole objects one by one.but i was wondering
why there're too many Entrys. There are about 2000 java files at most in
my app, and no more than 500 wicket page/components with 2
properties files , 1 html files in average. It means there are not huge
properties or name that needs to retain in heapze ,so what things
would those 2,863,559 entries supposed to contain?
Is there any settings can control the limit of Entry size?or some strategy
can reduce the key name of the entry?
2008/5/12 Iman Rahmatizadeh <im...@gmail.com>:
> Well actually I haven't :-) My localizer gets quite large, but it hasnt
> made
> any problems, yet .
> You see when the localizer wants to find the resource value for a specific
> key, it caches the result into the localizer. Now if your component has a
> deep hierarchy, the generated key will be quite large. In yourkit , use
> the
> object explorer to explore the ConcurrentHashMap entries and see why are
> they so large, as I think the number of entries in the cache is limited,
> So
> the only explanation would be to see why are the key/values taking so much
> space. If you can give a dump of one of the bigger key/values we can help
> more.
> Also the DiskPageStore doesnt hold on to anything in memory, so it wont
> consume any memory, nothing strange about it.
>
> Iman
>
> On Mon, May 12, 2008 at 9:31 AM, Quan Zhou <be...@gmail.com> wrote:
>
> > Thanks for your all replys.
> >
> > I review the dump file with both SAP MemoryAnalyzer and YourKit
> > They all show the same hierachy as follows:
> >
> > -org.apache.wicket.settings.Settings
> > - org.apache.wicket.Localizer
> > - org.apache.wicket.util.concurrent.ConcurrentHashMap
> > - org.apache.wicket.util.concurrent.ConcurrentHashMap$Entry
> >
> > Localizer Object retaind 87.84% HeapSize. while the DiskPageStore only
> > retained 0.71%
> > That's weird,isn't it?
> >
> > I decrease the max heapsize settings to 50M, and make a load test then
> > monitor the memory allocation.
> > It indeed allocated more and more char[] objects time by time.
> >
> > Iman,how do you solve your problem at last?
> > could you share some experience with me ? Thank you very much.
> >
> > 2008/5/10 Iman Rahmatizadeh <im...@gmail.com>:
> >
> > > I've seen this before, altough it wasnt 2GB, but in a small 70MB heap
> > dump
> > > the cache size was around 25MB. The ConcurrentHashMap caches a lot of
> > > unneeded string keys, where the keys are quite large, maybe strings of
> > size
> > > 1k characters, like key :
> > >
> > >
> >
> "org.apache.wicket.extensions.markup.html.repeater.data.table.DataTable$1:rows-ir.co.meraat.avicenna.web.components.AvicennaDataTable$InnerDataTable:inner-table-ir.co.meraat.avicenna.web.components.AvicennaDataTable$1:filter-form-ir.co.meraat.avicenna.web.components.AvicennaDataTable:table-ir.co.meraat.avicenna.vita.GradesManagementPanel$1:studentSearch-ir.co.meraat.avicenna.vita.GradesManagementPanel:componentId-ir.co.meraat.avicenna.web.CompositePage:5-fa_IR-nullg.apache.wicket.markup.repeater.OddEvenItem:29-...."
> > >
> > > As you see the component hierarchy is dumped into the string, making
> it
> > > very
> > > large. I guess we're both localizing a lot of strings, so our problem
> > could
> > > be the same.
> > >
> > > Iman
> > >
> > > On Sat, May 10, 2008 at 9:38 AM, Johan Compagner <jcompagner@gmail.com
> >
> > > wrote:
> > >
> > > > Can you really see what it holds?
> > > > Almost 2G in memory in localizer is extreme... Thats really a lot of
> > > > strings..
> > > > You could try to read that dump with yourkit if your current one
> > > > doesnt show enough.
> > > >
> > > > On 5/9/08, Quan Zhou <be...@gmail.com> wrote:
> > > > > Hello everyone.
> > > > >
> > > > > I recently develop my App use Wicket1.3.3. It's my first time to
> use
> > > this
> > > > > framework and I feel it's really really a perfect framework for
> me.
> > > > > My app support both Simplified Chinese , Traditional Chinese, I
> > > implement
> > > > > this with Wicket i18n feature.
> > > > > With the load increasing these days, I found my app would become
> > very
> > > lag
> > > > > abount every 24 hours ,so that i would only restart it
> > > > > without any choice.
> > > > > when I found the lag, My log records many Exceptions like :
> > > > > "after 1 minute the Pagemap null is still locked by:
> > > > > Thread[http-8080-321,5,main], giving
> > > > > up trying to get the page for path xxx"
> > > > >
> > > > > I check the JVM status with jstat -gc , It tells that the Heapsize
> > is
> > > > full
> > > > > even after full GC.
> > > > > My VM paraemter is "-Xms2000m -Xmx2000m -XX:MaxNewSize=250m
> > > > > -XX:MaxPermSize=250m"
> > > > > My deploy server has 2*CPU and 4G memory, Redhat AS4 OS + tomcat
> > 6.0.
> > > > > There're 2000 sessions on the day while the timeout threshold is
> 15
> > > > minutes.
> > > > > So i dump the whole heapsize with the command " jmap
> > > > > -dump:live,format=b,file=3.dump.hprof processid"
> > > > > and i truely get a 2G size dump files. I use SAP Memory Analyer to
> > see
> > > > > what're stored in HeapMemory.
> > > > > and I found a strange number of Retained Heap usage:
> > > > > Classname
> > > > > ShallowHeap
> > RetainHeap
> > > > > RetainedHeap%
> > > > > -org.apache.wicket.Localizer@0x78..
> > > > > 16
> > > > > 1,755,070,352 87.64%
> > > > > -org.apache.wicket.util.concurrent.ConcurrentHashMap@0x79...
> > > > > 48 1,755,070,336
> > 87.69%
> > > > > -org.apache.wicket.util.concurrent.ConcurrentHaspMap$Entry@0xd.
> ...
> > > > > 33,554,448
> > > > > 1,755,069,632 87.69%
> > > > > -
> org.apache.wicket.util.concurrent.ConcurrentHaspMap$Entry@0xd.
> > > ...
> > > > > 24 3928
> > > > > 0.00%
> > > > > -
> org.apache.wicket.util.concurrent.ConcurrentHaspMap$Entry@0xd.
> > > ...
> > > > > 24 3928
> > > > > 0.00%
> > > > > -
> org.apache.wicket.util.concurrent.ConcurrentHaspMap$Entry@0xd.
> > > ...
> > > > > 24 3928
> > > > > 0.00%
> > > > > -
> org.apache.wicket.util.concurrent.ConcurrentHaspMap$Entry@0xd.
> > > ...
> > > > > 24 3928
> > > > > 0.00%
> > > > > -
> org.apache.wicket.util.concurrent.ConcurrentHaspMap$Entry@0xd.
> > > ...
> > > > > 24 3928
> > > > > 0.00%
> > > > > -
> org.apache.wicket.util.concurrent.ConcurrentHaspMap$Entry@0xd.
> > > ...
> > > > > 24 3928
> > > > > 0.00%
> > > > > + 2,863,659 more...
> > > > >
> > > > > Is that means that the Localizer Object used most of the heap
> size?
> > > > > or Is this number normal for Wicket App?
> > > > >
> > > > > I wonder whether I forget to release the memory by my mis-using of
> > i18n
> > > > > feature?
> > > > > Is there any attentions I must pay to when dealing with Localizer?
> > > > >
> > > > > This problem annoys me more the 2 weeks. I really need some help.
> > > Thanks
> > > > .
> > > > >
> > > >
> > > >
> ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> > > > For additional commands, e-mail: users-help@wicket.apache.org
> > > >
> > > >
> > >
> >
>
Re: Why Localizer Retained so many heapsize?
Posted by Iman Rahmatizadeh <im...@gmail.com>.
Well actually I haven't :-) My localizer gets quite large, but it hasnt made
any problems, yet .
You see when the localizer wants to find the resource value for a specific
key, it caches the result into the localizer. Now if your component has a
deep hierarchy, the generated key will be quite large. In yourkit , use the
object explorer to explore the ConcurrentHashMap entries and see why are
they so large, as I think the number of entries in the cache is limited, So
the only explanation would be to see why are the key/values taking so much
space. If you can give a dump of one of the bigger key/values we can help
more.
Also the DiskPageStore doesnt hold on to anything in memory, so it wont
consume any memory, nothing strange about it.
Iman
On Mon, May 12, 2008 at 9:31 AM, Quan Zhou <be...@gmail.com> wrote:
> Thanks for your all replys.
>
> I review the dump file with both SAP MemoryAnalyzer and YourKit
> They all show the same hierachy as follows:
>
> -org.apache.wicket.settings.Settings
> - org.apache.wicket.Localizer
> - org.apache.wicket.util.concurrent.ConcurrentHashMap
> - org.apache.wicket.util.concurrent.ConcurrentHashMap$Entry
>
> Localizer Object retaind 87.84% HeapSize. while the DiskPageStore only
> retained 0.71%
> That's weird,isn't it?
>
> I decrease the max heapsize settings to 50M, and make a load test then
> monitor the memory allocation.
> It indeed allocated more and more char[] objects time by time.
>
> Iman,how do you solve your problem at last?
> could you share some experience with me ? Thank you very much.
>
> 2008/5/10 Iman Rahmatizadeh <im...@gmail.com>:
>
> > I've seen this before, altough it wasnt 2GB, but in a small 70MB heap
> dump
> > the cache size was around 25MB. The ConcurrentHashMap caches a lot of
> > unneeded string keys, where the keys are quite large, maybe strings of
> size
> > 1k characters, like key :
> >
> >
> "org.apache.wicket.extensions.markup.html.repeater.data.table.DataTable$1:rows-ir.co.meraat.avicenna.web.components.AvicennaDataTable$InnerDataTable:inner-table-ir.co.meraat.avicenna.web.components.AvicennaDataTable$1:filter-form-ir.co.meraat.avicenna.web.components.AvicennaDataTable:table-ir.co.meraat.avicenna.vita.GradesManagementPanel$1:studentSearch-ir.co.meraat.avicenna.vita.GradesManagementPanel:componentId-ir.co.meraat.avicenna.web.CompositePage:5-fa_IR-nullg.apache.wicket.markup.repeater.OddEvenItem:29-...."
> >
> > As you see the component hierarchy is dumped into the string, making it
> > very
> > large. I guess we're both localizing a lot of strings, so our problem
> could
> > be the same.
> >
> > Iman
> >
> > On Sat, May 10, 2008 at 9:38 AM, Johan Compagner <jc...@gmail.com>
> > wrote:
> >
> > > Can you really see what it holds?
> > > Almost 2G in memory in localizer is extreme... Thats really a lot of
> > > strings..
> > > You could try to read that dump with yourkit if your current one
> > > doesnt show enough.
> > >
> > > On 5/9/08, Quan Zhou <be...@gmail.com> wrote:
> > > > Hello everyone.
> > > >
> > > > I recently develop my App use Wicket1.3.3. It's my first time to use
> > this
> > > > framework and I feel it's really really a perfect framework for me.
> > > > My app support both Simplified Chinese , Traditional Chinese, I
> > implement
> > > > this with Wicket i18n feature.
> > > > With the load increasing these days, I found my app would become
> very
> > lag
> > > > abount every 24 hours ,so that i would only restart it
> > > > without any choice.
> > > > when I found the lag, My log records many Exceptions like :
> > > > "after 1 minute the Pagemap null is still locked by:
> > > > Thread[http-8080-321,5,main], giving
> > > > up trying to get the page for path xxx"
> > > >
> > > > I check the JVM status with jstat -gc , It tells that the Heapsize
> is
> > > full
> > > > even after full GC.
> > > > My VM paraemter is "-Xms2000m -Xmx2000m -XX:MaxNewSize=250m
> > > > -XX:MaxPermSize=250m"
> > > > My deploy server has 2*CPU and 4G memory, Redhat AS4 OS + tomcat
> 6.0.
> > > > There're 2000 sessions on the day while the timeout threshold is 15
> > > minutes.
> > > > So i dump the whole heapsize with the command " jmap
> > > > -dump:live,format=b,file=3.dump.hprof processid"
> > > > and i truely get a 2G size dump files. I use SAP Memory Analyer to
> see
> > > > what're stored in HeapMemory.
> > > > and I found a strange number of Retained Heap usage:
> > > > Classname
> > > > ShallowHeap
> RetainHeap
> > > > RetainedHeap%
> > > > -org.apache.wicket.Localizer@0x78..
> > > > 16
> > > > 1,755,070,352 87.64%
> > > > -org.apache.wicket.util.concurrent.ConcurrentHashMap@0x79...
> > > > 48 1,755,070,336
> 87.69%
> > > > -org.apache.wicket.util.concurrent.ConcurrentHaspMap$Entry@0xd....
> > > > 33,554,448
> > > > 1,755,069,632 87.69%
> > > > - org.apache.wicket.util.concurrent.ConcurrentHaspMap$Entry@0xd.
> > ...
> > > > 24 3928
> > > > 0.00%
> > > > - org.apache.wicket.util.concurrent.ConcurrentHaspMap$Entry@0xd.
> > ...
> > > > 24 3928
> > > > 0.00%
> > > > - org.apache.wicket.util.concurrent.ConcurrentHaspMap$Entry@0xd.
> > ...
> > > > 24 3928
> > > > 0.00%
> > > > - org.apache.wicket.util.concurrent.ConcurrentHaspMap$Entry@0xd.
> > ...
> > > > 24 3928
> > > > 0.00%
> > > > - org.apache.wicket.util.concurrent.ConcurrentHaspMap$Entry@0xd.
> > ...
> > > > 24 3928
> > > > 0.00%
> > > > - org.apache.wicket.util.concurrent.ConcurrentHaspMap$Entry@0xd.
> > ...
> > > > 24 3928
> > > > 0.00%
> > > > + 2,863,659 more...
> > > >
> > > > Is that means that the Localizer Object used most of the heap size?
> > > > or Is this number normal for Wicket App?
> > > >
> > > > I wonder whether I forget to release the memory by my mis-using of
> i18n
> > > > feature?
> > > > Is there any attentions I must pay to when dealing with Localizer?
> > > >
> > > > This problem annoys me more the 2 weeks. I really need some help.
> > Thanks
> > > .
> > > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> > > For additional commands, e-mail: users-help@wicket.apache.org
> > >
> > >
> >
>
Re: Why Localizer Retained so many heapsize?
Posted by Quan Zhou <be...@gmail.com>.
Thanks for your all replys.
I review the dump file with both SAP MemoryAnalyzer and YourKit
They all show the same hierachy as follows:
-org.apache.wicket.settings.Settings
- org.apache.wicket.Localizer
- org.apache.wicket.util.concurrent.ConcurrentHashMap
- org.apache.wicket.util.concurrent.ConcurrentHashMap$Entry
Localizer Object retaind 87.84% HeapSize. while the DiskPageStore only
retained 0.71%
That's weird,isn't it?
I decrease the max heapsize settings to 50M, and make a load test then
monitor the memory allocation.
It indeed allocated more and more char[] objects time by time.
Iman,how do you solve your problem at last?
could you share some experience with me ? Thank you very much.
2008/5/10 Iman Rahmatizadeh <im...@gmail.com>:
> I've seen this before, altough it wasnt 2GB, but in a small 70MB heap dump
> the cache size was around 25MB. The ConcurrentHashMap caches a lot of
> unneeded string keys, where the keys are quite large, maybe strings of size
> 1k characters, like key :
>
> "org.apache.wicket.extensions.markup.html.repeater.data.table.DataTable$1:rows-ir.co.meraat.avicenna.web.components.AvicennaDataTable$InnerDataTable:inner-table-ir.co.meraat.avicenna.web.components.AvicennaDataTable$1:filter-form-ir.co.meraat.avicenna.web.components.AvicennaDataTable:table-ir.co.meraat.avicenna.vita.GradesManagementPanel$1:studentSearch-ir.co.meraat.avicenna.vita.GradesManagementPanel:componentId-ir.co.meraat.avicenna.web.CompositePage:5-fa_IR-nullg.apache.wicket.markup.repeater.OddEvenItem:29-...."
>
> As you see the component hierarchy is dumped into the string, making it
> very
> large. I guess we're both localizing a lot of strings, so our problem could
> be the same.
>
> Iman
>
> On Sat, May 10, 2008 at 9:38 AM, Johan Compagner <jc...@gmail.com>
> wrote:
>
> > Can you really see what it holds?
> > Almost 2G in memory in localizer is extreme... Thats really a lot of
> > strings..
> > You could try to read that dump with yourkit if your current one
> > doesnt show enough.
> >
> > On 5/9/08, Quan Zhou <be...@gmail.com> wrote:
> > > Hello everyone.
> > >
> > > I recently develop my App use Wicket1.3.3. It's my first time to use
> this
> > > framework and I feel it's really really a perfect framework for me.
> > > My app support both Simplified Chinese , Traditional Chinese, I
> implement
> > > this with Wicket i18n feature.
> > > With the load increasing these days, I found my app would become very
> lag
> > > abount every 24 hours ,so that i would only restart it
> > > without any choice.
> > > when I found the lag, My log records many Exceptions like :
> > > "after 1 minute the Pagemap null is still locked by:
> > > Thread[http-8080-321,5,main], giving
> > > up trying to get the page for path xxx"
> > >
> > > I check the JVM status with jstat -gc , It tells that the Heapsize is
> > full
> > > even after full GC.
> > > My VM paraemter is "-Xms2000m -Xmx2000m -XX:MaxNewSize=250m
> > > -XX:MaxPermSize=250m"
> > > My deploy server has 2*CPU and 4G memory, Redhat AS4 OS + tomcat 6.0.
> > > There're 2000 sessions on the day while the timeout threshold is 15
> > minutes.
> > > So i dump the whole heapsize with the command " jmap
> > > -dump:live,format=b,file=3.dump.hprof processid"
> > > and i truely get a 2G size dump files. I use SAP Memory Analyer to see
> > > what're stored in HeapMemory.
> > > and I found a strange number of Retained Heap usage:
> > > Classname
> > > ShallowHeap RetainHeap
> > > RetainedHeap%
> > > -org.apache.wicket.Localizer@0x78..
> > > 16
> > > 1,755,070,352 87.64%
> > > -org.apache.wicket.util.concurrent.ConcurrentHashMap@0x79...
> > > 48 1,755,070,336 87.69%
> > > -org.apache.wicket.util.concurrent.ConcurrentHaspMap$Entry@0xd....
> > > 33,554,448
> > > 1,755,069,632 87.69%
> > > - org.apache.wicket.util.concurrent.ConcurrentHaspMap$Entry@0xd.
> ...
> > > 24 3928
> > > 0.00%
> > > - org.apache.wicket.util.concurrent.ConcurrentHaspMap$Entry@0xd.
> ...
> > > 24 3928
> > > 0.00%
> > > - org.apache.wicket.util.concurrent.ConcurrentHaspMap$Entry@0xd.
> ...
> > > 24 3928
> > > 0.00%
> > > - org.apache.wicket.util.concurrent.ConcurrentHaspMap$Entry@0xd.
> ...
> > > 24 3928
> > > 0.00%
> > > - org.apache.wicket.util.concurrent.ConcurrentHaspMap$Entry@0xd.
> ...
> > > 24 3928
> > > 0.00%
> > > - org.apache.wicket.util.concurrent.ConcurrentHaspMap$Entry@0xd.
> ...
> > > 24 3928
> > > 0.00%
> > > + 2,863,659 more...
> > >
> > > Is that means that the Localizer Object used most of the heap size?
> > > or Is this number normal for Wicket App?
> > >
> > > I wonder whether I forget to release the memory by my mis-using of i18n
> > > feature?
> > > Is there any attentions I must pay to when dealing with Localizer?
> > >
> > > This problem annoys me more the 2 weeks. I really need some help.
> Thanks
> > .
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> > For additional commands, e-mail: users-help@wicket.apache.org
> >
> >
>
Re: Why Localizer Retained so many heapsize?
Posted by Iman Rahmatizadeh <im...@gmail.com>.
I've seen this before, altough it wasnt 2GB, but in a small 70MB heap dump
the cache size was around 25MB. The ConcurrentHashMap caches a lot of
unneeded string keys, where the keys are quite large, maybe strings of size
1k characters, like key :
"org.apache.wicket.extensions.markup.html.repeater.data.table.DataTable$1:rows-ir.co.meraat.avicenna.web.components.AvicennaDataTable$InnerDataTable:inner-table-ir.co.meraat.avicenna.web.components.AvicennaDataTable$1:filter-form-ir.co.meraat.avicenna.web.components.AvicennaDataTable:table-ir.co.meraat.avicenna.vita.GradesManagementPanel$1:studentSearch-ir.co.meraat.avicenna.vita.GradesManagementPanel:componentId-ir.co.meraat.avicenna.web.CompositePage:5-fa_IR-nullg.apache.wicket.markup.repeater.OddEvenItem:29-...."
As you see the component hierarchy is dumped into the string, making it very
large. I guess we're both localizing a lot of strings, so our problem could
be the same.
Iman
On Sat, May 10, 2008 at 9:38 AM, Johan Compagner <jc...@gmail.com>
wrote:
> Can you really see what it holds?
> Almost 2G in memory in localizer is extreme... Thats really a lot of
> strings..
> You could try to read that dump with yourkit if your current one
> doesnt show enough.
>
> On 5/9/08, Quan Zhou <be...@gmail.com> wrote:
> > Hello everyone.
> >
> > I recently develop my App use Wicket1.3.3. It's my first time to use this
> > framework and I feel it's really really a perfect framework for me.
> > My app support both Simplified Chinese , Traditional Chinese, I implement
> > this with Wicket i18n feature.
> > With the load increasing these days, I found my app would become very lag
> > abount every 24 hours ,so that i would only restart it
> > without any choice.
> > when I found the lag, My log records many Exceptions like :
> > "after 1 minute the Pagemap null is still locked by:
> > Thread[http-8080-321,5,main], giving
> > up trying to get the page for path xxx"
> >
> > I check the JVM status with jstat -gc , It tells that the Heapsize is
> full
> > even after full GC.
> > My VM paraemter is "-Xms2000m -Xmx2000m -XX:MaxNewSize=250m
> > -XX:MaxPermSize=250m"
> > My deploy server has 2*CPU and 4G memory, Redhat AS4 OS + tomcat 6.0.
> > There're 2000 sessions on the day while the timeout threshold is 15
> minutes.
> > So i dump the whole heapsize with the command " jmap
> > -dump:live,format=b,file=3.dump.hprof processid"
> > and i truely get a 2G size dump files. I use SAP Memory Analyer to see
> > what're stored in HeapMemory.
> > and I found a strange number of Retained Heap usage:
> > Classname
> > ShallowHeap RetainHeap
> > RetainedHeap%
> > -org.apache.wicket.Localizer@0x78..
> > 16
> > 1,755,070,352 87.64%
> > -org.apache.wicket.util.concurrent.ConcurrentHashMap@0x79...
> > 48 1,755,070,336 87.69%
> > -org.apache.wicket.util.concurrent.ConcurrentHaspMap$Entry@0xd....
> > 33,554,448
> > 1,755,069,632 87.69%
> > - org.apache.wicket.util.concurrent.ConcurrentHaspMap$Entry@0xd....
> > 24 3928
> > 0.00%
> > - org.apache.wicket.util.concurrent.ConcurrentHaspMap$Entry@0xd....
> > 24 3928
> > 0.00%
> > - org.apache.wicket.util.concurrent.ConcurrentHaspMap$Entry@0xd....
> > 24 3928
> > 0.00%
> > - org.apache.wicket.util.concurrent.ConcurrentHaspMap$Entry@0xd....
> > 24 3928
> > 0.00%
> > - org.apache.wicket.util.concurrent.ConcurrentHaspMap$Entry@0xd....
> > 24 3928
> > 0.00%
> > - org.apache.wicket.util.concurrent.ConcurrentHaspMap$Entry@0xd....
> > 24 3928
> > 0.00%
> > + 2,863,659 more...
> >
> > Is that means that the Localizer Object used most of the heap size?
> > or Is this number normal for Wicket App?
> >
> > I wonder whether I forget to release the memory by my mis-using of i18n
> > feature?
> > Is there any attentions I must pay to when dealing with Localizer?
> >
> > This problem annoys me more the 2 weeks. I really need some help. Thanks
> .
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
Re: Why Localizer Retained so many heapsize?
Posted by Quan Zhou <be...@gmail.com>.
i remove the code "cursor.getId()" from Localizer.getCacheKey and deploy it
to the server.
No more memory leak detected. the server runs well for several days.
Great thanks to Johan.
2008/5/15 Quan Zhou <be...@gmail.com>:
> Maybe you're right.
> Yesterday I deployed the application in a high load with a little fewer
> heapsize than the usual setting to see whether the same thing happened
> again,
> and now the heapsize usage increase little by little. the Full GC interval
> becomes shorter. I'm sure that several hours later.
> I deeply explore the cache key and value; as you said, some thing with same
> value but different key's store in the cache.
> like:
>
> first :
> woodPr_lab-com.wedomo.webgame.fbm3guo.wicket.reuse.ResourcePanel:resourcepanel-com.wedomo.webgame.fbm3guo.wicket.pages.map.MapSmall:4-zh_CN-null
> 产量：
> ironPr_lab-com.wedomo.webgame.fbm3guo.wicket.reuse.ResourcePanel:resourcepanel-com.wedomo.webgame.fbm3guo.wicket.pages.map.MapSmall:4-zh_CN-null
> 产量：
> cropPr_lab-com.wedomo.webgame.fbm3guo.wicket.reuse.ResourcePanel:resourcepanel-com.wedomo.webgame.fbm3guo.wicket.pages.map.MapSmall:4-zh_CN-null
> 产量：
>
> later:
> woodPr_lab-com.wedomo.webgame.fbm3guo.wicket.reuse.ResourcePanel:resourcepanel-com.wedomo.webgame.fbm3guo.wicket.pages.map.MapSmall:6-zh_CN-null
> 产量：
> ironPr_lab-com.wedomo.webgame.fbm3guo.wicket.reuse.ResourcePanel:resourcepanel-com.wedomo.webgame.fbm3guo.wicket.pages.map.MapSmall:6-zh_CN-null
> 产量：
> cropPr_lab-com.wedomo.webgame.fbm3guo.wicket.reuse.ResourcePanel:resourcepanel-com.wedomo.webgame.fbm3guo.wicket.pages.map.MapSmall:6-zh_CN-null
> 产量：
>
> the only difference is PageId . the source code of Locailzer.getCacheKey
> tells
> //
> for(Component cursor = component; cursor != null; cursor =
> cursor.getParent())
> {
> buffer.append("-").append(cursor.getClass().getName());
> buffer.append(":").append(cursor.getId());
> }
>
> so is the cursor.getId() useful when it represents a repeater? and whether
> i can remove it when it represents the page class?
> that would really reduce the cacheKey number I think.
>
> Johan, could you show me the code you fix with this problem please?
>
> Thanks for your great help!
>
>
>
>
>
> 2008/5/14 Johan Compagner <jc...@gmail.com>:
>
>> i fixed something in the localizer that it doesnt add the page id to the
>> cachekey string
>> that was your problem
>> everypage that was created also creates an localizer entry that is just
>> plain wrong.
>>
>> So the pageid is not in the path anymore.. i think this is what really
>> caused your constant growing cache
>>
>>
>> On Wed, May 14, 2008 at 5:04 PM, Quan Zhou <be...@gmail.com> wrote:
>>
>> > Yes , it would be a bit slower. I'm going to make more test to see what
>> > havn't store in cache.
>> > Maybe i can caculate how many percents it effect my application
>> performance
>> > after i deploy it in a high load circumstance.
>> >
>> > I'm not sure about what you said about your fix for not including page.
>> > can you make it some clear? thanks very much.
>> >
>> >
>> > 2008/5/14 Johan Compagner <jc...@gmail.com>:
>> >
>> > > ok so you dont store the tested cacheKey 's that returned null..
>> > > so that could result in a bit slower access because it is tried to
>> > resolve
>> > > everytime
>> > >
>> > > I do think that my fix for not including the page is solving your real
>> > mem
>> > > leak problem
>> > >
>> > > johan
>> > >
>> > >
>> > > On Wed, May 14, 2008 at 2:03 PM, Quan Zhou <be...@gmail.com>
>> wrote:
>> > >
>> > > > getResourceSettings().setLocalizer(new Localizer() {
>> > > > @Override
>> > > > public void putIntoCache(final String cacheKey,final
>> String
>> > > > string) {
>> > > > if (string != null && cacheKey!=null)
>> > > > super.putIntoCache(cacheKey, string);
>> > > > }
>> > > > });
>> > > >
>> > > >
>> > > >
>> > > > 2008/5/14 Johan Compagner <jc...@gmail.com>:
>> > > >
>> > > > > but what did you do there in that method?
>> > > > > nothing? you dont cache anything anymore?
>> > > > >
>> > > > > On Wed, May 14, 2008 at 10:29 AM, Quan Zhou <betogether@gmail.com
>> >
>> > > > wrote:
>> > > > >
>> > > > > > Hello everyone.
>> > > > > >
>> > > > > > I override Localizer.putIntoCache method. and it really reduce
>> the
>> > > > > > heapsize
>> > > > > > usage of Localizer.
>> > > > > >
>> > > > > > The application is more stable now although the key remains
>> large.
>> > > > > >
>> > > > > > Hope we can find a way to shorter the key length.
>> > > > > >
>> > > > > > thanks everyone.
>> > > > > >
>> > > > > > 2008/5/13 Eirik Rude <ei...@ballangrud.com>:
>> > > > > >
>> > > > > > >
>> > > > > > > A soft reference is very common for this type of thing. I
>> know
>> > > some
>> > > > of
>> > > > > > > ICU's
>> > > > > > > resources are stored this way.
>> > > > > > >
>> > > > > > >
>> > > > > > >
>> > > > > > > Jonathan Locke wrote:
>> > > > > > > >
>> > > > > > > >
>> > > > > > > > maybe localizer should limit its size or use a soft
>> reference
>> > > > cache?
>> > > > > > > >
>> > > > > > > >
>> > > > > > > > Johan Compagner wrote:
>> > > > > > > >>
>> > > > > > > >> Can you really see what it holds?
>> > > > > > > >> Almost 2G in memory in localizer is extreme... Thats really
>> a
>> > > lot
>> > > > of
>> > > > > > > >> strings..
>> > > > > > > >> You could try to read that dump with yourkit if your
>> current
>> > one
>> > > > > > > >> doesnt show enough.
>> > > > > > > >>
>> > > > > > > >> On 5/9/08, Quan Zhou <be...@gmail.com> wrote:
>> > > > > > > >>> Hello everyone.
>> > > > > > > >>>
>> > > > > > > >>> I recently develop my App use Wicket1.3.3. It's my first
>> time
>> > > to
>> > > > > use
>> > > > > > > >>> this
>> > > > > > > >>> framework and I feel it's really really a perfect
>> framework
>> > for
>> > > > me.
>> > > > > > > >>> My app support both Simplified Chinese , Traditional
>> Chinese,
>> > I
>> > > > > > > >>> implement
>> > > > > > > >>> this with Wicket i18n feature.
>> > > > > > > >>> With the load increasing these days, I found my app would
>> > > become
>> > > > > > very
>> > > > > > > >>> lag
>> > > > > > > >>> abount every 24 hours ,so that i would only restart it
>> > > > > > > >>> without any choice.
>> > > > > > > >>> when I found the lag, My log records many Exceptions like
>> :
>> > > > > > > >>> "after 1 minute the Pagemap null is still locked by:
>> > > > > > > >>> Thread[http-8080-321,5,main], giving
>> > > > > > > >>> up trying to get the page for path xxx"
>> > > > > > > >>>
>> > > > > > > >>> I check the JVM status with jstat -gc , It tells that the
>> > > > Heapsize
>> > > > > > is
>> > > > > > > >>> full
>> > > > > > > >>> even after full GC.
>> > > > > > > >>> My VM paraemter is "-Xms2000m -Xmx2000m
>> -XX:MaxNewSize=250m
>> > > > > > > >>> -XX:MaxPermSize=250m"
>> > > > > > > >>> My deploy server has 2*CPU and 4G memory, Redhat AS4 OS +
>> > > tomcat
>> > > > > > 6.0.
>> > > > > > > >>> There're 2000 sessions on the day while the timeout
>> threshold
>> > > is
>> > > > 15
>> > > > > > > >>> minutes.
>> > > > > > > >>> So i dump the whole heapsize with the command " jmap
>> > > > > > > >>> -dump:live,format=b,file=3.dump.hprof processid"
>> > > > > > > >>> and i truely get a 2G size dump files. I use SAP Memory
>> > Analyer
>> > > > to
>> > > > > > see
>> > > > > > > >>> what're stored in HeapMemory.
>> > > > > > > >>> and I found a strange number of Retained Heap usage:
>> > > > > > > >>> Classname
>> > > > > > > >>> ShallowHeap
>> > > > > > RetainHeap
>> > > > > > > >>> RetainedHeap%
>> > > > > > > >>> -org.apache.wicket.Localizer@0x78..
>> > > > > > > >>> 16
>> > > > > > > >>> 1,755,070,352 87.64%
>> > > > > > > >>>
>> -org.apache.wicket.util.concurrent.ConcurrentHashMap@0x79.
>> > ..
>> > > > > > > >>> 48 1,755,070,336
>> > > > > > 87.69%
>> > > > > > > >>>
>> > > > -org.apache.wicket.util.concurrent.ConcurrentHaspMap$Entry@0xd.
>> > > > > ...
>> > > > > > > >>> 33,554,448
>> > > > > > > >>> 1,755,069,632
>> > 87.69%
>> > > > > > > >>> -
>> > > > > org.apache.wicket.util.concurrent.ConcurrentHaspMap$Entry@0xd.
>> > > > > > > ...
>> > > > > > > >>> 24 3928
>> > > > > > > >>> 0.00%
>> > > > > > > >>> -
>> > > > > org.apache.wicket.util.concurrent.ConcurrentHaspMap$Entry@0xd.
>> > > > > > > ...
>> > > > > > > >>> 24 3928
>> > > > > > > >>> 0.00%
>> > > > > > > >>> -
>> > > > > org.apache.wicket.util.concurrent.ConcurrentHaspMap$Entry@0xd.
>> > > > > > > ...
>> > > > > > > >>> 24 3928
>> > > > > > > >>> 0.00%
>> > > > > > > >>> -
>> > > > > org.apache.wicket.util.concurrent.ConcurrentHaspMap$Entry@0xd.
>> > > > > > > ...
>> > > > > > > >>> 24 3928
>> > > > > > > >>> 0.00%
>> > > > > > > >>> -
>> > > > > org.apache.wicket.util.concurrent.ConcurrentHaspMap$Entry@0xd.
>> > > > > > > ...
>> > > > > > > >>> 24 3928
>> > > > > > > >>> 0.00%
>> > > > > > > >>> -
>> > > > > org.apache.wicket.util.concurrent.ConcurrentHaspMap$Entry@0xd.
>> > > > > > > ...
>> > > > > > > >>> 24 3928
>> > > > > > > >>> 0.00%
>> > > > > > > >>> + 2,863,659 more...
>> > > > > > > >>>
>> > > > > > > >>> Is that means that the Localizer Object used most of the
>> heap
>> > > > size?
>> > > > > > > >>> or Is this number normal for Wicket App?
>> > > > > > > >>>
>> > > > > > > >>> I wonder whether I forget to release the memory by my
>> > mis-using
>> > > > of
>> > > > > > > i18n
>> > > > > > > >>> feature?
>> > > > > > > >>> Is there any attentions I must pay to when dealing with
>> > > > Localizer?
>> > > > > > > >>>
>> > > > > > > >>> This problem annoys me more the 2 weeks. I really need
>> some
>> > > > help.
>> > > > > > > Thanks
>> > > > > > > >>> .
>> > > > > > > >>>
>> > > > > > > >>
>> > > > > > > >>
>> > > > >
>> ---------------------------------------------------------------------
>> > > > > > > >> To unsubscribe, e-mail:
>> users-unsubscribe@wicket.apache.org
>> > > > > > > >> For additional commands, e-mail:
>> users-help@wicket.apache.org
>> > > > > > > >>
>> > > > > > > >>
>> > > > > > > >>
>> > > > > > > >
>> > > > > > > >
>> > > > > > >
>> > > > > > > --
>> > > > > > > View this message in context:
>> > > > > > >
>> > > > > >
>> > > > >
>> > > >
>> > >
>> >
>> http://www.nabble.com/Why-Localizer-Retained-so-many-heapsize--tp17142582p17199950.html
>> > > > > > > Sent from the Wicket - User mailing list archive at
>> Nabble.com.
>> > > > > > >
>> > > > > > >
>> > > > > > >
>> > > >
>> ---------------------------------------------------------------------
>> > > > > > > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> > > > > > > For additional commands, e-mail: users-help@wicket.apache.org
>> > > > > > >
>> > > > > > >
>> > > > > >
>> > > > >
>> > > >
>> > >
>> >
>>
>
>
Re: Why Localizer Retained so many heapsize?
Posted by Quan Zhou <be...@gmail.com>.
Maybe you're right.
Yesterday I deployed the application in a high load with a little fewer
heapsize than the usual setting to see whether the same thing happened
again,
and now the heapsize usage increase little by little. the Full GC interval
becomes shorter. I'm sure that several hours later.
I deeply explore the cache key and value; as you said, some thing with same
value but different key's store in the cache.
like:
first :
woodPr_lab-com.wedomo.webgame.fbm3guo.wicket.reuse.ResourcePanel:resourcepanel-com.wedomo.webgame.fbm3guo.wicket.pages.map.MapSmall:4-zh_CN-null
产量：
ironPr_lab-com.wedomo.webgame.fbm3guo.wicket.reuse.ResourcePanel:resourcepanel-com.wedomo.webgame.fbm3guo.wicket.pages.map.MapSmall:4-zh_CN-null
产量：
cropPr_lab-com.wedomo.webgame.fbm3guo.wicket.reuse.ResourcePanel:resourcepanel-com.wedomo.webgame.fbm3guo.wicket.pages.map.MapSmall:4-zh_CN-null
产量：
later:
woodPr_lab-com.wedomo.webgame.fbm3guo.wicket.reuse.ResourcePanel:resourcepanel-com.wedomo.webgame.fbm3guo.wicket.pages.map.MapSmall:6-zh_CN-null
产量：
ironPr_lab-com.wedomo.webgame.fbm3guo.wicket.reuse.ResourcePanel:resourcepanel-com.wedomo.webgame.fbm3guo.wicket.pages.map.MapSmall:6-zh_CN-null
产量：
cropPr_lab-com.wedomo.webgame.fbm3guo.wicket.reuse.ResourcePanel:resourcepanel-com.wedomo.webgame.fbm3guo.wicket.pages.map.MapSmall:6-zh_CN-null
产量：
the only difference is PageId . the source code of Locailzer.getCacheKey
tells
//
for(Component cursor = component; cursor != null; cursor =
cursor.getParent())
{
buffer.append("-").append(cursor.getClass().getName());
buffer.append(":").append(cursor.getId());
}
so is the cursor.getId() useful when it represents a repeater? and whether i
can remove it when it represents the page class?
that would really reduce the cacheKey number I think.
Johan, could you show me the code you fix with this problem please?
Thanks for your great help!
2008/5/14 Johan Compagner <jc...@gmail.com>:
> i fixed something in the localizer that it doesnt add the page id to the
> cachekey string
> that was your problem
> everypage that was created also creates an localizer entry that is just
> plain wrong.
>
> So the pageid is not in the path anymore.. i think this is what really
> caused your constant growing cache
>
>
> On Wed, May 14, 2008 at 5:04 PM, Quan Zhou <be...@gmail.com> wrote:
>
> > Yes , it would be a bit slower. I'm going to make more test to see what
> > havn't store in cache.
> > Maybe i can caculate how many percents it effect my application
> performance
> > after i deploy it in a high load circumstance.
> >
> > I'm not sure about what you said about your fix for not including page.
> > can you make it some clear? thanks very much.
> >
> >
> > 2008/5/14 Johan Compagner <jc...@gmail.com>:
> >
> > > ok so you dont store the tested cacheKey 's that returned null..
> > > so that could result in a bit slower access because it is tried to
> > resolve
> > > everytime
> > >
> > > I do think that my fix for not including the page is solving your real
> > mem
> > > leak problem
> > >
> > > johan
> > >
> > >
> > > On Wed, May 14, 2008 at 2:03 PM, Quan Zhou <be...@gmail.com>
> wrote:
> > >
> > > > getResourceSettings().setLocalizer(new Localizer() {
> > > > @Override
> > > > public void putIntoCache(final String cacheKey,final
> String
> > > > string) {
> > > > if (string != null && cacheKey!=null)
> > > > super.putIntoCache(cacheKey, string);
> > > > }
> > > > });
> > > >
> > > >
> > > >
> > > > 2008/5/14 Johan Compagner <jc...@gmail.com>:
> > > >
> > > > > but what did you do there in that method?
> > > > > nothing? you dont cache anything anymore?
> > > > >
> > > > > On Wed, May 14, 2008 at 10:29 AM, Quan Zhou <be...@gmail.com>
> > > > wrote:
> > > > >
> > > > > > Hello everyone.
> > > > > >
> > > > > > I override Localizer.putIntoCache method. and it really reduce
> the
> > > > > > heapsize
> > > > > > usage of Localizer.
> > > > > >
> > > > > > The application is more stable now although the key remains
> large.
> > > > > >
> > > > > > Hope we can find a way to shorter the key length.
> > > > > >
> > > > > > thanks everyone.
> > > > > >
> > > > > > 2008/5/13 Eirik Rude <ei...@ballangrud.com>:
> > > > > >
> > > > > > >
> > > > > > > A soft reference is very common for this type of thing. I know
> > > some
> > > > of
> > > > > > > ICU's
> > > > > > > resources are stored this way.
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > Jonathan Locke wrote:
> > > > > > > >
> > > > > > > >
> > > > > > > > maybe localizer should limit its size or use a soft reference
> > > > cache?
> > > > > > > >
> > > > > > > >
> > > > > > > > Johan Compagner wrote:
> > > > > > > >>
> > > > > > > >> Can you really see what it holds?
> > > > > > > >> Almost 2G in memory in localizer is extreme... Thats really
> a
> > > lot
> > > > of
> > > > > > > >> strings..
> > > > > > > >> You could try to read that dump with yourkit if your current
> > one
> > > > > > > >> doesnt show enough.
> > > > > > > >>
> > > > > > > >> On 5/9/08, Quan Zhou <be...@gmail.com> wrote:
> > > > > > > >>> Hello everyone.
> > > > > > > >>>
> > > > > > > >>> I recently develop my App use Wicket1.3.3. It's my first
> time
> > > to
> > > > > use
> > > > > > > >>> this
> > > > > > > >>> framework and I feel it's really really a perfect framework
> > for
> > > > me.
> > > > > > > >>> My app support both Simplified Chinese , Traditional
> Chinese,
> > I
> > > > > > > >>> implement
> > > > > > > >>> this with Wicket i18n feature.
> > > > > > > >>> With the load increasing these days, I found my app would
> > > become
> > > > > > very
> > > > > > > >>> lag
> > > > > > > >>> abount every 24 hours ,so that i would only restart it
> > > > > > > >>> without any choice.
> > > > > > > >>> when I found the lag, My log records many Exceptions like :
> > > > > > > >>> "after 1 minute the Pagemap null is still locked by:
> > > > > > > >>> Thread[http-8080-321,5,main], giving
> > > > > > > >>> up trying to get the page for path xxx"
> > > > > > > >>>
> > > > > > > >>> I check the JVM status with jstat -gc , It tells that the
> > > > Heapsize
> > > > > > is
> > > > > > > >>> full
> > > > > > > >>> even after full GC.
> > > > > > > >>> My VM paraemter is "-Xms2000m -Xmx2000m -XX:MaxNewSize=250m
> > > > > > > >>> -XX:MaxPermSize=250m"
> > > > > > > >>> My deploy server has 2*CPU and 4G memory, Redhat AS4 OS +
> > > tomcat
> > > > > > 6.0.
> > > > > > > >>> There're 2000 sessions on the day while the timeout
> threshold
> > > is
> > > > 15
> > > > > > > >>> minutes.
> > > > > > > >>> So i dump the whole heapsize with the command " jmap
> > > > > > > >>> -dump:live,format=b,file=3.dump.hprof processid"
> > > > > > > >>> and i truely get a 2G size dump files. I use SAP Memory
> > Analyer
> > > > to
> > > > > > see
> > > > > > > >>> what're stored in HeapMemory.
> > > > > > > >>> and I found a strange number of Retained Heap usage:
> > > > > > > >>> Classname
> > > > > > > >>> ShallowHeap
> > > > > > RetainHeap
> > > > > > > >>> RetainedHeap%
> > > > > > > >>> -org.apache.wicket.Localizer@0x78..
> > > > > > > >>> 16
> > > > > > > >>> 1,755,070,352 87.64%
> > > > > > > >>> -org.apache.wicket.util.concurrent.ConcurrentHashMap@0x79.
> > ..
> > > > > > > >>> 48 1,755,070,336
> > > > > > 87.69%
> > > > > > > >>>
> > > > -org.apache.wicket.util.concurrent.ConcurrentHaspMap$Entry@0xd.
> > > > > ...
> > > > > > > >>> 33,554,448
> > > > > > > >>> 1,755,069,632
> > 87.69%
> > > > > > > >>> -
> > > > > org.apache.wicket.util.concurrent.ConcurrentHaspMap$Entry@0xd.
> > > > > > > ...
> > > > > > > >>> 24 3928
> > > > > > > >>> 0.00%
> > > > > > > >>> -
> > > > > org.apache.wicket.util.concurrent.ConcurrentHaspMap$Entry@0xd.
> > > > > > > ...
> > > > > > > >>> 24 3928
> > > > > > > >>> 0.00%
> > > > > > > >>> -
> > > > > org.apache.wicket.util.concurrent.ConcurrentHaspMap$Entry@0xd.
> > > > > > > ...
> > > > > > > >>> 24 3928
> > > > > > > >>> 0.00%
> > > > > > > >>> -
> > > > > org.apache.wicket.util.concurrent.ConcurrentHaspMap$Entry@0xd.
> > > > > > > ...
> > > > > > > >>> 24 3928
> > > > > > > >>> 0.00%
> > > > > > > >>> -
> > > > > org.apache.wicket.util.concurrent.ConcurrentHaspMap$Entry@0xd.
> > > > > > > ...
> > > > > > > >>> 24 3928
> > > > > > > >>> 0.00%
> > > > > > > >>> -
> > > > > org.apache.wicket.util.concurrent.ConcurrentHaspMap$Entry@0xd.
> > > > > > > ...
> > > > > > > >>> 24 3928
> > > > > > > >>> 0.00%
> > > > > > > >>> + 2,863,659 more...
> > > > > > > >>>
> > > > > > > >>> Is that means that the Localizer Object used most of the
> heap
> > > > size?
> > > > > > > >>> or Is this number normal for Wicket App?
> > > > > > > >>>
> > > > > > > >>> I wonder whether I forget to release the memory by my
> > mis-using
> > > > of
> > > > > > > i18n
> > > > > > > >>> feature?
> > > > > > > >>> Is there any attentions I must pay to when dealing with
> > > > Localizer?
> > > > > > > >>>
> > > > > > > >>> This problem annoys me more the 2 weeks. I really need some
> > > > help.
> > > > > > > Thanks
> > > > > > > >>> .
> > > > > > > >>>
> > > > > > > >>
> > > > > > > >>
> > > > >
> ---------------------------------------------------------------------
> > > > > > > >> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> > > > > > > >> For additional commands, e-mail:
> users-help@wicket.apache.org
> > > > > > > >>
> > > > > > > >>
> > > > > > > >>
> > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > > > --
> > > > > > > View this message in context:
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> http://www.nabble.com/Why-Localizer-Retained-so-many-heapsize--tp17142582p17199950.html
> > > > > > > Sent from the Wicket - User mailing list archive at Nabble.com.
> > > > > > >
> > > > > > >
> > > > > > >
> > > > ---------------------------------------------------------------------
> > > > > > > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> > > > > > > For additional commands, e-mail: users-help@wicket.apache.org
> > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
Re: Why Localizer Retained so many heapsize?
Posted by Johan Compagner <jc...@gmail.com>.
i fixed something in the localizer that it doesnt add the page id to the
cachekey string
that was your problem
everypage that was created also creates an localizer entry that is just
plain wrong.
So the pageid is not in the path anymore.. i think this is what really
caused your constant growing cache
On Wed, May 14, 2008 at 5:04 PM, Quan Zhou <be...@gmail.com> wrote:
> Yes , it would be a bit slower. I'm going to make more test to see what
> havn't store in cache.
> Maybe i can caculate how many percents it effect my application performance
> after i deploy it in a high load circumstance.
>
> I'm not sure about what you said about your fix for not including page.
> can you make it some clear? thanks very much.
>
>
> 2008/5/14 Johan Compagner <jc...@gmail.com>:
>
> > ok so you dont store the tested cacheKey 's that returned null..
> > so that could result in a bit slower access because it is tried to
> resolve
> > everytime
> >
> > I do think that my fix for not including the page is solving your real
> mem
> > leak problem
> >
> > johan
> >
> >
> > On Wed, May 14, 2008 at 2:03 PM, Quan Zhou <be...@gmail.com> wrote:
> >
> > > getResourceSettings().setLocalizer(new Localizer() {
> > > @Override
> > > public void putIntoCache(final String cacheKey,final String
> > > string) {
> > > if (string != null && cacheKey!=null)
> > > super.putIntoCache(cacheKey, string);
> > > }
> > > });
> > >
> > >
> > >
> > > 2008/5/14 Johan Compagner <jc...@gmail.com>:
> > >
> > > > but what did you do there in that method?
> > > > nothing? you dont cache anything anymore?
> > > >
> > > > On Wed, May 14, 2008 at 10:29 AM, Quan Zhou <be...@gmail.com>
> > > wrote:
> > > >
> > > > > Hello everyone.
> > > > >
> > > > > I override Localizer.putIntoCache method. and it really reduce the
> > > > > heapsize
> > > > > usage of Localizer.
> > > > >
> > > > > The application is more stable now although the key remains large.
> > > > >
> > > > > Hope we can find a way to shorter the key length.
> > > > >
> > > > > thanks everyone.
> > > > >
> > > > > 2008/5/13 Eirik Rude <ei...@ballangrud.com>:
> > > > >
> > > > > >
> > > > > > A soft reference is very common for this type of thing. I know
> > some
> > > of
> > > > > > ICU's
> > > > > > resources are stored this way.
> > > > > >
> > > > > >
> > > > > >
> > > > > > Jonathan Locke wrote:
> > > > > > >
> > > > > > >
> > > > > > > maybe localizer should limit its size or use a soft reference
> > > cache?
> > > > > > >
> > > > > > >
> > > > > > > Johan Compagner wrote:
> > > > > > >>
> > > > > > >> Can you really see what it holds?
> > > > > > >> Almost 2G in memory in localizer is extreme... Thats really a
> > lot
> > > of
> > > > > > >> strings..
> > > > > > >> You could try to read that dump with yourkit if your current
> one
> > > > > > >> doesnt show enough.
> > > > > > >>
> > > > > > >> On 5/9/08, Quan Zhou <be...@gmail.com> wrote:
> > > > > > >>> Hello everyone.
> > > > > > >>>
> > > > > > >>> I recently develop my App use Wicket1.3.3. It's my first time
> > to
> > > > use
> > > > > > >>> this
> > > > > > >>> framework and I feel it's really really a perfect framework
> for
> > > me.
> > > > > > >>> My app support both Simplified Chinese , Traditional Chinese,
> I
> > > > > > >>> implement
> > > > > > >>> this with Wicket i18n feature.
> > > > > > >>> With the load increasing these days, I found my app would
> > become
> > > > > very
> > > > > > >>> lag
> > > > > > >>> abount every 24 hours ,so that i would only restart it
> > > > > > >>> without any choice.
> > > > > > >>> when I found the lag, My log records many Exceptions like :
> > > > > > >>> "after 1 minute the Pagemap null is still locked by:
> > > > > > >>> Thread[http-8080-321,5,main], giving
> > > > > > >>> up trying to get the page for path xxx"
> > > > > > >>>
> > > > > > >>> I check the JVM status with jstat -gc , It tells that the
> > > Heapsize
> > > > > is
> > > > > > >>> full
> > > > > > >>> even after full GC.
> > > > > > >>> My VM paraemter is "-Xms2000m -Xmx2000m -XX:MaxNewSize=250m
> > > > > > >>> -XX:MaxPermSize=250m"
> > > > > > >>> My deploy server has 2*CPU and 4G memory, Redhat AS4 OS +
> > tomcat
> > > > > 6.0.
> > > > > > >>> There're 2000 sessions on the day while the timeout threshold
> > is
> > > 15
> > > > > > >>> minutes.
> > > > > > >>> So i dump the whole heapsize with the command " jmap
> > > > > > >>> -dump:live,format=b,file=3.dump.hprof processid"
> > > > > > >>> and i truely get a 2G size dump files. I use SAP Memory
> Analyer
> > > to
> > > > > see
> > > > > > >>> what're stored in HeapMemory.
> > > > > > >>> and I found a strange number of Retained Heap usage:
> > > > > > >>> Classname
> > > > > > >>> ShallowHeap
> > > > > RetainHeap
> > > > > > >>> RetainedHeap%
> > > > > > >>> -org.apache.wicket.Localizer@0x78..
> > > > > > >>> 16
> > > > > > >>> 1,755,070,352 87.64%
> > > > > > >>> -org.apache.wicket.util.concurrent.ConcurrentHashMap@0x79.
> ..
> > > > > > >>> 48 1,755,070,336
> > > > > 87.69%
> > > > > > >>>
> > > -org.apache.wicket.util.concurrent.ConcurrentHaspMap$Entry@0xd.
> > > > ...
> > > > > > >>> 33,554,448
> > > > > > >>> 1,755,069,632
> 87.69%
> > > > > > >>> -
> > > > org.apache.wicket.util.concurrent.ConcurrentHaspMap$Entry@0xd.
> > > > > > ...
> > > > > > >>> 24 3928
> > > > > > >>> 0.00%
> > > > > > >>> -
> > > > org.apache.wicket.util.concurrent.ConcurrentHaspMap$Entry@0xd.
> > > > > > ...
> > > > > > >>> 24 3928
> > > > > > >>> 0.00%
> > > > > > >>> -
> > > > org.apache.wicket.util.concurrent.ConcurrentHaspMap$Entry@0xd.
> > > > > > ...
> > > > > > >>> 24 3928
> > > > > > >>> 0.00%
> > > > > > >>> -
> > > > org.apache.wicket.util.concurrent.ConcurrentHaspMap$Entry@0xd.
> > > > > > ...
> > > > > > >>> 24 3928
> > > > > > >>> 0.00%
> > > > > > >>> -
> > > > org.apache.wicket.util.concurrent.ConcurrentHaspMap$Entry@0xd.
> > > > > > ...
> > > > > > >>> 24 3928
> > > > > > >>> 0.00%
> > > > > > >>> -
> > > > org.apache.wicket.util.concurrent.ConcurrentHaspMap$Entry@0xd.
> > > > > > ...
> > > > > > >>> 24 3928
> > > > > > >>> 0.00%
> > > > > > >>> + 2,863,659 more...
> > > > > > >>>
> > > > > > >>> Is that means that the Localizer Object used most of the heap
> > > size?
> > > > > > >>> or Is this number normal for Wicket App?
> > > > > > >>>
> > > > > > >>> I wonder whether I forget to release the memory by my
> mis-using
> > > of
> > > > > > i18n
> > > > > > >>> feature?
> > > > > > >>> Is there any attentions I must pay to when dealing with
> > > Localizer?
> > > > > > >>>
> > > > > > >>> This problem annoys me more the 2 weeks. I really need some
> > > help.
> > > > > > Thanks
> > > > > > >>> .
> > > > > > >>>
> > > > > > >>
> > > > > > >>
> > > > ---------------------------------------------------------------------
> > > > > > >> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> > > > > > >> For additional commands, e-mail: users-help@wicket.apache.org
> > > > > > >>
> > > > > > >>
> > > > > > >>
> > > > > > >
> > > > > > >
> > > > > >
> > > > > > --
> > > > > > View this message in context:
> > > > > >
> > > > >
> > > >
> > >
> >
> http://www.nabble.com/Why-Localizer-Retained-so-many-heapsize--tp17142582p17199950.html
> > > > > > Sent from the Wicket - User mailing list archive at Nabble.com.
> > > > > >
> > > > > >
> > > > > >
> > > ---------------------------------------------------------------------
> > > > > > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> > > > > > For additional commands, e-mail: users-help@wicket.apache.org
> > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
Re: Why Localizer Retained so many heapsize?
Posted by Quan Zhou <be...@gmail.com>.
Yes , it would be a bit slower. I'm going to make more test to see what
havn't store in cache.
Maybe i can caculate how many percents it effect my application performance
after i deploy it in a high load circumstance.
I'm not sure about what you said about your fix for not including page.
can you make it some clear? thanks very much.
2008/5/14 Johan Compagner <jc...@gmail.com>:
> ok so you dont store the tested cacheKey 's that returned null..
> so that could result in a bit slower access because it is tried to resolve
> everytime
>
> I do think that my fix for not including the page is solving your real mem
> leak problem
>
> johan
>
>
> On Wed, May 14, 2008 at 2:03 PM, Quan Zhou <be...@gmail.com> wrote:
>
> > getResourceSettings().setLocalizer(new Localizer() {
> > @Override
> > public void putIntoCache(final String cacheKey,final String
> > string) {
> > if (string != null && cacheKey!=null)
> > super.putIntoCache(cacheKey, string);
> > }
> > });
> >
> >
> >
> > 2008/5/14 Johan Compagner <jc...@gmail.com>:
> >
> > > but what did you do there in that method?
> > > nothing? you dont cache anything anymore?
> > >
> > > On Wed, May 14, 2008 at 10:29 AM, Quan Zhou <be...@gmail.com>
> > wrote:
> > >
> > > > Hello everyone.
> > > >
> > > > I override Localizer.putIntoCache method. and it really reduce the
> > > > heapsize
> > > > usage of Localizer.
> > > >
> > > > The application is more stable now although the key remains large.
> > > >
> > > > Hope we can find a way to shorter the key length.
> > > >
> > > > thanks everyone.
> > > >
> > > > 2008/5/13 Eirik Rude <ei...@ballangrud.com>:
> > > >
> > > > >
> > > > > A soft reference is very common for this type of thing. I know
> some
> > of
> > > > > ICU's
> > > > > resources are stored this way.
> > > > >
> > > > >
> > > > >
> > > > > Jonathan Locke wrote:
> > > > > >
> > > > > >
> > > > > > maybe localizer should limit its size or use a soft reference
> > cache?
> > > > > >
> > > > > >
> > > > > > Johan Compagner wrote:
> > > > > >>
> > > > > >> Can you really see what it holds?
> > > > > >> Almost 2G in memory in localizer is extreme... Thats really a
> lot
> > of
> > > > > >> strings..
> > > > > >> You could try to read that dump with yourkit if your current one
> > > > > >> doesnt show enough.
> > > > > >>
> > > > > >> On 5/9/08, Quan Zhou <be...@gmail.com> wrote:
> > > > > >>> Hello everyone.
> > > > > >>>
> > > > > >>> I recently develop my App use Wicket1.3.3. It's my first time
> to
> > > use
> > > > > >>> this
> > > > > >>> framework and I feel it's really really a perfect framework for
> > me.
> > > > > >>> My app support both Simplified Chinese , Traditional Chinese, I
> > > > > >>> implement
> > > > > >>> this with Wicket i18n feature.
> > > > > >>> With the load increasing these days, I found my app would
> become
> > > > very
> > > > > >>> lag
> > > > > >>> abount every 24 hours ,so that i would only restart it
> > > > > >>> without any choice.
> > > > > >>> when I found the lag, My log records many Exceptions like :
> > > > > >>> "after 1 minute the Pagemap null is still locked by:
> > > > > >>> Thread[http-8080-321,5,main], giving
> > > > > >>> up trying to get the page for path xxx"
> > > > > >>>
> > > > > >>> I check the JVM status with jstat -gc , It tells that the
> > Heapsize
> > > > is
> > > > > >>> full
> > > > > >>> even after full GC.
> > > > > >>> My VM paraemter is "-Xms2000m -Xmx2000m -XX:MaxNewSize=250m
> > > > > >>> -XX:MaxPermSize=250m"
> > > > > >>> My deploy server has 2*CPU and 4G memory, Redhat AS4 OS +
> tomcat
> > > > 6.0.
> > > > > >>> There're 2000 sessions on the day while the timeout threshold
> is
> > 15
> > > > > >>> minutes.
> > > > > >>> So i dump the whole heapsize with the command " jmap
> > > > > >>> -dump:live,format=b,file=3.dump.hprof processid"
> > > > > >>> and i truely get a 2G size dump files. I use SAP Memory Analyer
> > to
> > > > see
> > > > > >>> what're stored in HeapMemory.
> > > > > >>> and I found a strange number of Retained Heap usage:
> > > > > >>> Classname
> > > > > >>> ShallowHeap
> > > > RetainHeap
> > > > > >>> RetainedHeap%
> > > > > >>> -org.apache.wicket.Localizer@0x78..
> > > > > >>> 16
> > > > > >>> 1,755,070,352 87.64%
> > > > > >>> -org.apache.wicket.util.concurrent.ConcurrentHashMap@0x79...
> > > > > >>> 48 1,755,070,336
> > > > 87.69%
> > > > > >>>
> > -org.apache.wicket.util.concurrent.ConcurrentHaspMap$Entry@0xd.
> > > ...
> > > > > >>> 33,554,448
> > > > > >>> 1,755,069,632 87.69%
> > > > > >>> -
> > > org.apache.wicket.util.concurrent.ConcurrentHaspMap$Entry@0xd.
> > > > > ...
> > > > > >>> 24 3928
> > > > > >>> 0.00%
> > > > > >>> -
> > > org.apache.wicket.util.concurrent.ConcurrentHaspMap$Entry@0xd.
> > > > > ...
> > > > > >>> 24 3928
> > > > > >>> 0.00%
> > > > > >>> -
> > > org.apache.wicket.util.concurrent.ConcurrentHaspMap$Entry@0xd.
> > > > > ...
> > > > > >>> 24 3928
> > > > > >>> 0.00%
> > > > > >>> -
> > > org.apache.wicket.util.concurrent.ConcurrentHaspMap$Entry@0xd.
> > > > > ...
> > > > > >>> 24 3928
> > > > > >>> 0.00%
> > > > > >>> -
> > > org.apache.wicket.util.concurrent.ConcurrentHaspMap$Entry@0xd.
> > > > > ...
> > > > > >>> 24 3928
> > > > > >>> 0.00%
> > > > > >>> -
> > > org.apache.wicket.util.concurrent.ConcurrentHaspMap$Entry@0xd.
> > > > > ...
> > > > > >>> 24 3928
> > > > > >>> 0.00%
> > > > > >>> + 2,863,659 more...
> > > > > >>>
> > > > > >>> Is that means that the Localizer Object used most of the heap
> > size?
> > > > > >>> or Is this number normal for Wicket App?
> > > > > >>>
> > > > > >>> I wonder whether I forget to release the memory by my mis-using
> > of
> > > > > i18n
> > > > > >>> feature?
> > > > > >>> Is there any attentions I must pay to when dealing with
> > Localizer?
> > > > > >>>
> > > > > >>> This problem annoys me more the 2 weeks. I really need some
> > help.
> > > > > Thanks
> > > > > >>> .
> > > > > >>>
> > > > > >>
> > > > > >>
> > > ---------------------------------------------------------------------
> > > > > >> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> > > > > >> For additional commands, e-mail: users-help@wicket.apache.org
> > > > > >>
> > > > > >>
> > > > > >>
> > > > > >
> > > > > >
> > > > >
> > > > > --
> > > > > View this message in context:
> > > > >
> > > >
> > >
> >
> http://www.nabble.com/Why-Localizer-Retained-so-many-heapsize--tp17142582p17199950.html
> > > > > Sent from the Wicket - User mailing list archive at Nabble.com.
> > > > >
> > > > >
> > > > >
> > ---------------------------------------------------------------------
> > > > > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> > > > > For additional commands, e-mail: users-help@wicket.apache.org
> > > > >
> > > > >
> > > >
> > >
> >
>
Re: Why Localizer Retained so many heapsize?
Posted by Johan Compagner <jc...@gmail.com>.
ok so you dont store the tested cacheKey 's that returned null..
so that could result in a bit slower access because it is tried to resolve
everytime
I do think that my fix for not including the page is solving your real mem
leak problem
johan
On Wed, May 14, 2008 at 2:03 PM, Quan Zhou <be...@gmail.com> wrote:
> getResourceSettings().setLocalizer(new Localizer() {
> @Override
> public void putIntoCache(final String cacheKey,final String
> string) {
> if (string != null && cacheKey!=null)
> super.putIntoCache(cacheKey, string);
> }
> });
>
>
>
> 2008/5/14 Johan Compagner <jc...@gmail.com>:
>
> > but what did you do there in that method?
> > nothing? you dont cache anything anymore?
> >
> > On Wed, May 14, 2008 at 10:29 AM, Quan Zhou <be...@gmail.com>
> wrote:
> >
> > > Hello everyone.
> > >
> > > I override Localizer.putIntoCache method. and it really reduce the
> > > heapsize
> > > usage of Localizer.
> > >
> > > The application is more stable now although the key remains large.
> > >
> > > Hope we can find a way to shorter the key length.
> > >
> > > thanks everyone.
> > >
> > > 2008/5/13 Eirik Rude <ei...@ballangrud.com>:
> > >
> > > >
> > > > A soft reference is very common for this type of thing. I know some
> of
> > > > ICU's
> > > > resources are stored this way.
> > > >
> > > >
> > > >
> > > > Jonathan Locke wrote:
> > > > >
> > > > >
> > > > > maybe localizer should limit its size or use a soft reference
> cache?
> > > > >
> > > > >
> > > > > Johan Compagner wrote:
> > > > >>
> > > > >> Can you really see what it holds?
> > > > >> Almost 2G in memory in localizer is extreme... Thats really a lot
> of
> > > > >> strings..
> > > > >> You could try to read that dump with yourkit if your current one
> > > > >> doesnt show enough.
> > > > >>
> > > > >> On 5/9/08, Quan Zhou <be...@gmail.com> wrote:
> > > > >>> Hello everyone.
> > > > >>>
> > > > >>> I recently develop my App use Wicket1.3.3. It's my first time to
> > use
> > > > >>> this
> > > > >>> framework and I feel it's really really a perfect framework for
> me.
> > > > >>> My app support both Simplified Chinese , Traditional Chinese, I
> > > > >>> implement
> > > > >>> this with Wicket i18n feature.
> > > > >>> With the load increasing these days, I found my app would become
> > > very
> > > > >>> lag
> > > > >>> abount every 24 hours ,so that i would only restart it
> > > > >>> without any choice.
> > > > >>> when I found the lag, My log records many Exceptions like :
> > > > >>> "after 1 minute the Pagemap null is still locked by:
> > > > >>> Thread[http-8080-321,5,main], giving
> > > > >>> up trying to get the page for path xxx"
> > > > >>>
> > > > >>> I check the JVM status with jstat -gc , It tells that the
> Heapsize
> > > is
> > > > >>> full
> > > > >>> even after full GC.
> > > > >>> My VM paraemter is "-Xms2000m -Xmx2000m -XX:MaxNewSize=250m
> > > > >>> -XX:MaxPermSize=250m"
> > > > >>> My deploy server has 2*CPU and 4G memory, Redhat AS4 OS + tomcat
> > > 6.0.
> > > > >>> There're 2000 sessions on the day while the timeout threshold is
> 15
> > > > >>> minutes.
> > > > >>> So i dump the whole heapsize with the command " jmap
> > > > >>> -dump:live,format=b,file=3.dump.hprof processid"
> > > > >>> and i truely get a 2G size dump files. I use SAP Memory Analyer
> to
> > > see
> > > > >>> what're stored in HeapMemory.
> > > > >>> and I found a strange number of Retained Heap usage:
> > > > >>> Classname
> > > > >>> ShallowHeap
> > > RetainHeap
> > > > >>> RetainedHeap%
> > > > >>> -org.apache.wicket.Localizer@0x78..
> > > > >>> 16
> > > > >>> 1,755,070,352 87.64%
> > > > >>> -org.apache.wicket.util.concurrent.ConcurrentHashMap@0x79...
> > > > >>> 48 1,755,070,336
> > > 87.69%
> > > > >>>
> -org.apache.wicket.util.concurrent.ConcurrentHaspMap$Entry@0xd.
> > ...
> > > > >>> 33,554,448
> > > > >>> 1,755,069,632 87.69%
> > > > >>> -
> > org.apache.wicket.util.concurrent.ConcurrentHaspMap$Entry@0xd.
> > > > ...
> > > > >>> 24 3928
> > > > >>> 0.00%
> > > > >>> -
> > org.apache.wicket.util.concurrent.ConcurrentHaspMap$Entry@0xd.
> > > > ...
> > > > >>> 24 3928
> > > > >>> 0.00%
> > > > >>> -
> > org.apache.wicket.util.concurrent.ConcurrentHaspMap$Entry@0xd.
> > > > ...
> > > > >>> 24 3928
> > > > >>> 0.00%
> > > > >>> -
> > org.apache.wicket.util.concurrent.ConcurrentHaspMap$Entry@0xd.
> > > > ...
> > > > >>> 24 3928
> > > > >>> 0.00%
> > > > >>> -
> > org.apache.wicket.util.concurrent.ConcurrentHaspMap$Entry@0xd.
> > > > ...
> > > > >>> 24 3928
> > > > >>> 0.00%
> > > > >>> -
> > org.apache.wicket.util.concurrent.ConcurrentHaspMap$Entry@0xd.
> > > > ...
> > > > >>> 24 3928
> > > > >>> 0.00%
> > > > >>> + 2,863,659 more...
> > > > >>>
> > > > >>> Is that means that the Localizer Object used most of the heap
> size?
> > > > >>> or Is this number normal for Wicket App?
> > > > >>>
> > > > >>> I wonder whether I forget to release the memory by my mis-using
> of
> > > > i18n
> > > > >>> feature?
> > > > >>> Is there any attentions I must pay to when dealing with
> Localizer?
> > > > >>>
> > > > >>> This problem annoys me more the 2 weeks. I really need some
> help.
> > > > Thanks
> > > > >>> .
> > > > >>>
> > > > >>
> > > > >>
> > ---------------------------------------------------------------------
> > > > >> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> > > > >> For additional commands, e-mail: users-help@wicket.apache.org
> > > > >>
> > > > >>
> > > > >>
> > > > >
> > > > >
> > > >
> > > > --
> > > > View this message in context:
> > > >
> > >
> >
> http://www.nabble.com/Why-Localizer-Retained-so-many-heapsize--tp17142582p17199950.html
> > > > Sent from the Wicket - User mailing list archive at Nabble.com.
> > > >
> > > >
> > > >
> ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> > > > For additional commands, e-mail: users-help@wicket.apache.org
> > > >
> > > >
> > >
> >
>
Re: Why Localizer Retained so many heapsize?
Posted by Quan Zhou <be...@gmail.com>.
getResourceSettings().setLocalizer(new Localizer() {
@Override
public void putIntoCache(final String cacheKey,final String
string) {
if (string != null && cacheKey!=null)
super.putIntoCache(cacheKey, string);
}
});
2008/5/14 Johan Compagner <jc...@gmail.com>:
> but what did you do there in that method?
> nothing? you dont cache anything anymore?
>
> On Wed, May 14, 2008 at 10:29 AM, Quan Zhou <be...@gmail.com> wrote:
>
> > Hello everyone.
> >
> > I override Localizer.putIntoCache method. and it really reduce the
> > heapsize
> > usage of Localizer.
> >
> > The application is more stable now although the key remains large.
> >
> > Hope we can find a way to shorter the key length.
> >
> > thanks everyone.
> >
> > 2008/5/13 Eirik Rude <ei...@ballangrud.com>:
> >
> > >
> > > A soft reference is very common for this type of thing. I know some of
> > > ICU's
> > > resources are stored this way.
> > >
> > >
> > >
> > > Jonathan Locke wrote:
> > > >
> > > >
> > > > maybe localizer should limit its size or use a soft reference cache?
> > > >
> > > >
> > > > Johan Compagner wrote:
> > > >>
> > > >> Can you really see what it holds?
> > > >> Almost 2G in memory in localizer is extreme... Thats really a lot of
> > > >> strings..
> > > >> You could try to read that dump with yourkit if your current one
> > > >> doesnt show enough.
> > > >>
> > > >> On 5/9/08, Quan Zhou <be...@gmail.com> wrote:
> > > >>> Hello everyone.
> > > >>>
> > > >>> I recently develop my App use Wicket1.3.3. It's my first time to
> use
> > > >>> this
> > > >>> framework and I feel it's really really a perfect framework for me.
> > > >>> My app support both Simplified Chinese , Traditional Chinese, I
> > > >>> implement
> > > >>> this with Wicket i18n feature.
> > > >>> With the load increasing these days, I found my app would become
> > very
> > > >>> lag
> > > >>> abount every 24 hours ,so that i would only restart it
> > > >>> without any choice.
> > > >>> when I found the lag, My log records many Exceptions like :
> > > >>> "after 1 minute the Pagemap null is still locked by:
> > > >>> Thread[http-8080-321,5,main], giving
> > > >>> up trying to get the page for path xxx"
> > > >>>
> > > >>> I check the JVM status with jstat -gc , It tells that the Heapsize
> > is
> > > >>> full
> > > >>> even after full GC.
> > > >>> My VM paraemter is "-Xms2000m -Xmx2000m -XX:MaxNewSize=250m
> > > >>> -XX:MaxPermSize=250m"
> > > >>> My deploy server has 2*CPU and 4G memory, Redhat AS4 OS + tomcat
> > 6.0.
> > > >>> There're 2000 sessions on the day while the timeout threshold is 15
> > > >>> minutes.
> > > >>> So i dump the whole heapsize with the command " jmap
> > > >>> -dump:live,format=b,file=3.dump.hprof processid"
> > > >>> and i truely get a 2G size dump files. I use SAP Memory Analyer to
> > see
> > > >>> what're stored in HeapMemory.
> > > >>> and I found a strange number of Retained Heap usage:
> > > >>> Classname
> > > >>> ShallowHeap
> > RetainHeap
> > > >>> RetainedHeap%
> > > >>> -org.apache.wicket.Localizer@0x78..
> > > >>> 16
> > > >>> 1,755,070,352 87.64%
> > > >>> -org.apache.wicket.util.concurrent.ConcurrentHashMap@0x79...
> > > >>> 48 1,755,070,336
> > 87.69%
> > > >>> -org.apache.wicket.util.concurrent.ConcurrentHaspMap$Entry@0xd.
> ...
> > > >>> 33,554,448
> > > >>> 1,755,069,632 87.69%
> > > >>> -
> org.apache.wicket.util.concurrent.ConcurrentHaspMap$Entry@0xd.
> > > ...
> > > >>> 24 3928
> > > >>> 0.00%
> > > >>> -
> org.apache.wicket.util.concurrent.ConcurrentHaspMap$Entry@0xd.
> > > ...
> > > >>> 24 3928
> > > >>> 0.00%
> > > >>> -
> org.apache.wicket.util.concurrent.ConcurrentHaspMap$Entry@0xd.
> > > ...
> > > >>> 24 3928
> > > >>> 0.00%
> > > >>> -
> org.apache.wicket.util.concurrent.ConcurrentHaspMap$Entry@0xd.
> > > ...
> > > >>> 24 3928
> > > >>> 0.00%
> > > >>> -
> org.apache.wicket.util.concurrent.ConcurrentHaspMap$Entry@0xd.
> > > ...
> > > >>> 24 3928
> > > >>> 0.00%
> > > >>> -
> org.apache.wicket.util.concurrent.ConcurrentHaspMap$Entry@0xd.
> > > ...
> > > >>> 24 3928
> > > >>> 0.00%
> > > >>> + 2,863,659 more...
> > > >>>
> > > >>> Is that means that the Localizer Object used most of the heap size?
> > > >>> or Is this number normal for Wicket App?
> > > >>>
> > > >>> I wonder whether I forget to release the memory by my mis-using of
> > > i18n
> > > >>> feature?
> > > >>> Is there any attentions I must pay to when dealing with Localizer?
> > > >>>
> > > >>> This problem annoys me more the 2 weeks. I really need some help.
> > > Thanks
> > > >>> .
> > > >>>
> > > >>
> > > >>
> ---------------------------------------------------------------------
> > > >> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> > > >> For additional commands, e-mail: users-help@wicket.apache.org
> > > >>
> > > >>
> > > >>
> > > >
> > > >
> > >
> > > --
> > > View this message in context:
> > >
> >
> http://www.nabble.com/Why-Localizer-Retained-so-many-heapsize--tp17142582p17199950.html
> > > Sent from the Wicket - User mailing list archive at Nabble.com.
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> > > For additional commands, e-mail: users-help@wicket.apache.org
> > >
> > >
> >
>
Re: Why Localizer Retained so many heapsize?
Posted by Johan Compagner <jc...@gmail.com>.
but what did you do there in that method?
nothing? you dont cache anything anymore?
On Wed, May 14, 2008 at 10:29 AM, Quan Zhou <be...@gmail.com> wrote:
> Hello everyone.
>
> I override Localizer.putIntoCache method. and it really reduce the
> heapsize
> usage of Localizer.
>
> The application is more stable now although the key remains large.
>
> Hope we can find a way to shorter the key length.
>
> thanks everyone.
>
> 2008/5/13 Eirik Rude <ei...@ballangrud.com>:
>
> >
> > A soft reference is very common for this type of thing. I know some of
> > ICU's
> > resources are stored this way.
> >
> >
> >
> > Jonathan Locke wrote:
> > >
> > >
> > > maybe localizer should limit its size or use a soft reference cache?
> > >
> > >
> > > Johan Compagner wrote:
> > >>
> > >> Can you really see what it holds?
> > >> Almost 2G in memory in localizer is extreme... Thats really a lot of
> > >> strings..
> > >> You could try to read that dump with yourkit if your current one
> > >> doesnt show enough.
> > >>
> > >> On 5/9/08, Quan Zhou <be...@gmail.com> wrote:
> > >>> Hello everyone.
> > >>>
> > >>> I recently develop my App use Wicket1.3.3. It's my first time to use
> > >>> this
> > >>> framework and I feel it's really really a perfect framework for me.
> > >>> My app support both Simplified Chinese , Traditional Chinese, I
> > >>> implement
> > >>> this with Wicket i18n feature.
> > >>> With the load increasing these days, I found my app would become
> very
> > >>> lag
> > >>> abount every 24 hours ,so that i would only restart it
> > >>> without any choice.
> > >>> when I found the lag, My log records many Exceptions like :
> > >>> "after 1 minute the Pagemap null is still locked by:
> > >>> Thread[http-8080-321,5,main], giving
> > >>> up trying to get the page for path xxx"
> > >>>
> > >>> I check the JVM status with jstat -gc , It tells that the Heapsize
> is
> > >>> full
> > >>> even after full GC.
> > >>> My VM paraemter is "-Xms2000m -Xmx2000m -XX:MaxNewSize=250m
> > >>> -XX:MaxPermSize=250m"
> > >>> My deploy server has 2*CPU and 4G memory, Redhat AS4 OS + tomcat
> 6.0.
> > >>> There're 2000 sessions on the day while the timeout threshold is 15
> > >>> minutes.
> > >>> So i dump the whole heapsize with the command " jmap
> > >>> -dump:live,format=b,file=3.dump.hprof processid"
> > >>> and i truely get a 2G size dump files. I use SAP Memory Analyer to
> see
> > >>> what're stored in HeapMemory.
> > >>> and I found a strange number of Retained Heap usage:
> > >>> Classname
> > >>> ShallowHeap
> RetainHeap
> > >>> RetainedHeap%
> > >>> -org.apache.wicket.Localizer@0x78..
> > >>> 16
> > >>> 1,755,070,352 87.64%
> > >>> -org.apache.wicket.util.concurrent.ConcurrentHashMap@0x79...
> > >>> 48 1,755,070,336
> 87.69%
> > >>> -org.apache.wicket.util.concurrent.ConcurrentHaspMap$Entry@0xd....
> > >>> 33,554,448
> > >>> 1,755,069,632 87.69%
> > >>> - org.apache.wicket.util.concurrent.ConcurrentHaspMap$Entry@0xd.
> > ...
> > >>> 24 3928
> > >>> 0.00%
> > >>> - org.apache.wicket.util.concurrent.ConcurrentHaspMap$Entry@0xd.
> > ...
> > >>> 24 3928
> > >>> 0.00%
> > >>> - org.apache.wicket.util.concurrent.ConcurrentHaspMap$Entry@0xd.
> > ...
> > >>> 24 3928
> > >>> 0.00%
> > >>> - org.apache.wicket.util.concurrent.ConcurrentHaspMap$Entry@0xd.
> > ...
> > >>> 24 3928
> > >>> 0.00%
> > >>> - org.apache.wicket.util.concurrent.ConcurrentHaspMap$Entry@0xd.
> > ...
> > >>> 24 3928
> > >>> 0.00%
> > >>> - org.apache.wicket.util.concurrent.ConcurrentHaspMap$Entry@0xd.
> > ...
> > >>> 24 3928
> > >>> 0.00%
> > >>> + 2,863,659 more...
> > >>>
> > >>> Is that means that the Localizer Object used most of the heap size?
> > >>> or Is this number normal for Wicket App?
> > >>>
> > >>> I wonder whether I forget to release the memory by my mis-using of
> > i18n
> > >>> feature?
> > >>> Is there any attentions I must pay to when dealing with Localizer?
> > >>>
> > >>> This problem annoys me more the 2 weeks. I really need some help.
> > Thanks
> > >>> .
> > >>>
> > >>
> > >> ---------------------------------------------------------------------
> > >> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> > >> For additional commands, e-mail: users-help@wicket.apache.org
> > >>
> > >>
> > >>
> > >
> > >
> >
> > --
> > View this message in context:
> >
> http://www.nabble.com/Why-Localizer-Retained-so-many-heapsize--tp17142582p17199950.html
> > Sent from the Wicket - User mailing list archive at Nabble.com.
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> > For additional commands, e-mail: users-help@wicket.apache.org
> >
> >
>
Re: Why Localizer Retained so many heapsize?
Posted by Quan Zhou <be...@gmail.com>.
Hello everyone.
I override Localizer.putIntoCache method. and it really reduce the heapsize
usage of Localizer.
The application is more stable now although the key remains large.
Hope we can find a way to shorter the key length.
thanks everyone.
2008/5/13 Eirik Rude <ei...@ballangrud.com>:
>
> A soft reference is very common for this type of thing. I know some of
> ICU's
> resources are stored this way.
>
>
>
> Jonathan Locke wrote:
> >
> >
> > maybe localizer should limit its size or use a soft reference cache?
> >
> >
> > Johan Compagner wrote:
> >>
> >> Can you really see what it holds?
> >> Almost 2G in memory in localizer is extreme... Thats really a lot of
> >> strings..
> >> You could try to read that dump with yourkit if your current one
> >> doesnt show enough.
> >>
> >> On 5/9/08, Quan Zhou <be...@gmail.com> wrote:
> >>> Hello everyone.
> >>>
> >>> I recently develop my App use Wicket1.3.3. It's my first time to use
> >>> this
> >>> framework and I feel it's really really a perfect framework for me.
> >>> My app support both Simplified Chinese , Traditional Chinese, I
> >>> implement
> >>> this with Wicket i18n feature.
> >>> With the load increasing these days, I found my app would become very
> >>> lag
> >>> abount every 24 hours ,so that i would only restart it
> >>> without any choice.
> >>> when I found the lag, My log records many Exceptions like :
> >>> "after 1 minute the Pagemap null is still locked by:
> >>> Thread[http-8080-321,5,main], giving
> >>> up trying to get the page for path xxx"
> >>>
> >>> I check the JVM status with jstat -gc , It tells that the Heapsize is
> >>> full
> >>> even after full GC.
> >>> My VM paraemter is "-Xms2000m -Xmx2000m -XX:MaxNewSize=250m
> >>> -XX:MaxPermSize=250m"
> >>> My deploy server has 2*CPU and 4G memory, Redhat AS4 OS + tomcat 6.0.
> >>> There're 2000 sessions on the day while the timeout threshold is 15
> >>> minutes.
> >>> So i dump the whole heapsize with the command " jmap
> >>> -dump:live,format=b,file=3.dump.hprof processid"
> >>> and i truely get a 2G size dump files. I use SAP Memory Analyer to see
> >>> what're stored in HeapMemory.
> >>> and I found a strange number of Retained Heap usage:
> >>> Classname
> >>> ShallowHeap RetainHeap
> >>> RetainedHeap%
> >>> -org.apache.wicket.Localizer@0x78..
> >>> 16
> >>> 1,755,070,352 87.64%
> >>> -org.apache.wicket.util.concurrent.ConcurrentHashMap@0x79...
> >>> 48 1,755,070,336 87.69%
> >>> -org.apache.wicket.util.concurrent.ConcurrentHaspMap$Entry@0xd....
> >>> 33,554,448
> >>> 1,755,069,632 87.69%
> >>> - org.apache.wicket.util.concurrent.ConcurrentHaspMap$Entry@0xd.
> ...
> >>> 24 3928
> >>> 0.00%
> >>> - org.apache.wicket.util.concurrent.ConcurrentHaspMap$Entry@0xd.
> ...
> >>> 24 3928
> >>> 0.00%
> >>> - org.apache.wicket.util.concurrent.ConcurrentHaspMap$Entry@0xd.
> ...
> >>> 24 3928
> >>> 0.00%
> >>> - org.apache.wicket.util.concurrent.ConcurrentHaspMap$Entry@0xd.
> ...
> >>> 24 3928
> >>> 0.00%
> >>> - org.apache.wicket.util.concurrent.ConcurrentHaspMap$Entry@0xd.
> ...
> >>> 24 3928
> >>> 0.00%
> >>> - org.apache.wicket.util.concurrent.ConcurrentHaspMap$Entry@0xd.
> ...
> >>> 24 3928
> >>> 0.00%
> >>> + 2,863,659 more...
> >>>
> >>> Is that means that the Localizer Object used most of the heap size?
> >>> or Is this number normal for Wicket App?
> >>>
> >>> I wonder whether I forget to release the memory by my mis-using of
> i18n
> >>> feature?
> >>> Is there any attentions I must pay to when dealing with Localizer?
> >>>
> >>> This problem annoys me more the 2 weeks. I really need some help.
> Thanks
> >>> .
> >>>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> >> For additional commands, e-mail: users-help@wicket.apache.org
> >>
> >>
> >>
> >
> >
>
> --
> View this message in context:
> http://www.nabble.com/Why-Localizer-Retained-so-many-heapsize--tp17142582p17199950.html
> Sent from the Wicket - User mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
Re: Why Localizer Retained so many heapsize?
Posted by Eirik Rude <ei...@ballangrud.com>.
A soft reference is very common for this type of thing. I know some of ICU's
resources are stored this way.
Jonathan Locke wrote:
>
>
> maybe localizer should limit its size or use a soft reference cache?
>
>
> Johan Compagner wrote:
>>
>> Can you really see what it holds?
>> Almost 2G in memory in localizer is extreme... Thats really a lot of
>> strings..
>> You could try to read that dump with yourkit if your current one
>> doesnt show enough.
>>
>> On 5/9/08, Quan Zhou <be...@gmail.com> wrote:
>>> Hello everyone.
>>>
>>> I recently develop my App use Wicket1.3.3. It's my first time to use
>>> this
>>> framework and I feel it's really really a perfect framework for me.
>>> My app support both Simplified Chinese , Traditional Chinese, I
>>> implement
>>> this with Wicket i18n feature.
>>> With the load increasing these days, I found my app would become very
>>> lag
>>> abount every 24 hours ,so that i would only restart it
>>> without any choice.
>>> when I found the lag, My log records many Exceptions like :
>>> "after 1 minute the Pagemap null is still locked by:
>>> Thread[http-8080-321,5,main], giving
>>> up trying to get the page for path xxx"
>>>
>>> I check the JVM status with jstat -gc , It tells that the Heapsize is
>>> full
>>> even after full GC.
>>> My VM paraemter is "-Xms2000m -Xmx2000m -XX:MaxNewSize=250m
>>> -XX:MaxPermSize=250m"
>>> My deploy server has 2*CPU and 4G memory, Redhat AS4 OS + tomcat 6.0.
>>> There're 2000 sessions on the day while the timeout threshold is 15
>>> minutes.
>>> So i dump the whole heapsize with the command " jmap
>>> -dump:live,format=b,file=3.dump.hprof processid"
>>> and i truely get a 2G size dump files. I use SAP Memory Analyer to see
>>> what're stored in HeapMemory.
>>> and I found a strange number of Retained Heap usage:
>>> Classname
>>> ShallowHeap RetainHeap
>>> RetainedHeap%
>>> -org.apache.wicket.Localizer@0x78..
>>> 16
>>> 1,755,070,352 87.64%
>>> -org.apache.wicket.util.concurrent.ConcurrentHashMap@0x79...
>>> 48 1,755,070,336 87.69%
>>> -org.apache.wicket.util.concurrent.ConcurrentHaspMap$Entry@0xd....
>>> 33,554,448
>>> 1,755,069,632 87.69%
>>> - org.apache.wicket.util.concurrent.ConcurrentHaspMap$Entry@0xd....
>>> 24 3928
>>> 0.00%
>>> - org.apache.wicket.util.concurrent.ConcurrentHaspMap$Entry@0xd....
>>> 24 3928
>>> 0.00%
>>> - org.apache.wicket.util.concurrent.ConcurrentHaspMap$Entry@0xd....
>>> 24 3928
>>> 0.00%
>>> - org.apache.wicket.util.concurrent.ConcurrentHaspMap$Entry@0xd....
>>> 24 3928
>>> 0.00%
>>> - org.apache.wicket.util.concurrent.ConcurrentHaspMap$Entry@0xd....
>>> 24 3928
>>> 0.00%
>>> - org.apache.wicket.util.concurrent.ConcurrentHaspMap$Entry@0xd....
>>> 24 3928
>>> 0.00%
>>> + 2,863,659 more...
>>>
>>> Is that means that the Localizer Object used most of the heap size?
>>> or Is this number normal for Wicket App?
>>>
>>> I wonder whether I forget to release the memory by my mis-using of i18n
>>> feature?
>>> Is there any attentions I must pay to when dealing with Localizer?
>>>
>>> This problem annoys me more the 2 weeks. I really need some help. Thanks
>>> .
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
>>
>
>
--
View this message in context: http://www.nabble.com/Why-Localizer-Retained-so-many-heapsize--tp17142582p17199950.html
Sent from the Wicket - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Why Localizer Retained so many heapsize?
Posted by Jonathan Locke <jo...@gmail.com>.
maybe localizer should limit its size or use a soft reference cache?
Johan Compagner wrote:
>
> Can you really see what it holds?
> Almost 2G in memory in localizer is extreme... Thats really a lot of
> strings..
> You could try to read that dump with yourkit if your current one
> doesnt show enough.
>
> On 5/9/08, Quan Zhou <be...@gmail.com> wrote:
>> Hello everyone.
>>
>> I recently develop my App use Wicket1.3.3. It's my first time to use this
>> framework and I feel it's really really a perfect framework for me.
>> My app support both Simplified Chinese , Traditional Chinese, I implement
>> this with Wicket i18n feature.
>> With the load increasing these days, I found my app would become very lag
>> abount every 24 hours ,so that i would only restart it
>> without any choice.
>> when I found the lag, My log records many Exceptions like :
>> "after 1 minute the Pagemap null is still locked by:
>> Thread[http-8080-321,5,main], giving
>> up trying to get the page for path xxx"
>>
>> I check the JVM status with jstat -gc , It tells that the Heapsize is
>> full
>> even after full GC.
>> My VM paraemter is "-Xms2000m -Xmx2000m -XX:MaxNewSize=250m
>> -XX:MaxPermSize=250m"
>> My deploy server has 2*CPU and 4G memory, Redhat AS4 OS + tomcat 6.0.
>> There're 2000 sessions on the day while the timeout threshold is 15
>> minutes.
>> So i dump the whole heapsize with the command " jmap
>> -dump:live,format=b,file=3.dump.hprof processid"
>> and i truely get a 2G size dump files. I use SAP Memory Analyer to see
>> what're stored in HeapMemory.
>> and I found a strange number of Retained Heap usage:
>> Classname
>> ShallowHeap RetainHeap
>> RetainedHeap%
>> -org.apache.wicket.Localizer@0x78..
>> 16
>> 1,755,070,352 87.64%
>> -org.apache.wicket.util.concurrent.ConcurrentHashMap@0x79...
>> 48 1,755,070,336 87.69%
>> -org.apache.wicket.util.concurrent.ConcurrentHaspMap$Entry@0xd....
>> 33,554,448
>> 1,755,069,632 87.69%
>> - org.apache.wicket.util.concurrent.ConcurrentHaspMap$Entry@0xd....
>> 24 3928
>> 0.00%
>> - org.apache.wicket.util.concurrent.ConcurrentHaspMap$Entry@0xd....
>> 24 3928
>> 0.00%
>> - org.apache.wicket.util.concurrent.ConcurrentHaspMap$Entry@0xd....
>> 24 3928
>> 0.00%
>> - org.apache.wicket.util.concurrent.ConcurrentHaspMap$Entry@0xd....
>> 24 3928
>> 0.00%
>> - org.apache.wicket.util.concurrent.ConcurrentHaspMap$Entry@0xd....
>> 24 3928
>> 0.00%
>> - org.apache.wicket.util.concurrent.ConcurrentHaspMap$Entry@0xd....
>> 24 3928
>> 0.00%
>> + 2,863,659 more...
>>
>> Is that means that the Localizer Object used most of the heap size?
>> or Is this number normal for Wicket App?
>>
>> I wonder whether I forget to release the memory by my mis-using of i18n
>> feature?
>> Is there any attentions I must pay to when dealing with Localizer?
>>
>> This problem annoys me more the 2 weeks. I really need some help. Thanks
>> .
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
>
--
View this message in context: http://www.nabble.com/Why-Localizer-Retained-so-many-heapsize--tp17142582p17182082.html
Sent from the Wicket - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Why Localizer Retained so many heapsize?
Posted by Johan Compagner <jc...@gmail.com>.
Can you really see what it holds?
Almost 2G in memory in localizer is extreme... Thats really a lot of strings..
You could try to read that dump with yourkit if your current one
doesnt show enough.
On 5/9/08, Quan Zhou <be...@gmail.com> wrote:
> Hello everyone.
>
> I recently develop my App use Wicket1.3.3. It's my first time to use this
> framework and I feel it's really really a perfect framework for me.
> My app support both Simplified Chinese , Traditional Chinese, I implement
> this with Wicket i18n feature.
> With the load increasing these days, I found my app would become very lag
> abount every 24 hours ,so that i would only restart it
> without any choice.
> when I found the lag, My log records many Exceptions like :
> "after 1 minute the Pagemap null is still locked by:
> Thread[http-8080-321,5,main], giving
> up trying to get the page for path xxx"
>
> I check the JVM status with jstat -gc , It tells that the Heapsize is full
> even after full GC.
> My VM paraemter is "-Xms2000m -Xmx2000m -XX:MaxNewSize=250m
> -XX:MaxPermSize=250m"
> My deploy server has 2*CPU and 4G memory, Redhat AS4 OS + tomcat 6.0.
> There're 2000 sessions on the day while the timeout threshold is 15 minutes.
> So i dump the whole heapsize with the command " jmap
> -dump:live,format=b,file=3.dump.hprof processid"
> and i truely get a 2G size dump files. I use SAP Memory Analyer to see
> what're stored in HeapMemory.
> and I found a strange number of Retained Heap usage:
> Classname
> ShallowHeap RetainHeap
> RetainedHeap%
> -org.apache.wicket.Localizer@0x78..
> 16
> 1,755,070,352 87.64%
> -org.apache.wicket.util.concurrent.ConcurrentHashMap@0x79...
> 48 1,755,070,336 87.69%
> -org.apache.wicket.util.concurrent.ConcurrentHaspMap$Entry@0xd....
> 33,554,448
> 1,755,069,632 87.69%
> - org.apache.wicket.util.concurrent.ConcurrentHaspMap$Entry@0xd....
> 24 3928
> 0.00%
> - org.apache.wicket.util.concurrent.ConcurrentHaspMap$Entry@0xd....
> 24 3928
> 0.00%
> - org.apache.wicket.util.concurrent.ConcurrentHaspMap$Entry@0xd....
> 24 3928
> 0.00%
> - org.apache.wicket.util.concurrent.ConcurrentHaspMap$Entry@0xd....
> 24 3928
> 0.00%
> - org.apache.wicket.util.concurrent.ConcurrentHaspMap$Entry@0xd....
> 24 3928
> 0.00%
> - org.apache.wicket.util.concurrent.ConcurrentHaspMap$Entry@0xd....
> 24 3928
> 0.00%
> + 2,863,659 more...
>
> Is that means that the Localizer Object used most of the heap size?
> or Is this number normal for Wicket App?
>
> I wonder whether I forget to release the memory by my mis-using of i18n
> feature?
> Is there any attentions I must pay to when dealing with Localizer?
>
> This problem annoys me more the 2 weeks. I really need some help. Thanks .
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org