+1 for maxing out the heap size up to (almost) 32g. In my experience it has to be set to a value below 32g, so any value slightly below 32g will ensure that compressed oops are used. The only reason to use a smaller heap size would be if the latency requirements are very low such that GC pauses have to be kept extremely short.
On Jun 29, 2015, at 9:42 AM, Darrel Schneider <[email protected]> wrote: > I think 32g is a good max heap goal to have since it allows compressed oops > (the jvm now just defaults to compressed oops if the heap is <=32g). > > Be aware that in 1.8 you can now have compressed oops with heaps <= 64g. > > The larger the heap the longer the possible gc pause. > > Also according to the following if your heap is < 26g then compressed oops > have less of a performance impact: > Zero-Based Compressed Ordinary Object Pointers (oops) > When using compressed oops in a 64-bit Java Virtual Machine process, the JVM > software asks the operating system to reserve memory for the Java heap > starting at virtual address zero. If the operating system supports such a > request and can reserve memory for the Java heap at virtual address zero, > then zero-based compressed oops are used. > Use of zero-based compressed oops means that a 64-bit pointer can be decoded > from a 32-bit object offset without adding in the Java heap base address. For > heap sizes less than 4 gigabytes, the JVM software can use a byte offset > instead of an object offset and thus also avoid scaling the offset by 8. > Encoding a 64-bit address into a 32-bit offset is correspondingly efficient. > For Java heap sizes up around 26 gigabytes, any of Solaris, Linux, and > Windows operating systems will typically be able to allocate the Java heap at > virtual address zero. > > This quote came from: > http://docs.oracle.com/javase/7/docs/technotes/guides/vm/performance-enhancements-7.html > > On Fri, Jun 26, 2015 at 6:24 PM, Real Wes Williams <[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 > http://pivotal.io/big-data/pivotal-gemfire >
