rw.r.Intn(rw.sumOfWeights)
//fmt.Printf("rand val: %d\n",randomWeight)
...
}
I am sorry about that I did't give the context of my code.
在 2019年6月27日星期四 UTC+8上午11:22:49，Kurtis Rader写道：
>
> On Wed, Jun 26, 2019 at 8:18 PM Chou Yan > wrote:
>
>> I fix it by :
>>
&g
ializing the RNG in a tight loop. Since
> `time.Now().Unix()` has a resolution of one second you end up generating
> the same initial value every time through the loop until the current time
> advances to the next second.
>
> On Wed, Jun 26, 2019 at 7:48 PM Chou Yan > wrote:
,errors.New("get next err")
}
return no, nil
}
}
thx
在 2019年6月27日星期四 UTC+8上午11:16:01，Chou Yan写道：
>
> The situation I am currently experiencing is that it only occur on my
> online app. I try it at local but I can not got the result.
> haha... I make a mistake.
> the code i
6月27日星期四 UTC+8上午10:52:56，Burak Serdar写道：
>
> On Wed, Jun 26, 2019 at 8:48 PM Chou Yan > wrote:
> >
> > like this:
> > r:=rand.New(rand.NewSource(time.Now().Unix()))
> > for {
> > r.Intn(96)
> > }
> > I know the same seed will generate t
o()', It will not.
I suspect what this is related to the seqence rand algorithm,But I have no
relevant evidence
在 2019年6月27日星期四 UTC+8上午10:32:38，Burak Serdar写道：
>
> On Wed, Jun 26, 2019 at 8:17 PM Chou Yan > wrote:
> >
> > I use:
> > r:=rand.New(rand.NewSource(t
I use:
r:=rand.New(rand.NewSource(time.Now().Unix()))
r..Intn(96)
I got:
and val: 82
rand val: 82
rand val: 82
rand val: 82
rand val: 82
rand val: 82
rand val: 82
rand val: 82
rand val: 82
rand val: 82
rand val: 82
rand val: 82
rand val: 82
rand val: 82
rand val: 82
rand val: 82
rand val: 82
rand
I use 'debug.FreeOsMemory'. But it is not the certain.
在 2019年6月24日星期一 UTC+8上午10:59:06，Chou Yan写道：
>
> My server have 100G memory.
> I limit my server 60G by cgroups.
> But my app process use the momory more and more !
> even more than 50G.
> my prof:
>
> # He
I am use 'debug.FreeOsMemory'. But it is not the certain.
在 2019年6月24日星期一 UTC+8上午10:59:06，Chou Yan写道：
>
> My server have 100G memory.
> I limit my server 60G by cgroups.
> But my app process use the momory more and more !
> even more than 50G.
> my prof:
40585/0+297 ms
cpu, 22495->22569->4643 MB, 23425 MB goal, 64 P
在 2019年6月24日星期一 UTC+8上午10:59:06，Chou Yan写道：
>
> My server have 100G memory.
> I limit my server 60G by cgroups.
> But my app process use the momory more and more !
> even more than 50G.
> my prof:
>
>
My server have 100G memory.
I limit my server 60G by cgroups.
But my app process use the momory more and more !
even more than 50G.
my prof:
# HeapIdle = 27377164288
# HeapInuse = 21910396928
The Cgroup will kill the process when it use more than 60G
But golang runtime gc will not release the
thx
在 2019年6月21日星期五 UTC+8下午12:38:50，Ian Lance Taylor写道：
>
> On Thu, Jun 20, 2019 at 7:22 PM Chou Yan > wrote:
> >
> > The describe 'release the physical memory' may not be rigorous. Because
> gc remand the span,obj, or big obj to heap or central area, may
during sweep termination?
在 2019年6月21日星期五 UTC+8上午8:54:31，Ian Lance Taylor写道：
>
> On Thu, Jun 20, 2019 at 9:56 AM Chou Yan > wrote:
> >
> > I look up the doc for gctrace:
> > https://godoc.org/runtime
> > it show us:
> >
> > Currently, it is:
>
weep = scan the root span', like java cms 'gc root scan'?
not the release the physical memory?
在 2019年6月21日星期五 UTC+8上午8:54:31，Ian Lance Taylor写道：
>
> On Thu, Jun 20, 2019 at 9:56 AM Chou Yan > wrote:
> >
> > I look up the doc for gctrace:
> > https://god
I look up the doc for gctrace:
https://godoc.org/runtime
it show us:
Currently, it is:
gc # @#s #%: #+#+# ms clock, #+#/#/#+# ms cpu, #->#-># MB, # MB goal, #
P
where the fields are as follows:
gc #the GC number, incremented at each GC
@#s time in seconds s
14 matches
Mail list logo
