Re: [go-nuts] Re: Why does my time.Ticker work fine for 6 months then suddenly stop sending ticks?

2023-11-27 Thread Eric Hubbard 
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 confusion, I must have updated go since I built this binary.
> If I run `go version ` I get "go1.20.4" (released 2023-05-02)
> which sounds about right.
>
> On Monday, 27 November 2023 at 05:24:08 UTC+2 Kevin Chowski wrote:
>
>> Perhaps I'm missing something, but given that 1.21.4 was
>> released 2023-11-07 I'm not sure how it could have been running for 6
>> months. Do you mind double-checking your assumptions?
>>
>> On Sunday, November 26, 2023 at 4:59:10 PM UTC-5 Ari Croock wrote:
>>
>>> Hi,
>>>
>>> I hope someone here can shed some light on a problem I'm having.
>>>
>>> There is a detailed explanation on my stackoverflow question:
>>> https://stackoverflow.com/questions/77538297/why-does-my-time-ticker-work-fine-for-6-months-then-suddenly-stop-sending-ticks
>>>
>>> The summary is I have a very simple time.Ticker running with a period of
>>> 24h which calls a function that normally only takes a few seconds to run.
>>> This worked perfectly fine for about 6 months but then suddenly stopped
>>> working (the program has been continuously running for 6 months).
>>>
>>> I have attached the debugger so I can see it has paused execution on the
>>> `select` statement, waiting for a value on the ticker channel. There
>>> doesn't seem to be any way that the ticker.Stop method was called anywhere.
>>> If anyone has any suggestions for things to look for in the debugger that
>>> would be very welcome.
>>>
>>> The binary was built using "go version go1.21.4 linux/amd64".
>>>
>>> Thanks
>>>
>> --
> 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+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/c006f5e5-2484-4ebd-87ab-f254760fe200n%40googlegroups.com
> 
> .
>

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CABOXiu1ZD8qeS3VxfHSABuVnOoowiKh-p9QmQzmuxqGOmMJ4VA%40mail.gmail.com.

Re: [go-nuts] Re: Why this simple sorting code doesn't work?

2022-12-06 Thread Eric Hubbard 
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 recommended to look at the generics slices package, which
> also has a sort
> On Tuesday, December 6, 2022 at 6:39:29 PM UTC-8 hey...@gmail.com wrote:
>
>> Hi,
>>
>> I have this very simple sorting code:
>>
>> s := make([]int, 0, 100)
>> for i := 1; i <= 20; i++ {
>> s = append(s, i)
>> }
>> sort.Slice(s, func(i, j int) bool { return i > j })
>> log.Print(s)
>>
>> I expect it to print numbers in reverse order, since items with larger
>> index numbers should be at the front. However, at lease in go1.19.3, it
>> prints
>>
>> [9 1 8 5 16 3 20 2 10 7 12 13 14 15 6 4 19 18 17 11]
>>
>> I guess I must have misunderstood how the sort package works, but
>> rereading sort's doc multiple time doesn't help answer the question.
>>
>> Could anyone shed some light?
>>
> --
> 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+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/47074e6b-b1f2-447e-b7aa-645b9a504913n%40googlegroups.com
> 
> .
>

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CABOXiu2KiVok-h2qHCLfUZf4Cw_scGBu5JrFm-5P%2BAeTwe1%2BCQ%40mail.gmail.com.

Re: [go-nuts] Occasional hard lockup w/ 100% CPU usage in go applications

2022-10-31 Thread Eric Hubbard 
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 security settings setup to all this
> to happen.
>
> On Oct 31, 2022, at 9:55 AM, Steven Sokol  wrote:
>
> I tried doing that and it did not seem to work:
>
> root@pi4cm1(rw):/# gcore -o ~/lockup.core 22022
> Unable to attach: program exited with code 1.
> You can't do that without a process to debug.
> The program is not being run.
> gcore: failed to create /root/lockup.core.22022
>
> The attempt somehow killed the process.
>
> On Wednesday, October 26, 2022 at 10:03:30 AM UTC-5 Konstantin Khomoutov
> wrote:
>
>> On Wed, Oct 26, 2022 at 08:45:00AM -0500, Robert Engels wrote:
>>
>> > Trigger a core dump then use gdb on the core file.
>>
>> Also, the gdb is usually shipped with the `gcore` helper which can attach
>> to
>> the specified PID and dump its core.
>>
>> --
> 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+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/75272721-b821-4081-af23-2c84147bfadcn%40googlegroups.com
> 
> .
>
> --
> 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+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/CC5D84DB-A09C-4A5D-91FE-1A52940CA018%40ix.netcom.com
> 
> .
>

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CABOXiu2ZN0BxDE9EXEi168JvBAq3GwXhP6FbBVRZfH3nB8jOkQ%40mail.gmail.com.

