A couple of notes: 1. There are many JVM implementations (Oracle HotSpot, OpenJDK, Zing, J9, ...) and many collectors to choose from (G1, CMS, C4, ParallelGC, Balanced, GenCon, ...) and the answers may vary between them. The choice of JVM and collector is often driven by the application need, not the other way around.
2. The implications of breaking an application into lots of small JVMs can vary dramatically. For some systems (e.g. completely stateless execution with no benefit from in-process retained or cached information and no accumulation of in-process data) spreading work across JVMs can be architecturally easy. For some systems (e.g. data and execution can both be effectively sharded along dimensions that allow scalable distributed execution with no [significant] growth in state or work), good architecture can allow arbitrary lateral scaling across processes (e.g. Cassandra, Solr/Elastic, Kafka can be good examples of this design concept on JVMs). For some systems (e.g. systems where execution efficiency and speed depend on locally accumulated in-process state, such as caches, in-memory DBs, etc.) scaling across processes can be done well as long as each process can effectively hold all or much of the required state in-process (leading to minimal practical process sizes, and potentially lots of replicated memory for scaling). And for some systems, scaling across an arbitrary number of processes is not practical [and a limited number is used, primarily for redundancy purposes]. Which of these groupings your system falls in will strongly affect the "right" answer in your case. As a general statement, the size at which you *cap* your heap size on JVMs that use collectors that increase their pause sizes with heap size (HotSpot's ParallelGC, CMS, G1 all fall into that category, but E.g. Zing's C4 does not) will be primarily driven by your response time requirements. The answers (to your question) will depend on what your application is doing, on what it's expected/required response time behavior is, and on what collectors (and JVMs) you are able to apply. E.g. if your application is doing batch gene sequencing analysis, you are concerned purely with sequencing throughput measured over a day, and freezing for 20 minutes several times over the period of the run is fine as long as it keeps going after, then you can happily run 2TB heaps on both CMS and G1 with HotSpot. On the other hard, if you want to keep your actual 99.9%'ile response times during the peak 10 minutes of your day below 2msec, you may find it hard to do with *any* HotSpot collector, with any heap size larger than about 50MB. If you live in the wide range of response time behavior needs between those two "extremes", and e.g. you want to keep your 99.9%'ile at peak below a much more lax number (e.g. 200msec), you may find some heap sizes that would work for that with HotSpot and CMS or G1, while larger or smaller ones won't. With C4, you can generally keep your percentiles happy anywhere in the 1GB...2TB range (since JVM pauses do not grow or shrink with heap size), and I can't speak much from experience for the IBM collectors. We certainly see people commonly using multi-GB JVMs to run JVM-based infrastructure pieces (Cassandra, Kafka, Solr, Elastic, Cache engines, servlet containers, etc.). When inherent multi-100s-of-msec pauses are acceptable and 99.9%'iles of 200msec+ are ok, we see people using 2-8GB heap sizes quite often and living with the consequences on HotSpot. And when people want to avoid those sorts of glitches, stalls or circuit-breaker-triggers, we'll see them either opting for Zing (which will both eliminate the glitches and take the cap off of the heap size they can use if they wish), or spending a few man years rewriting parts of their application to better live around HotSpot collector limitations and reduce the occurrences or magnitude of glitches. On Sunday, November 27, 2016 at 5:04:47 AM UTC-8, yahim stnsc wrote: > > Hi all, > > Does anyone have any dimensioning rules for the maximum heap size that > can be managed by CMS/G1 wiith a certain FullGC time? > > My application works with relatively small objects. > > I keep hearing people of running multiple JVMs on same computer with 2 GB > of heap or 8GB of heap but cannot find any clear data. > > Regards > -- You received this message because you are subscribed to the Google Groups "mechanical-sympathy" group. To unsubscribe from this group and stop receiving emails from it, send an email to mechanical-sympathy+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.