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.