Re: [go-nuts] Occasional hard lockup w/ 100% CPU usage in go applications

2022-10-25 Thread Eric Hubbard 
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 a
> screenshot of htop - check out the fvUnisocket process at the top of the
> list:
>
>
> https://user-images.githubusercontent.com/350268/197785991-a8a9691b-4499-4e7a-b0c5-557ef2924514.png
>
>
> On Tuesday, October 25, 2022 at 6:42:14 PM UTC-5 ren...@ix.netcom.com
> wrote:
>
>> Are you certain you haven’t capped the memory and all of the GC threads
>> are spinning trying to claim/allocate memory?
>>
>> On Oct 25, 2022, at 4:49 PM, Steven Sokol  wrote:
>>
>> Weird one. I have a go application that, on occasion, will suddenly jump
>> from some very low CPU usage (1% - 10%) to 400% (4 core system). I run this
>> app at a heightened priority and it can nearly lock the machine (Pi CM4) up.
>>
>> I can kill it with SIGKILL and I'm able to get a stack trace by sending
>> SIGQUIT. (Here's a gist
>>  of the
>> stack trace.)
>>
>> The trace would seem to indicate that everything is idle - virtually all
>> the goroutines are in runtime.gopark. None of them ever get out of it. I've
>> tried adding a watchdog timer and it locks up along with all the other
>> goroutines, so it never fires once the runaway event starts.
>>
>> The app itself isn't anything special. It listens for data on a set of
>> about  16 Redis pubsub channels and forwards any data it receives to a very
>> limited number of clients over UDP. Throughput ranges from 34 - 38 KB/sec,
>> and the message counts are in the hundreds. Most of the time it eats about
>> 5% of one core on the CM4.
>>
>> I guess this could be an error on my part, but there's nothing in my code
>> that seems likely to cause this - no obvious place for a multi-threaded
>> tight loop. I thought for a while that it might be some sort of an issue in
>> Redigo (golang redis client) but from what that stack trace shows, it looks
>> like all the redis listeners are happy and healthy and stuck waiting in
>> gopark along with all the other goroutines.
>>
>> Has anyone seen this kind of weird before?
>>
>> Thanks,
>>
>> -S
>>
>>
>> --
>> 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...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/golang-nuts/5465198d-9a48-4db1-98d5-498922b1ac39n%40googlegroups.com
>> 
>> .
>>
>>
>> --
> 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+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/382df009-cd81-4f62-ae67-03dfc1bb338en%40googlegroups.com
> 
> .
>

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CABOXiu1qCZLBfOY77aJBwcPBrSLnoES21H2XEwFbJ8iNfLXhxQ%40mail.gmail.com.

Re: [go-nuts] BoringCrypto on arm64?

