GC Settings for low latency

[Janny]

We use Java8, Disruptors, we read from sockets market data and deliver them to our algo engine. Because of this lots of small objects created when we parse FIX messages. What will be your suggestion regarding GC tuning for low latency. We don't want FullGC stop the world, etc. Any suggestion? any articles to read?

[Jean-Philippe BEMPEL]

1) Size your heap to make the day without Full GC

2) reduce your allocation

3) go off heap see https://github.com/OpenHFT

[peter royal]

Zing from Azul. It will pay for itself in developer-time spent. 

-- 

peter royal - (on the go)

On Feb 17, 2015, at 7:25 AM, Janny <winnie...@gmail.com> wrote:

We use Java8, Disruptors, we read from sockets market data and deliver them to our algo engine. Because of this lots of small objects created when we parse FIX messages. What will be your suggestion regarding GC tuning for low latency. We don't want FullGC stop the world, etc. Any suggestion? any articles to read?

--
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-symp...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Jean-Philippe BEMPEL]

+1 

should have added to my list :(

[Jan van Oort]

Ad Jean-Philippe Bempel's #3: 

- more specifically, store large collections / (hash) maps / sets etc. in memory-mapped files. On Linux / Unices, use tmpfs instead of ext4 / xfs / whatever-fs for that. 

I would like to add: 

4) for large collections / (hash) maps / sets etc that you use often or that are critical for you: design your own binary file format. For an example, see 

http://www.aclweb.org/anthology/W09-1505 , especially page 32. 

Fortuna audaces adiuvat - hos solos ? 

[Richard Warburton]

Hi,

We use Java8, Disruptors, we read from sockets market data and deliver them to our algo engine. Because of this lots of small objects created when we parse FIX messages. What will be your suggestion regarding GC tuning for low latency. We don't want FullGC stop the world, etc. Any suggestion? any articles to read?

Are you sure there's a need to create lots of small objects when parsing FIX messages. Might be worth a quick bit of memory profiling to cut down your allocation rate.

regards,

  Richard Warburton

  http://insightfullogic.com

  @RichardWarburto

[Kirk Pepperdine]

+1, with C24’s SDO implementation I was able to cut allocation rates down quite a bit on parsing and down to 0 for query performance. We started at 1.8Gig/sec.

[Michael Barker]

+1 for using Zing.  If improving latency is how you make more money, there is a straightforward business case for paying the costs.

Prior to using Zing we used ParNew and CMS for a long time.  Our best tuning involved running with a very small eden space (16-32MB) resulting in frequent but short new GCs (1-5ms).  We generate too much garbage to take the alternative approach which is to have a huge eden and only GC manually during a maintenance window.

[Wojciech Kudla]

I remember a few years back we achieved 90th minor GC times at or below 650 micros on Oracle's hotspot (1.6 server, ParNew).

We sized YG at 512-1024MB. It was on a fairly quiesced system (isolcpus, affinity, rcu threads pinned, irqs blacklisted from app cores, etc.) + object demographics was an ideal case of generational hypothesis in action (pretty much no survivors after 3-4 gens).

[Vitaly Davidovich]

The other option is to write these systems in a similar style to c/c++: avoid memory allocation on hot paths.  It's harder to do in java but it's possible (especially if you can size your eden to make it through the day without any GC whatsoever).

sent from my phone