FAQ
On Mon, Mar 23, 2015 at 2:50 PM, Dave Cheney wrote:
On 24 Mar 2015 08:45, "Peter Vessenes" wrote:


On Mon, Mar 23, 2015 at 2:37 PM, Dave Cheney wrote:

On 24 Mar 2015 08:06, "Peter Vessenes" wrote:

Thanks.

For my use case, seems like running the first phase and then punting
if there's no major changes would save a lot of stop the world time. Or
just turning this off; the scavenger isn't the only thing that will trigger
a GC, is it?
There may be an environment variable for this, I don't know it.
Can it just scavenge what was previously freed, without doing the
free? That would let me chew up memory as I see fit and not worry about the
stops so often if nothing is happening.
If no gc cycle is run, then nothing will be freed. That's the problem
with this line of argument. The scavenger relies on the gc to free
allocations on a page size piece of memory so it can advise the OS that the
contents are not needed.
Right, but a server doing nothing is not allocating (much); if we want
the server to be greedy or prefer uninterrupted availability, perhaps the
scavenger just takes what it's given. the GC would presumably still be run
when memory allocations exceed some threshold. To my mind, I'd like to make
that call as the server developer; I'm not complaining about the default
behavior particularly, and if it happened in 50ms chunks with no
perceivable downtime, I wouldn't complain at all. As it is, it happens in 1
to 5 second chunks very often.

If a server is doing nothing then does time spent on housekeeping matter?

The general philosophy of the go runtime is to eschew knobs and dials and
choose sensible defaults that work for the majority case. I suggest raising
a bug. There may be a way to disable the scavenger but I don't know it.

You may also want to try GOGC=off and see the effect it has on your
application.
Thanks Dave. I'm probably wait and see right now how 1.5's work turns out;
it's enough to understand the source at this point. I agree with your
perspective that the long runtimes are the thing bugging me, not the
frequency of scavenging, per-se. I also agree that reducing cognitive load
is one of the many benefits of using go, so my first response isn't "more
options for scavenging!"

But, I do maintain a small patchset already for our tool, and some
adjustments might go in there. In answer to your question on GOGC=off, the
total lifetime memory allocation is well in excess of our server RAM, on
the order of 300-500GB, so we do need that collection. I would LOVE to be
able to turn off GC during certain phases of the server lifecycle, though,
then turn it back on later. Can this be done, to your knowledge? I don't
know how to fake commandline settings to the runtime like that, if there is
in fact a way.

Peter
On Fri, Mar 20, 2015 at 5:39 PM, Dave Cheney wrote:

That's your answer then. The scavenger will trigger a GC if one has
not been performed in the last 300 seconds. I may be slightly wrong on
those numbers, I do seem to always be a incorrect then talking about the
behaviour of the scavenger, but suffice to say, it triggers the GC
periodically so that heap pages are free (of live data) so that it may
return them to the operating system (on its next run)
On Saturday, 21 March 2015 09:34:54 UTC+11, Peter Vessenes wrote:

I am not filtering them, except in my post. :) Yes, each is
preceded by a scavenger run: sample line:
scvg54: inuse: 62455, idle: 120133, sys: 182589, released: 120133,
consumed: 62455 (MB)

Peter
On Friday, March 20, 2015 at 3:12:20 PM UTC-7, Dave Cheney wrote:

Are you filtering these log files ? The most likely cause is the
scavenger, which should also be outputting to the log with a svg prefix
--
You received this message because you are subscribed to a topic in
the Google Groups "golang-nuts" group.
To unsubscribe from this topic, visit
https://groups.google.com/d/topic/golang-nuts/_uWOKYFFyXc/unsubscribe.
To unsubscribe from this group and all its topics, send an email to
golang-nuts+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.



--

________________________________

PETER VESSENES
CEO

peter@coinlab.com / 206.486.6856 / SKYPE: vessenes
900 Winslow Way East / SUITE 100 / Bainbridge Island, WA 98110



--

________________________________

PETER VESSENES
CEO

peter@coinlab.com / 206.486.6856 / SKYPE: vessenes
900 Winslow Way East / SUITE 100 / Bainbridge Island, WA 98110


--

------------------------------

[image: CoinLab Logo]PETER VESSENES
CEO

*peter@coinlab.com <peter@coinlab.com> * / 206.486.6856 / SKYPE: vessenes
900 Winslow Way East / SUITE 100 / Bainbridge Island, WA 98110

--
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Search Discussions

Discussion Posts

Previous

Follow ups

Related Discussions

Discussion Navigation
viewthread | post
posts ‹ prev | 9 of 13 | next ›
Discussion Overview
groupgolang-nuts @
categoriesgo
postedMar 20, '15 at 7:32p
activeMar 24, '15 at 5:56p
posts13
users3
websitegolang.org

People

Translate

site design / logo © 2021 Grokbase