<p dir="auto">Hello,<br>
while running the program at <a href="https://github.com/raintank/raintank-metric/tree/master/metric_tank">https://github.com/raintank/raintank-metric/tree/master/metric_tank</a><br>
I'm seeing mark-and-scan times of <del>15s cpu time, 2000</del>2500 ms clock time. (8 core system) for a heap of about 6.5GB<br>
(STW pauses are fine and ~1ms)<br>
I used <a href="https://circleci.com/gh/raintank/raintank-metric/507" rel="nofollow">https://circleci.com/gh/raintank/raintank-metric/507</a> to obtain the data below.</p>
<div class="snippet-clipboard-content notranslate position-relative overflow-auto" data-snippet-clipboard-copy-content="$ metric_tank --version
metrics_tank (built with go1.6, git hash 8897ef4f8f8f1a2585ee88ecadee501bfc1a4139)
$ go version
go version go1.6 linux/amd64
$ uname -a #on the host where the app runs
Linux metric-tank-3-qa 3.19.0-43-generic #49~14.04.1-Ubuntu SMP Thu Dec 31 15:44:49 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux"><pre class="notranslate"><code class="notranslate">$ metric_tank --version
metrics_tank (built with go1.6, git hash 8897ef4f8f8f1a2585ee88ecadee501bfc1a4139)
$ go version
go version go1.6 linux/amd64
$ uname -a #on the host where the app runs
Linux metric-tank-3-qa 3.19.0-43-generic #49~14.04.1-Ubuntu SMP Thu Dec 31 15:44:49 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux
</code></pre></div>
<p dir="auto">I know the app is currently not optimized for GC workload: while i've gotten allocations down in various parts of the program there are currently probably about a million or more live pointers referencing pieces of data. I was going to work on optimizing this when Dave Cheney suggested there's a problem with the runtime and I should file a bug (<a href="https://groups.google.com/forum/#!topic/golang-nuts/Q0rXKYjy1cg" rel="nofollow">https://groups.google.com/forum/#!topic/golang-nuts/Q0rXKYjy1cg</a>)<br>
Here's the log with gctrace and schedtrace enabled: <a href="https://gist.githubusercontent.com/Dieterbe/18453451c5af0cdececa/raw/9c4f2abd85bb7a815c6cda5c1828334d3d29817d/log.txt" rel="nofollow">https://gist.githubusercontent.com/Dieterbe/18453451c5af0cdececa/raw/9c4f2abd85bb7a815c6cda5c1828334d3d29817d/log.txt</a></p>
<p dir="auto">at <a href="http://dieter.plaetinck.be/files/go/mt3-qa-gc-vs-no-gc.zip" rel="nofollow">http://dieter.plaetinck.be/files/go/mt3-qa-gc-vs-no-gc.zip</a> you'll find a zip containing this log, the binary, a cpu profile taken during gc run 1482, and a cpu and heap profile in between run 1482 and 1483</p>
<p dir="auto">I also have these two dashboards that seem useful. (they both end just after the spike induced by GC run 1482)<br>
<a href="https://snapshot.raintank.io/dashboard/snapshot/MtLqvc4F6015zbs4iMQSPzfizvG7OQjC" rel="nofollow">https://snapshot.raintank.io/dashboard/snapshot/MtLqvc4F6015zbs4iMQSPzfizvG7OQjC</a><br>
shows memory usage, GC runs and STW pause times. it also shows that incoming load (requests) of the app is constant so this conveys to me that any extra load is caused by GC, not by changing workload<br>
<a href="https://snapshot.raintank.io/dashboard/snapshot/c2zwTZCF7BmfyzEuGF6cHN9GX9aM1V99" rel="nofollow">https://snapshot.raintank.io/dashboard/snapshot/c2zwTZCF7BmfyzEuGF6cHN9GX9aM1V99</a><br>
this shows the system stats. note the cpu spikes corresponding to the GC workload.</p>
<p dir="auto">let me know if there's anything else I can provide,<br>
thanks,<br>
Dieter.</p>
<p dir="auto">by <strong><a href="mailto:porjo38@yahoo.com.au">porjo38@yahoo.com.au</a></strong>:</p>
<pre class="notranslate">Anchor link history for Golang API web pages is broken when browsing with Firefox.

For example:

1. browse to <a href="http://golang.org/pkg/net/" rel="nofollow">http://golang.org/pkg/net/</a>
2. click on any of the items in the index. You will be auto-scrolled down to the item
heading
4. Click back button...nothing happens

Back button should take you back to the index. 

By trial and error, I've discovered that removing the stylesheet from the following line
fixes the issue:

&lt;div id="mainframe" style="position: fixed; bottom: 0; top:0;
overflow: auto; width: 100%;"&gt;

I'm not sure why this stylesheet is a problem for Firefox. Posting here so that others
can provide some insight.

Tested using Firefox 30.0 on Fedora 20 x86_64. Also confirmed this issue with others on
#go-nuts irc channel.</pre>