Do all ticker stop? or just the one?
I had a problem back in 1.17? where the clock that powered the tickers
wasn't monotomic .. only on some systems and configurations..
-Eric
http://www.google.com/profiles/eric.hubbard
On Sun, Nov 26, 2023 at 11:39 PM Ari Croock wrote:
> Sorry for the conf
sort.Slice(s, func(i, j int) bool { return i > j })
You are comparing the indexes and not the values
-Eric
http://www.google.com/profiles/eric.hubbard
On Tue, Dec 6, 2022 at 6:45 PM Andrew Harris wrote:
> Subtly:
> return s[i] > s[j]
>
> Is the right sort func
>
> I think it'd be recomme
I'm eager to hear what the final answer is. These are the "fun" ones..:)
-Eric
http://www.google.com/profiles/eric.hubbard
On Mon, Oct 31, 2022 at 8:03 AM Robert Engels wrote:
> I would simply use kill to send a signal that generates a core dump and
> exits. Make sure you have the shell and s
What version of GoLang? tried different ones?
-Eric
http://www.google.com/profiles/eric.hubbard
On Tue, Oct 25, 2022 at 5:28 PM Steven Sokol wrote:
> I don't think so. I don't have it capped in the systemd configuration and
> it's not using very much memory even in the runaway state. Here's
Not sure if this helps but there is also this repo that does things a
little differently..
https://github.com/golang-fips/go
-Eric
http://www.google.com/profiles/eric.hubbard
On Mon, Sep 26, 2022 at 12:02 PM Ian Lance Taylor wrote:
> On Mon, Sep 26, 2022 at 2:51 PM Louisa Berger wrote:
> >
>
> debug.SetMemoryLimit will be useful (for me at least).
Me too! :) I need to read up more about it though. It seems to be a soft
limit, not a hard limit. We run in a container that has limited memory..
and anything we can do to make the GC aware of that limit would be nice..
-Eric
http://www.
How does go know about memory pressure? maybe that aspect is broken in my
environment... within a cgroup..etc..
On Saturday, 29 January 2022 at 02:16:56 UTC-8 Brian Candler wrote:
> What go version are you compiling with?
>
> go prior to 1.16 would hold onto memory such that the OS would only
v1.16.4
On Saturday, 29 January 2022 at 02:16:56 UTC-8 Brian Candler wrote:
> What go version are you compiling with?
>
> go prior to 1.16 would hold onto memory such that the OS would only
> reclaim it when under memory pressure; it could be made to free memory
> eagerly using GODEBUG=madvdon
I've been trying to root cause an OOM condition. My process is running
within a cgroup with a 4gb limit. Occasionally that limit gets hit. I
added a cgroup listener to watch for memory usage and create a pprof and
core dump.
The pprof shows just a few hundred megs of "in-use" memory, however
