3:25 a.m.
Just saw this: https://github.com/wolfc/jboss-libra
We should investigate the possibility of adding this to Infinispan and provide memory size
based eviction, WDYT?
The performance impact would need to be measured too.
EhCache has apparenlty done something similar but from what I heard, it's full of
hacks to work on diff plattforms...
Cheers,
--
Galder Zamarreño
Sr. Software Engineer
Infinispan, JBoss Cache
3:34 a.m.
IMO, measuring object size using java.lang.instrument is not a good
idea: first of all, it's probably very slow and the time to do so is
linear to the number of live objects. Second, this probably takes into
acount only objects in the cache, but not the cache structures used by
Infinispan, JGroups and so on...
The approach I've recommended before is to trigger an eviction policy
based on free/available memory. This can easily be fetched from the JVM
via JMX...
On 1/31/12 10:25 AM, Galder Zamarreño wrote:
Just saw this: https://github.com/wolfc/jboss-libra
We should investigate the possibility of adding this to Infinispan and provide memory
size based eviction, WDYT?
The performance impact would need to be measured too.
EhCache has apparenlty done something similar but from what I heard, it's full of
hacks to work on diff plattforms...
--
Bela Ban
Lead JGroups (http://www.jgroups.org)
JBoss / Red Hat
8:32 a.m.
On 1/31/12 11:32 AM, Tristan Tarrant wrote:
On 01/31/2012 10:34 AM, Bela Ban wrote:
> The approach I've recommended before is to trigger an eviction policy
> based on free/available memory. This can easily be fetched from the JVM
> via JMX...
And maybe you're just close to a large GC and you're evicting for no reason.
IIRC you can look at the size of the young and old generation via JMX,
and there you can see how much memory has accumulated.
--
Bela Ban
Lead JGroups (http://www.jgroups.org)
JBoss / Red Hat
8:49 a.m.
I don't know, but I don't see why not.
If you look at java.lang.{Memory,GarbageCollector,MemoryPool}, there are
a lot of values you can look at, including the details on eden and old.
You can even register for notifications when free memory drops below a
certain threshold, but I've never tried this out and I heard some impls
don't provide this...
On 1/31/12 3:32 PM, Tristan Tarrant wrote:
On 01/31/2012 03:32 PM, Bela Ban wrote:
> IIRC you can look at the size of the young and old generation via JMX,
> and there you can see how much memory has accumulated.
Does that work when using G1 ?
Tristan
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
--
Bela Ban
Lead JGroups (http://www.jgroups.org)
JBoss / Red Hat
2:51 p.m.
On Tue, Jan 31, 2012 at 4:49 PM, Bela Ban <bban(a)redhat.com> wrote:
I don't know, but I don't see why not.
If you look at java.lang.{Memory,GarbageCollector,MemoryPool}, there are
a lot of values you can look at, including the details on eden and old.
I just looked at G1 with JConsole, it does provide memory usage
information in (java.lang:type=MemoryPool, name={G1 Young Gen, G1
Survivor, G1 Old Gen}).Usage. However, the locations are not standard,
so we'd have to keep a bunch of rules about where to look for each
garbage collector.
Plus I'm not sure what looking at each generation separately would buy
us over looking only at Runtime.freeMemory().
You can even register for notifications when free memory drops below
a
certain threshold, but I've never tried this out and I heard some impls
don't provide this...
The biggest problem I think with looking at the amount of used/free
memory is used memory includes dead objects. So you'll get a free
memory threshold notification and start evicting entries, but you
won't know how much memory you've freed (or even if you needed to
evict any entries in the first place) without triggering an extremely
expensive full GC.
I second Mircea's idea of using the serialized data size, that's the
only reliable data we've got.
Cheers
Dan
On 1/31/12 3:32 PM, Tristan Tarrant wrote:
> On 01/31/2012 03:32 PM, Bela Ban wrote:
>> IIRC you can look at the size of the young and old generation via JMX,
>> and there you can see how much memory has accumulated.
> Does that work when using G1 ?
>
> Tristan
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
--
Bela Ban
Lead JGroups (http://www.jgroups.org)
JBoss / Red Hat
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
11:14 a.m.
New idea: what about implementing a memory-size based eviction policy
which only works on values of type byte[] ?
The limitation might be strong, but actually applies quite well to
some use cases:
- Hot Rod
- Lucene
I think this could serve well more use cases, and specifically for
Lucene it would rock, as besides from some small metadata, the bulk of
stuff is big arrays of bytes.
-- Sanne
8:57 a.m.
This is very similar to storeAsBinary. If this is set to true, then keys and values are
serialized and stored as a MarshalledValue which contains the resulting byte[]. So rather
than restrict to just byte[] types, we could restrict to:
* byte[] or any other primitive, primitive array or String
* OR, if storeAsBinary is set to true.
The tricky part will be to get this to work with Vladimir's LIRS container which works
on number of entries. :) Vladimir?
Cheers
Manik
On 3 Feb 2012, at 18:14, Sanne Grinovero wrote:
New idea: what about implementing a memory-size based eviction
policy
which only works on values of type byte[] ?
The limitation might be strong, but actually applies quite well to
some use cases:
- Hot Rod
- Lucene
I think this could serve well more use cases, and specifically for
Lucene it would rock, as besides from some small metadata, the bulk of
stuff is big arrays of bytes.
-- Sanne
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
--
Manik Surtani
manik(a)jboss.org
twitter.com/maniksurtani
Lead, Infinispan
http://www.infinispan.org
4:08 p.m.
On 4 February 2012 14:57, Manik Surtani <manik(a)jboss.org> wrote:
This is very similar to storeAsBinary. If this is set to true, then
keys and values are serialized and stored as a MarshalledValue which contains the
resulting byte[]. So rather than restrict to just byte[] types, we could restrict to:
* byte[] or any other primitive, primitive array or String
* OR, if storeAsBinary is set to true.
+1, the family of known sizes can be extended. We could even do a
recursive calculation and ask the registered Externalizer for the
specific type; it's unlikely we can have this information returned by
all externalizers but many could be able to handle a fairly accurate
estimate.
Precision is more important when allocating buffers for network & co,
so if we enrich the Externalizer API to provide such information it
would be handy to know as well if it's going to be an estimate or a
precise size of serialized form, considering as well that serialized
size isn't necessarily going to match the runtime memory cost.
The tricky part will be to get this to work with Vladimir's LIRS container which
works on number of entries. :) Vladimir?
Cheers
Manik
On 3 Feb 2012, at 18:14, Sanne Grinovero wrote:
> New idea: what about implementing a memory-size based eviction policy
> which only works on values of type byte[] ?
>
> The limitation might be strong, but actually applies quite well to
> some use cases:
> - Hot Rod
> - Lucene
>
> I think this could serve well more use cases, and specifically for
> Lucene it would rock, as besides from some small metadata, the bulk of
> stuff is big arrays of bytes.
>
> -- Sanne
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
--
Manik Surtani
manik(a)jboss.org
twitter.com/maniksurtani
Lead, Infinispan
http://www.infinispan.org
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
8:44 a.m.
----- Original Message -----
From: "Sanne Grinovero" <sanne(a)infinispan.org>
To: "infinispan -Dev List" <infinispan-dev(a)lists.jboss.org>
Sent: Saturday, February 4, 2012 10:08:16 PM
Subject: Re: [infinispan-dev] JBoss Libra
On 4 February 2012 14:57, Manik Surtani <manik(a)jboss.org> wrote:
> This is very similar to storeAsBinary. If this is set to true,
> then keys and values are serialized and stored as a
> MarshalledValue which contains the resulting byte[]. So rather
> than restrict to just byte[] types, we could restrict to:
>
> * byte[] or any other primitive, primitive array or String
> * OR, if storeAsBinary is set to true.
+1, the family of known sizes can be extended. We could even do a
recursive calculation and ask the registered Externalizer for the
specific type; it's unlikely we can have this information returned by
all externalizers but many could be able to handle a fairly accurate
estimate.
I'm not sure I get the "family of known sizes" bit. If you
have storeAsBinary set to true you know exactly the size the size that given object has in
memory. Or are you refering at the situation whre storeAsBinary is set to false?
8:56 a.m.
On 6 February 2012 14:44, Mircea Markus <mmarkus(a)redhat.com> wrote:
----- Original Message -----
> From: "Sanne Grinovero" <sanne(a)infinispan.org>
> To: "infinispan -Dev List" <infinispan-dev(a)lists.jboss.org>
> Sent: Saturday, February 4, 2012 10:08:16 PM
> Subject: Re: [infinispan-dev] JBoss Libra
>
> On 4 February 2012 14:57, Manik Surtani <manik(a)jboss.org> wrote:
> > This is very similar to storeAsBinary. If this is set to true,
> > then keys and values are serialized and stored as a
> > MarshalledValue which contains the resulting byte[]. So rather
> > than restrict to just byte[] types, we could restrict to:
> >
> > * byte[] or any other primitive, primitive array or String
> > * OR, if storeAsBinary is set to true.
>
> +1, the family of known sizes can be extended. We could even do a
> recursive calculation and ask the registered Externalizer for the
> specific type; it's unlikely we can have this information returned by
> all externalizers but many could be able to handle a fairly accurate
> estimate.
I'm not sure I get the "family of known sizes" bit. If you have
storeAsBinary set to true you know exactly the size the size that given object has in
memory. Or are you refering at the situation whre storeAsBinary is set to false?
Yes, with storeAsBinary=false. I didn't think about the details, just
suggesting that there are many more cases in which the size can be
well known even if it's not a byte[].
For example, the Externalizer interface could provide this information
in many cases. Maybe we could even use JBoss Libra at build time to
"weight" all internal and some other common types and fold this
information in the provided externalizers, so to take advantage of its
capabilities but not require the annotation processor to be used by
Infinispan users.
--Sanne
12:16 p.m.
----- Original Message -----
From: "Sanne Grinovero" <sanne(a)infinispan.org>
To: "infinispan -Dev List" <infinispan-dev(a)lists.jboss.org>
Sent: Monday, February 6, 2012 2:56:58 PM
Subject: Re: [infinispan-dev] JBoss Libra
On 6 February 2012 14:44, Mircea Markus <mmarkus(a)redhat.com> wrote:
>
>
> ----- Original Message -----
>> From: "Sanne Grinovero" <sanne(a)infinispan.org>
>> To: "infinispan -Dev List" <infinispan-dev(a)lists.jboss.org>
>> Sent: Saturday, February 4, 2012 10:08:16 PM
>> Subject: Re: [infinispan-dev] JBoss Libra
>>
>> On 4 February 2012 14:57, Manik Surtani <manik(a)jboss.org> wrote:
>> > This is very similar to storeAsBinary. If this is set to true,
>> > then keys and values are serialized and stored as a
>> > MarshalledValue which contains the resulting byte[]. So rather
>> > than restrict to just byte[] types, we could restrict to:
>> >
>> > * byte[] or any other primitive, primitive array or String
>> > * OR, if storeAsBinary is set to true.
>>
>> +1, the family of known sizes can be extended. We could even do a
>> recursive calculation and ask the registered Externalizer for the
>> specific type; it's unlikely we can have this information returned
>> by
>> all externalizers but many could be able to handle a fairly
>> accurate
>> estimate.
> I'm not sure I get the "family of known sizes" bit. If you have
> storeAsBinary set to true you know exactly the size the size that
> given object has in memory. Or are you refering at the situation
> whre storeAsBinary is set to false?
Yes, with storeAsBinary=false. I didn't think about the details, just
suggesting that there are many more cases in which the size can be
well known even if it's not a byte[].
For example, the Externalizer interface could provide this
information
in many cases. Maybe we could even use JBoss Libra at build time to
"weight" all internal and some other common types and fold this
information in the provided externalizers, so to take advantage of
its
capabilities but not require the annotation processor to be used by
Infinispan users.
this would work indeed at the cost of some effort from user's
side to extend and manintain the externilizers. Might cause some issues though: if the
users don't get the externalizer.size() right the memory estimate can go very wrong.
Geting the in-memory size for an object is not an simple thing to do, as per the
memory-usage presentation sent by Manik last week. On top of that an object added to the
cache might be refered by another object added to the cache, so the user must be aware of
that. IMO this approach is tricky from a support perspective.
7:59 a.m.
On 12-02-04 11:57 AM, Manik Surtani wrote:
This is very similar to storeAsBinary. If this is set to true, then
keys and values are serialized and stored as a MarshalledValue which contains the
resulting byte[]. So rather than restrict to just byte[] types, we could restrict to:
* byte[] or any other primitive, primitive array or String
* OR, if storeAsBinary is set to true.
The tricky part will be to get this to work with Vladimir's LIRS container which
works on number of entries. :) Vladimir?
We have to somehow translate eviction that works on number of entries
into eviction that works with memory size where size of each entry is
known only at runtime ! Not impossible but definitely a hard problem!
Vladimir
12:02 p.m.
On 6 Feb 2012, at 13:59, Vladimir Blagojevic wrote:
On 12-02-04 11:57 AM, Manik Surtani wrote:
> This is very similar to storeAsBinary. If this is set to true, then keys and values
are serialized and stored as a MarshalledValue which contains the resulting byte[]. So
rather than restrict to just byte[] types, we could restrict to:
>
> * byte[] or any other primitive, primitive array or String
> * OR, if storeAsBinary is set to true.
>
> The tricky part will be to get this to work with Vladimir's LIRS container which
works on number of entries. :) Vladimir?
>
We have to somehow translate eviction that works on number of entries into eviction that
works with memory size where size of each entry is known only at runtime ! Not impossible
but definitely a hard problem!
Well, this is the thing. For the container to not start evicting when a number of entries
limit is reached, but instead when a different metric is used and in this case that metric
is a size threshold.
By the way, Pete has agreed to look at this for 5.2.0 so expect to hear from him on this.
:)
--
Manik Surtani
manik(a)jboss.org
twitter.com/maniksurtani
Lead, Infinispan
http://www.infinispan.org
8:38 a.m.
This is very similar to storeAsBinary. If this is set to true, then
keys and values are serialized and stored as a MarshalledValue which
contains the resulting byte[]. So rather than restrict to just
byte[] types, we could restrict to:
* byte[] or any other primitive, primitive array or String
* OR, if storeAsBinary is set to true.
+1.
5:06 a.m.
On 31 Jan 2012, at 09:34, Bela Ban wrote:
IMO, measuring object size using java.lang.instrument is not a good
idea: first of all, it's probably very slow and the time to do so is
linear to the number of live objects.
+1
I remember prototyping this for JBossCache and the harness and that's what I found as
well.
Second, this probably takes into
acount only objects in the cache, but not the cache structures used by
Infinispan, JGroups and so on...
The approach I've recommended before is to trigger an eviction policy
based on free/available memory. This can easily be fetched from the JVM
via JMX...
..or keep the in-memory data in serialized form (byte[]) - that can be
counted - and add an empiric factor (TBD) for the harness/ISPN structure that holds the
data. AFAIK coherence does this.
5:09 a.m.
On 31 Jan 2012, at 11:06, Mircea Markus wrote:
..or keep the in-memory data in serialized form (byte[]) - that can
be counted - and add an empiric factor (TBD) for the harness/ISPN structure that holds
the data. AFAIK coherence does this.
I believe this is our beset bet. We already recommend storing serialised forms when using
DIST so thats easy.
--
Manik Surtani
manik(a)jboss.org
twitter.com/maniksurtani
Lead, Infinispan
http://www.infinispan.org
5:26 a.m.
MarshalledValue is already caching the "size when serialized" to
properly dimension output buffers. This value can be reused..
On 31 January 2012 11:09, Manik Surtani <manik(a)jboss.org> wrote:
On 31 Jan 2012, at 11:06, Mircea Markus wrote:
..or keep the in-memory data in serialized form (byte[]) - that can be
counted - and add an empiric factor (TBD) for the harness/ISPN structure
that holds the data. AFAIK coherence does this.
I believe this is our beset bet. We already recommend storing serialised
forms when using DIST so thats easy.
--
Manik Surtani
manik(a)jboss.org
twitter.com/maniksurtani
Lead, Infinispan
http://www.infinispan.org
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
4474
days inactive
4480
days old
infinispan-dev@lists.jboss.org
19 comments
10 participants
participants (10)
-
Bela Ban -
Dan Berindei -
Galder Zamarreño -
Manik Surtani -
Mircea Markus -
Mircea Markus -
Sanne Grinovero -
Thomas Fromm -
Tristan Tarrant -
Vladimir Blagojevic