The Query.execute(RegionFunctionContext context) API can be used to eliminate the PR query coordinating node issue. That API will force the query to be only on the local data and make the coordinating node the client.
Barry Oglesby GemFire Advanced Customer Engineering (ACE) For immediate support please contact Pivotal Support at http://support.pivotal.io/ On Mon, Jun 29, 2015 at 3:29 PM, Udo Kohlmeyer <[email protected]> wrote: > +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] > > 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 >> > > >
