+1, Queries over historic should be limited.
Adding to Edin and Darrel's comment. Maxing out the heap to32G is good.
When sizing we always allow about 2-4G of memory to the OS.
In your case the system only has 36G, which almost makes this a great
candidate. But what many people forget is that JVM max heap is not the
max memory that the Java process will use.
total memory used = maximum heap + thread stacks + direct memory + perm
gen + share libraries
So in an environment with many threads, high perm gen, you would find
that you are close to the limit of the machine's capacity.
Maybe 30G is a good option. Then at least it has some allowance for the
extra memory demands.
As for queries... I'd say add another 32G on top of the current memory. ;)
Unless querying has changed, queries over partitioned regions would have
a single node that collects all results, before passing them back to the
client. So a query that runs across all nodes can potentially destroy a
single node whilst collecting, serializing and sending data.
I would still use the "quick and dirty" guideline of 30% heap (in < 32G
jvm) for processing and queries.
--Udo
On 30/06/15 03:35, Michael Stolz wrote:
How are you limiting the OQL queries to only some-times go to disk?
Unless you are putting disk based data into separate regions from the
memory based regions ALL queries have the potential to go to disk
unless you have very carefully crafted queries that only hit indices.
I always question situations where people want to put more data into
an In Memory Data Grid than they are willing to spend on memory. Those
use-cases are usually better off with a disk based databases because
the disk paging management of a disk based database is probably
optimized better than Geode is when it comes to querying against disk
based data.
--
Mike Stolz
Principal Technical Account Manager
Mobile: 631-835-4771
On Fri, Jun 26, 2015 at 9:24 PM, Real Wes Williams
<[email protected] <mailto:[email protected]>> wrote:
I’d like to verify best practices for setting eviction threshold
settings. There’s not much written on it. I’m following guidelines at:
https://pubs.vmware.com/vfabric5/index.jsp?topic=/com.vmware.vfabric.gemfire.6.6/managing/heap_use/controlling_heap_use.html
and hoping that they are still current.
I have about 750GB of data, 1/2 historical on disk and 1/2 active
in memory in a cluster of servers with 36GB RAM and 28GB heaps
(20% overhead). The read/write ratio is about 60%/40% and lots of
OQL queries, which need memory space to run. A small percentage of
the queries will hit disk. I'm thinking that I want to give Java
50% overhead. Based on the above, here is what I am thinking:
20% overhead between RAM limit and heap (36GB RAM with 28GB heap)
- why? Java needs memory for its own use outside the heap.
-compressedOops -why? Heap is < 32GB and this gives me more
space. Space is more valuable than speed in this instance.
--eviction-heap-percentage=50 - why? I want to start
evicting around 14GB, which gives the JVM 50% headroom. I found
that when I raised this to 70% I was getting OOM exceptions with
several OQL queries. I'm thinking of lowering this even to 40.
Tradeoffs?
-CMSInitiatingOccupancyFraction=40 - why? I want the GC to be
working when eviction starts. This is from point 3 in the above
link under "Set the JVM's GC Tuning Parameters
"
--critical-heap-percentage=90
Would you determine the above a general best-practice approach?
*Wes Williams | Sr. **Data Engineer*
781.606.0325 <tel:781.606.0325>
http://pivotal.io/big-data/pivotal-gemfire