2022-09-26 Thread Eric Hubbard 
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:
> >
> > I've been using the BoringCrypto package, and would like to use it on
> Graviton as well. I see from the caveat here (
> https://go.googlesource.com/go/+/dev.boringcrypto/misc/boring#caveat )
> that BoringCrypto is only supported for GOOS=linux, GOARCH=amd64.
> >
> > Are there any plans to support BoringCrypto on arm64? If so, when? And
> if not, is there a recommended alternative?
>
> On tip, and the future Go 1.20, you can build with
> GOEXPERIMENT=boringcrypto, and get a version of Go that uses
> boringcrypto and supports arm64.  This was added in
> https://go.dev/cl/423362.  Not sure whether it is documented anywhere
> yet.
>
> Ian
>
> --
> 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+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/CAOyqgcULMkdHjX1Ww4Vr_4SLOuBW1JiCjwWpoZLVkgYk%3DK%3DcyQ%40mail.gmail.com
> .
>

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CABOXiu3wECKuJT2DgJDQmppvht3aBKDHDkuM-LmU8px%2BOkFrnw%40mail.gmail.com.

Re: [go-nuts] Re: Go 1.19 Beta 1 is released

2022-06-12 Thread Eric Hubbard 
> 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.google.com/profiles/eric.hubbard


On Sun, Jun 12, 2022 at 9:37 AM Amnon  wrote:

> debug.SetMemoryLimit will be useful (for me at least).
> But a bit disappointed not to see a fix for
> https://github.com/golang/go/issues/50603.
>
> On Sunday, 12 June 2022 at 05:51:23 UTC+1 ben...@gmail.com wrote:
>
>> I'm quite looking forward to the performance improvements we'll get for
>> free (i.e., by just upgrading): sort will be faster, large switch blocks
>> will be faster due to now using jump tables (good for interpreter
>> opcode-dispatch loops), and regexp will be a little faster due to a
>> pointer-vs-value optimization (
>> https://go-review.googlesource.com/c/go/+/355789 -- not mentioned in the
>> Go 1.19 release notes).
>>
>> -Ben
>>
>> On Sunday, June 12, 2022 at 9:27:27 AM UTC+12 Ian Lance Taylor wrote:
>>
>>> On Sat, Jun 11, 2022 at 12:30 AM Amnon  wrote:
>>> >
>>> > What are the biggest, and most exciting changes coming in 1.19?
>>>
>>> The draft release notes are at https://tip.golang.org/doc/go1.19 .
>>>
>>> 1.18 was a big release with a lot of exciting changes. 1.19 is more
>>> of a relaxed, catch your breath release. Personally I think the most
>>> exciting change is runtime/debug.SetMemoryLimit.
>>>
>>> Ian
>>>
>> --
> 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+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/bb037f28-5185-47fb-a439-23f61b7d716fn%40googlegroups.com
> 
> .
>

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CABOXiu1PD8UhiP3tEEokYdB-WfD6-kxKcB4LfvT%3DGmtyFLz9sA%40mail.gmail.com.

[go-nuts] Re: Lots of retained free spans

2022-01-29 Thread Eric Hubbard 
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 
> reclaim it when under memory pressure; it could be made to free memory 
> eagerly using GODEBUG=madvdontneed=1.  This was made the default in go 1.16.
>
>
> https://discuss.dgraph.io/t/benchmarks-using-godebug-madvdontneed-environment-variable/7322
> https://go.dev/doc/go1.16#runtime
>
> On Saturday, 29 January 2022 at 01:02:18 UTC eric.h...@gmail.com wrote:
>
>> 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 when 
>> I open the core dump with viewcore I'm seeing around 3.3gb of free spans 
>> that are being retained.  "kept for reuse by Go"..
>>
>> I've got GOGC set to 50 -- but my understanding is that just controls 
>> when a GC kicks off -- not when memory will be returned to the OS.   
>>
>> Is there some sort of behavior a program can do to create this type of 
>> situation?  or a way to give a hint to the GC  .. "hey... give it back!" 
>> :)   
>>
>> Thanks for any ideas or thoughts!
>>
>

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/c5d6c8cb-144e-4753-9938-cd3da9e47c99n%40googlegroups.com.

[go-nuts] Re: Lots of retained free spans

2022-01-29 Thread Eric Hubbard 
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=madvdontneed=1.  This was made the default in go 1.16.
>
>
> https://discuss.dgraph.io/t/benchmarks-using-godebug-madvdontneed-environment-variable/7322
> https://go.dev/doc/go1.16#runtime
>
> On Saturday, 29 January 2022 at 01:02:18 UTC eric.h...@gmail.com wrote:
>
>> 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 when 
>> I open the core dump with viewcore I'm seeing around 3.3gb of free spans 
>> that are being retained.  "kept for reuse by Go"..
>>
>> I've got GOGC set to 50 -- but my understanding is that just controls 
>> when a GC kicks off -- not when memory will be returned to the OS.   
>>
>> Is there some sort of behavior a program can do to create this type of 
>> situation?  or a way to give a hint to the GC  .. "hey... give it back!" 
>> :)   
>>
>> Thanks for any ideas or thoughts!
>>
>

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/1deb8716-4b07-4dd6-8d79-17c7952b1590n%40googlegroups.com.

[go-nuts] Lots of retained free spans

2022-01-28 Thread Eric Hubbard 
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 when I 
open the core dump with viewcore I'm seeing around 3.3gb of free spans that 
are being retained.  "kept for reuse by Go"..

I've got GOGC set to 50 -- but my understanding is that just controls when 
a GC kicks off -- not when memory will be returned to the OS.   

Is there some sort of behavior a program can do to create this type of 
situation?  or a way to give a hint to the GC  .. "hey... give it back!" 
:)   

Thanks for any ideas or thoughts!

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/5368c3f1-1734-4ace-a97e-2b9fbcc56343n%40googlegroups.com.