go 1.19 has just been released and the problem is gone!
--
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 dis
I was having the same problem without TLS but the symptoms are exactly the
same, even the part "The "loop" seems to be interruptable by triggering a
new connection, or by itself after ~1m54s"
I spent 4 days trying to get a consistent way to reproduce it but coulnd't
so I gave up and keept using
This "smells" a lot like https://github.com/golang/go/issues/51654 - though
the repro is with TLS.
This is very disruptive for us (MinIO) as well, seeing this at several
customers. Obviously downgrading to Go 1.16.6 is less than optimal for us.
/Klaus
On Tuesday, 12 April 2022 at 14:55:41 UTC+
Correct: "go run" builds a binary and then fork/execs the binary it has
built, to run it.
On Tuesday, 12 April 2022 at 08:19:38 UTC+1 scorr...@gmail.com wrote:
> By the way, the difference that I thought I saw between go run and the
> compiled version was because the pid of the process to look
By the way, the difference that I thought I saw between go run and the
compiled version was because the pid of the process to look at in the below
example should be 63668, the tmp file, not 63548, the go run call.
$ ps aux | grep test
bill 63548 0.2 0.1 2044984 17588 pts/0 Sl+ 09:15
Hi, yes, all about the toy program is the same. It was an attempt to get to
a minimal example that anyone can reproduce so I could ask for help. The
real problem is with a larger program where I get this 100% CPU usages
ramdomly when the server is idle.
I was thinking and with the basic example
At the start of the thread, you said "if I compile and run this simple
program ..."
Does the problem no longer reproduce with that?
On Monday, 11 April 2022 at 22:59:55 UTC+1 scorr...@gmail.com wrote:
> I tried with a more complex application and already got constant 100% CPU
> usage twice.
>
I tried with a more complex application and already got constant 100% CPU
usage twice.
When I attach strace I see the same as with the minimal demo but with much
more frecuency:
[pid 42659] 23:36:49.035120 epoll_pwait(3, [], 128, 0, NULL,
140341803388040) = 0
[pid 42659] 23:36:49.035133 epoll
I tried with the stripped tmp version of "go run" and after a while I was
able to reproduce it too. It definitely took me more time but probably is
just random.
I tried "$ GODEBUG=asyncpreemptoff=1 ./test" and I kept seeing the the
calls every 10ms. Is this expected to happen?
I compiled the
On Monday, 11 April 2022 at 09:26:28 UTC+1 scorr...@gmail.com wrote:
> and the output keeps growing like that with every new curl request until
> eventually it starts constantly printing output like this:
>
>>
>> [pid 143818] 10:02:22.697120 nanosleep({tv_sec=0, tv_nsec=1000},
>> NULL) = 0
>
I discovered this in another very similar pc, a bit older Lenovo Legion
laptop:
$ grep "model" /proc/cpuinfo | sort | uniq -c
12 model: 158
12 model name: Intel(R) Core(TM) i7-8750H CPU @ 2.20GHz
$ uname -r
5.4.0-107-generic
$ cat /etc/*ease
DISTRIB_ID=LinuxMint
DISTRIB_RE
Hi Brian, thanks for your help.
Al my go downloads are from go.dev
In this tests I am using
$ go version
go version go1.18 linux/amd64
I run the tests in a laptop with linux as the main OS, no emulation.
$ grep "model" /proc/cpuinfo | sort | uniq -c
12 model: 165
12 model name
Those nanosleep calls are at 10ms intervals - i.e. 100 calls per second. I
think this is normal behaviour of the Go scheduler, which signals itself
every 10ms to force a preemptive context switch. That feature was
introduced in go 1.14, at which point you were able to disable it at
runtime se
13 matches
Mail list logo
