Thanks Mhd and agree with the suggestion.
However, we are trying to catch a bug which happens in production on k8s &
hence trying to explore different options.
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and
In writing to a file option, we would periodically write the file as it
might turn out to be a huge file
for the entire life of the pod to flush at once.
On Fri, Sep 11, 2020 at 6:32 PM Siddhesh Divekar
wrote:
> You need to write to a shared writable path that is global so when the
d writable path that is global so when the pod
> terminated the file is avail.
>
> The http should work too if you map the ports properly. You can be able to
> access the port from outside the pod.
>
> On Sep 11, 2020, at 7:14 PM, Siddhesh Divekar
> wrote:
>
>
> I went thr
of what we can do to get a trace file avoiding above
issues ?
On Fri, Sep 11, 2020 at 12:06 PM Robert Engels
wrote:
> Please read golang.org/cmd/trace
>
> You need a trace file. There are many ways to capture one.
>
> On Sep 11, 2020, at 12:09 PM, Siddhesh Divekar
> wrote:
>
r more complete and substantial on the standard tools.
>
> On Sep 11, 2020, at 1:37 AM, Siddhesh Divekar
> wrote:
>
>
> Is there any dependency on GOPATH while running `./goanalyzer binary
> trace-file` ?
> Also my goanalyzer is built on mac and am trying to look at trac
e as ‘go tool trace’ - the usage
> message is misleading in this way.
>
> By ‘map’ I mean expose the pprof port as you would any other port, and yes
> you use the net/http/pprof to start the internal webserver - you don’t need
> to create your own.
>
>
>
> On Sep 10, 2020,
ut might be easier to capture to a file via code and
> use goanalyzer on the file.
>
> On Sep 10, 2020, at 4:53 PM, Siddhesh Divekar
> wrote:
>
>
> Hi,
>
> Has anyone tried running goanalyzer on golang process running inside k8s
> pod.
>
> If so can you point me to
Hi,
Has anyone tried running goanalyzer on golang process running inside k8s
pod.
If so can you point me to the steps.
--
-Siddhesh.
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails
viewer is listening on
> http://127.0.0.1:57135
>
>
> On Aug 29, 2020, at 7:43 PM, Robert Engels wrote:
>
> I have not tried building it in a while. I assume some internals have
> changed. I’ll look into it.
>
> On Aug 29, 2020, at 7:08 PM, Siddhesh Divekar
> wrote:
>
>
Thanks !
On Sun, Aug 30, 2020 at 9:35 PM Siddhesh Divekar
wrote:
> That's right, I had modules enabled.
> After moving the repo under go path src directory it worked fine.
>
> echo $GOPATH
> /Users/sidhesh/Development/gocode
> ~/Development/gocode/src/github.com/robaho/goanaly
Hi,
Has anyone tried building goanalyzer recently?
Am I missing something very basic here.
goanalyzer/cmd/goanalyzer$ ls
annotations.go doc.go goroutines.go main.go pprof.go trace_test.go
annotations_test.go goanalyzer.iml internal mmu.go trace.go
trace_unix_test.go
goanalyzer/cmd/goanalyzer$
Shyaka,
The list package does all operation on list pointer.
In your case, I think you are passing list object instead of pointer.
You have defined your structure as:-
type Persons struct {
name string
Names list.List < Its a list object and not a pointer to
list object.
}
to not spin up another collector controller at the 2
> min mark if the previous has not completed.
>
> I would determine if the stuck collector is BQ or Elastic and check the
> server side logs.
>
> On Aug 26, 2020, at 11:29 PM, Kurtis Rader wrote:
>
>
> On Wed, Aug 26, 2020 at 8:5
tats/prefetcher.go:77 +0xf2
created by
git.fusion.io/fusionio/fusion/controller.git/stats.(*Prefetcher).prefetchStats
/builds/fusionio/fusion/controller/stats/prefetcher.go:100 +0xd8
On Wed, Aug 26, 2020 at 9:28 PM Kurtis Rader wrote:
> On Wed, Aug 26, 2020 at 8:51 PM Siddhesh
Typo.
>From backtrace we have from sigabort we see only *2* such data collector go
> routine blocked and other 2 2 mins thread waiting on waitgroup.
On Wed, Aug 26, 2020 at 8:50 PM Siddhesh Divekar
wrote:
> Right, then it looks less likely that we are blocked on a mutex.
>
>
nections
> (if they are all accessing BQ). Plus there are BQ rate limits - when you
> hit those the connector may block - again blocking all clients.
>
> On Aug 26, 2020, at 8:27 PM, Siddhesh Divekar
> wrote:
>
>
> Robert,
>
> That's where the confusion is.
> From
d on the mutex/lock).
>
>
>
> On Aug 26, 2020, at 10:09 AM, Siddhesh Divekar
> wrote:
>
> Robert,
>
> I assume we can safely add these timeouts based on what we expect
> should be a reasonable timeout for our clients ?
>
> s.ReadTimeout = expTimeOut * time.Sec
Hi Ian,
Got it !
Thanks.
On Wed, Aug 26, 2020 at 9:09 AM Ian Lance Taylor wrote:
> On Wed, Aug 26, 2020 at 8:03 AM Siddhesh Divekar
> wrote:
> >
> > What is the convention to name an environment variable if the program is
> going to set it and use it.
> > I have
Robert,
I assume we can safely add these timeouts based on what we expect
should be a reasonable timeout for our clients ?
s.ReadTimeout = expTimeOut * time.Second
s.WriteTimeout = expTimeOut * time.Second
On Tue, Aug 25, 2020 at 1:14 PM Siddhesh Divekar
wrote:
> Both servers and data sour
Hi,
What is the convention to name an environment variable if the program is
going to set it and use it.
I have seen both ABC_DEF & AbcDef forms of it.
--
-Siddhesh.
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this
ring “tcp stalls”.
>
> On Aug 25, 2020, at 9:24 AM, Siddhesh Divekar
> wrote:
>
>
> Clients are over the internet.
>
> On Tue, Aug 25, 2020 at 3:25 AM Robert Engels
> wrote:
>
>> The tcp protocol allows the connection to wait for hours. Go routines
>> s
Clients are over the internet.
On Tue, Aug 25, 2020 at 3:25 AM Robert Engels wrote:
> The tcp protocol allows the connection to wait for hours. Go routines
> stuck in wait do not burn CPU. Are the clients local or remote (over
> internet)?
>
> On Aug 24, 2020, at 10:29 PM, S
disabling http/2 and see if your issue goes away.
>
> On Aug 24, 2020, at 6:15 PM, Siddhesh Divekar
> wrote:
>
> Hi Robert,
>
> Sorry I missed your earlier response.
>
> From what we saw our UI was blocked and since everything was unresponsive
> we had to recover
Hi Robert,
Sorry I missed your earlier response.
>From what we saw our UI was blocked and since everything was unresponsive
we had to recover the system by sending sig abort.
On Mon, Aug 24, 2020 at 4:11 PM Siddhesh Divekar
wrote:
> Looking at the no. of go routines we have does this
n from waiting to processing -
> this could show up as high CPU usage while everything looks blocks.
>
> I would use pprof - github.com/robaho/goanalyzer might be of assistance
> here to see the actual work being done.
>
> On Aug 24, 2020, at 9:10 AM, Siddhesh Divekar
> wrote:
Hi All,
We saw an issue with our process running in k8s on ubuntu 18.04.
Most of the go routines are stuck for several minutes in http/http2 net
code.
Have you seen similar issues ?
goroutine 2800143 [select, 324 minutes]:
net/http.(*persistConn).readLoop(0xc00187d440)
26 matches
Mail list logo
