That's a great article, Ibrahim. Thanks for sharing! On Thu, 9 May 2024 at 18:00, Ibrahim Altun <ibrahim.al...@segmentify.com> wrote:
> Try this post > > https://medium.com/segmentify-tech/garbage-collection-g1gc-optimisation-on-apache-ignite-7217f2d9186e > > > <https://www.segmentify.com/>İbrahim Halil AltunExpert R&D Developer+90 > 536 3327510 • segmentify.com → <https://www.segmentify.com/>UK • Germany > • Turkey • Spain • Poland <https://www.segmentify.com/> > > > On Thu, May 9, 2024 at 19:51 Jeremy McMillan <j...@gridgain.com> wrote: > >> 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 >>> >>> >>> >>> >>> >>> >>>
