<div dir="ltr">What idle GC does for you is tries to make you take the latency hit for garbage collection when your program is not CPU-bound, rather than doing it when you hit an arbitrary allocation threshold (probably during request processing when you're actually doing work). So in that case it's a good thing, yes --- but for yours I'd probably turn it off too. Other tweaks you can try include tweaking the RTS gc settings if you haven't already, especially increasing -A.</div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Nov 13, 2015 at 3:50 AM, David Turner <span dir="ltr"><<a href="mailto:dct25-561bs@mythic-beasts.com" target="_blank">dct25-561bs@mythic-beasts.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><span style="font-size:12.8px">Ah yes, and the more obvious question: should I just run it with -I0? I'm kind of assuming that the idle GC is a Good Thing since it's on by default.</span><br><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">Cheers,</span></div></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">On 13 November 2015 at 11:11, David Turner <span dir="ltr"><<a href="mailto:dct25-561bs@mythic-beasts.com" target="_blank">dct25-561bs@mythic-beasts.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hi all,<div><br></div><div>I'm working on a server process that has (by design) fairly high memory usage but serves relatively few requests and spends most of its time idle. By 'fairly high' I mean 100s of MB, nothing ridiculous. I'm trying to improve its quiescent CPU usage as this is currently the limiting factor for how cheaply we can run this service - we're aiming for the cheapest t-class EC2 machine we can get.</div><div><br></div><div>The quiescent CPU usage is currently about 50%. This seems to be largely due to the idle GC, because running with -I0 cuts it down to about 0.3%. Pretty much every time any thread wakes up it triggers the idle GC a short while later and because of the high memory usage these GCs are somewhat expensive.</div><div><br></div><div>Using threadscope I found the biggest problem was the reaper thread in resource-pool which wakes up every second whether there's anything to reap or not. Fortunately this was easy to spot as the reaper thread labels itself as such. I've replaced this with an event-driven reaper that only wakes up on demand and cut the baseline from 50% down to just under 10%.</div><div><br></div><div>There are two more threads I can now see waking up periodically in threadscope, with respective periods approximately 10 sec and 30 sec. I have a hunch what the 30-sec one is but no idea about the 10-sec one. If I can kill off the 10 sec one then that should take CPU usage down to <5% which would be just fine.</div><div><br></div><div>My question: is there any reliable way to determine where these threads came from, in terms of the location of the forkIO call that made them? I've just been looking for likely candidates and labelling threads and this is rather tedious.<br></div><div><br></div><div>Cheers,</div><div><br></div><div>David</div></div>
</blockquote></div><br></div>
</div></div><br>_______________________________________________<br>
Haskell-Cafe mailing list<br>
<a href="mailto:Haskell-Cafe@haskell.org">Haskell-Cafe@haskell.org</a><br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe</a><br>
<br></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature">Gregory Collins <<a href="mailto:greg@gregorycollins.net" target="_blank">greg@gregorycollins.net</a>></div>
</div>