Finding happiness is unfortunately never quite that simple. 1. Understand why the garbage collector cannot function with shorter pauses. (may require GC logging configuration to provide key details) 2. Identify priorities. (ie. absolute minimal GC pauses for best latency performance, or maximum throughput, or minimal hardware footprint/cost...) 3. Choose a remediation solution based on stated priorities. (ie. any combination of increase RAM, or possibly ironically CPU or network capacity, decrease query workload, tune GC parameters, ...) 4. Implement the solution with appropriate changes to hardware, code, configuration, and command line options, etc.
Ignite tends to use Java heap mostly for handling query workload. The slower these queries are, the greater number of them will be running concurrently. Java heap needs to accommodate the sum of all running queries' memory footprints, so the first remediation option on the list should include making the slowest queries faster or less memory-hungry. Alternatively, these queries could receive more server resources to spread the load thinner, putatively by adding more nodes to the cluster. This will divide the query load up, and also provide additional resources at the same time. Node resource levels may also be upgraded to help the queries complete faster if analysis reveals they are CPU bound or memory bound. Only when we know the workload and resource level are properly matched should we experiment with GC tuning options. On Thu, May 9, 2024 at 1:31 AM Charlin S <charli...@hotelhub.com> wrote: > Hi All, > > I am getting Possible too long JVM pause: 6403 milliseconds. JVM options > used as below > -XX:+DisableExplicitGC,-XX:+UseG1GC,-Xms3g,-Xmx5g - client node 1 > -XX:+DisableExplicitGC,-XX:+UseG1GC,-Xms1g,-Xmx4g - client node 2 > > Please suggest this.jvm option to avoid JVM pause issue. > > Thanks & Regards, > Charlin > > > > > > >
