Welcome to the new Gigaspaces XAP forum. To recover your account, please follow these instructions.

Ask Your Question
0

Memory footprint

Hi

Is there anyway we could get an explanation about how gigaspaces consume memory for our space entries. I know we can measure it easily by running against a single partition but I want to understand to explain to customers how much space the index takes etc.

Also if there are any know how about how the new -XX:CompressedOops option for 64 bits vm will affect the memory footprint and if it is or will be stable soon?

Cheers Magnus

{quote}This thread was imported from the previous forum. For your reference, the original is [available here|http://forum.openspaces.org/thread.jspa?threadID=3497]{quote}

asked 2010-09-08 10:26:02 -0500

magpor gravatar image

updated 2013-08-08 09:52:00 -0500

jaissefsfex gravatar image
edit retag flag offensive close merge delete

2 Answers

Sort by » oldest newest most voted
0

Dear Magnus,

The info you are looking for can be found here:
http://www.gigaspaces.com/wiki/display/SBP/CapacityPlanning

Many customers reporting about 30-40% drop with the memory utilization when using -XX:CompressedOops. It seems to be more stable with the latest 1.6 JVM, but not 100% solid. You should test your application and see.

Shay

answered 2010-09-09 00:27:01 -0500

shay hassidim gravatar image
edit flag offensive delete link more

Comments

Hi Shay

Yes I have seen this but it is based on pushing X object into a partition and calculate the size from that. But I want to know how to calculated it exactly to be able to answer customers when they ask. I mean you know you add like 60 bytes for a etc. so why can't we have a table saying " an extended I dex on a integer takes this much memory" ?

Cheers

Magnus

magpor gravatar imagemagpor ( 2010-09-09 13:18:16 -0500 )edit

The amount of memory consumed depends on the following: - Basic object size. Accumulation of all the object fields (serialized form size). - JVM type – 32 bit will consume less memory than 64 bit JVM. - Compressed Oops mode usage – See example added to: http://www.gigaspaces.com/wiki/displa... illustrating the difference. - Amount of indexes used. - Amount of different values an indexed field has – The more you have, the Index footprint for an indexed field will grow. - Space Object ID size. - GigaSpaces meta data – ~150 bytes.

In addition – you should also take into consideration replication overhead. This depends with the replication type (sync or async) , replicate-org-state mode and mirror usage. When using async replication (or Mirror) , if you have large replication batch size and low replication frequency the redo-log size will also have impact on the footprint.

An extended index will have an additional footprint (20%) compared to a basic index type.

Shay

shay hassidim gravatar imageshay hassidim ( 2010-09-11 23:32:57 -0500 )edit
0

Dear Magnus,

The info you are looking for can be found here: http://www.gigaspaces.com/wiki/displa...

Many customers reporting about 30-40% drop with the memory utilization when using -XX:CompressedOops. It seems to be more stable with the latest 1.6 JVM, but not 100% solid. You should test your application and see.

Shay

answered 2010-09-09 00:25:06 -0500

shay hassidim gravatar image
edit flag offensive delete link more

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Add Answer

Question Tools

1 follower

Stats

Asked: 2010-09-08 10:26:02 -0500

Seen: 74 times

Last updated: Sep 09 '10