|
|
|
|
|
|
|
|
|
This section covers topics related to memory use in your GemFire installation.
Memory Overhead Introduced by the Cache API
For each entry added to a region, the GemFire Enterprise cache API consumes a certain amount of Java memory to store and manage the data. This overhead is required even when an entry is overflowed or persisted to disk.
The Java cache overhead introduced by a region, using a 32-bit VM, can be approximated as listed below. Actual memory use varies based on a number of factors, including the JVM you are using and the platform you are running on. For 64-bit VMs, the usage will usually be larger than with 32-bit VMs. As much as 80% more memory may be required for 64-bit VMs.
■ Add 87 bytes of overhead for each region entry. This value may vary because memory consumption for object headers and object references varies for 64-bit VMs, different VM implementations, and different JDK versions.
■ For each optional user attribute, add 52 bytes of VM memory per entry (plus the space used by the user attribute object).
■ For global regions, a distributed lock token may be needed for each entry. Each token uses 90 bytes of VM memory.
■ For indexes used in querying, the overhead varies greatly depending on the type of data you are storing and the type of index you create. You can roughly estimate the overhead for some types of indexes as follows:
□ If the index has a single value per region entry for the indexedExpression, then the index introduces at most 243 bytes per region entry. An example of this type of index is: fromClause="/portfolios", indexedExpression="id"
The maximum of 243 bytes per region entry assumes that each entry has a unique value for the indexed expression. The overhead is reduced if the entries do not have unique index values.
□ If each region entry has more than one value for indexedExpression, but no two region entries have the same value for the indexedExpression, then the index introduces at most 236C + 75 bytes per region entry, where C is the average number of values per region entry for the indexedExpression. For suggestions on handling the trade-offs between memory overhead and system performance, see Garbage Collection.
Calculating the Size of Your Data
Objects in GemFire Enterprise are serialized for storage into partitioned regions and for all distribution activities, including overflow and persistence to disk. For optimum performance, GemFire tries to reduce the number of times an object is serialized and deserialized. Because of this, your objects may be stored in serialized form or non-serialized form in the cache. To do capacity planning for your data, therefore, use the larger of the serialized and deserialized sizes. If your objects classes are DataSerializable, the non-serialized form will generally be the larger of the two. For information on data serialization, see Data Serialization in the GemFire Enterprise Developer’s Guide.
Overhead of Application Objects
This section describes the overhead of your application objects in the cache. These are the estimated values for 32-bit VMs and 64-bit VMs. Sizes may vary slightly between JVMs and platforms.
■ Object header—12 bytes on 32-bit VMs. (The object header is actually only 8 bytes, but an extra 4 bytes padding is added if the total object size is not a multiple of 8, as is true roughly half the time.) 20 bytes for each object header on 64-bit VMs. Make sure to count the key as well as the value, and to count every object if the key and/or value is a composite object.
■ Field—On 32-bit VMs, 8 bytes for fields of type double or long, 4 bytes per field for all others. On 64-bit VMs, the size is the same as for 32-bit except for fields that are references to objects, which take 8 bytes.