https://www.arp242.net/static-go.html

> On May 5, 2022, at 11:27 PM, garenchan <garencha...@gmail.com> wrote:
> 
> The binary file is not a dynamic executable.   So I don't think that will 
> happen.
> 
> 在2022年5月6日星期五 UTC+8 11:54:44<ren...@ix.netcom.com> 写道:
>> Are you certain that on the low memory instance there isn’t another process 
>> - maybe Go - that hasn’t already loaded the shared libraries - and on the 
>> other it hasn’t - so the RSS is different. Compare the VSZ sizes and see if 
>> they are the same. 
>> 
>>>> On May 5, 2022, at 10:28 PM, garenchan <garen...@gmail.com> wrote:
>>>> 
>>> @jake, I tried 1.18 version of Go, but the problem still exists. 
>> 
>>> 
>>> I also tried using C to write program that includes memory allocation and 
>>> usage,  and this problem does not occur.
>>> 在2022年5月5日星期四 UTC+8 21:25:20<jake...@gmail.com> 写道:
>>>> Since no one has responded with concrete ideas, I'll throw out two 
>>>> suggestions. They may seem obvious.
>>>> 
>>>>  First have you tries the latest version of Go? and do you get the same 
>>>> results?
>>>> 
>>>>  Second have you run the experiment with a small binaries not from Go? I 
>>>> would suggest something that does allocate some real memory, not a "hello 
>>>> world" C program or something.
>>>>> On Thursday, May 5, 2022 at 7:21:39 AM UTC-4 garenchan wrote:
>>>>> 
>>>>> Both hosts have 8 cores and 16GB RAM.
>>>>> 在2022年4月30日星期六 UTC+8 00:19:44<garenchan> 写道:
>>>>>> What version of Go are you using (go version)?
>>>>>> 
>>>>>> $ go version
>>>>>> go version go1.17.6 linux/amd64
>>>>>> 
>>>>>> Does this issue reproduce with the latest release?
>>>>>> 
>>>>>> uncertain
>>>>>> 
>>>>>> What operating system and processor architecture are you using (go env)?
>>>>>> 
>>>>>> $ go env
>>>>>> GO111MODULE="on"
>>>>>> GOARCH="amd64"
>>>>>> GOBIN=""
>>>>>> GOCACHE="/root/.cache/go-build"
>>>>>> GOENV="/root/.config/go/env"
>>>>>> GOEXE=""
>>>>>> GOEXPERIMENT=""
>>>>>> GOFLAGS=""
>>>>>> GOHOSTARCH="amd64"
>>>>>> GOHOSTOS="linux"
>>>>>> GOINSECURE=""
>>>>>> GOMODCACHE="/root/go/pkg/mod"
>>>>>> GONOPROXY=""
>>>>>> GONOSUMDB=""
>>>>>> GOOS="linux"
>>>>>> GOPATH="/root/go"
>>>>>> GOPRIVATE=""
>>>>>> GOPROXY=""
>>>>>> GOROOT="/home/go"
>>>>>> GOSUMDB="off"
>>>>>> GOTMPDIR=""
>>>>>> GOTOOLDIR="/home/go/pkg/tool/linux_amd64"
>>>>>> GOVCS=""
>>>>>> GOVERSION="go1.17.6"
>>>>>> GCCGO="gccgo"
>>>>>> AR="ar"
>>>>>> CC="gcc"
>>>>>> CXX="g++"
>>>>>> CGO_ENABLED="1"
>>>>>> GOMOD="/home/demo/go.mod"
>>>>>> CGO_CFLAGS="-g -O2"
>>>>>> CGO_CPPFLAGS=""
>>>>>> CGO_CXXFLAGS="-g -O2"
>>>>>> CGO_FFLAGS="-g -O2"
>>>>>> CGO_LDFLAGS="-g -O2"
>>>>>> PKG_CONFIG="pkg-config"
>>>>>> GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 
>>>>>> -fdebug-prefix-map=/tmp/go-build4023324410=/tmp/go-build 
>>>>>> -gno-record-gcc-switches"
>>>>>> 
>>>>>> What did you do?
>>>>>> 
>>>>>> I encountered a memory problem with the GO program, see here for 
>>>>>> details.(https://stackoverflow.com/questions/71994609/memory-footprint-of-the-same-program-varies-greatly-in-two-similar-environments)
>>>>>> 
>>>>>> In order to simplify the analysis, I wrote a simple program to test.
>>>>>> 
>>>>>> ```go
>>>>>> package main
>>>>>> 
>>>>>> import (
>>>>>>     "time"
>>>>>> )
>>>>>> 
>>>>>> func main() {
>>>>>>     time.Sleep(60*time.Second)
>>>>>> }
>>>>>> ```
>>>>>> 
>>>>>> I compiled it into binary file on a linux host `host1` with kernel 4.18. 
>>>>>> Then I run it on `host1` and the process takes up close to 5MB RSS.
>>>>>> I then copy the binary file to another host `host2` with kernel 4.18. I 
>>>>>> also ran it on `host2`, but this time the process took up less than 1MB 
>>>>>> RSS.
>>>>>> I repeated the test many times and observed the same thing.
>>>>>> 
>>>>>> ```
>>>>>> $ uname -a
>>>>>> Linux host1 4.18.0 #1 SMP Wed Nov 10 20:46:19 CST 2021 x86_64 x86_64 
>>>>>> x86_64 GNU/Linux
>>>>>> 
>>>>>> $ uname -a
>>>>>> Linux host2 4.18.0 #1 SMP Fri May 8 10:59:10 UTC 2021 x86_64 x86_64 
>>>>>> x86_64 GNU/Linux
>>>>>> ```
>>>>>> 
>>>>>> Why is memory footprint of the same program in similar environments so 
>>>>>> different? What factors might be contributing to this problem?
>>>>>> 
>>>>>> What did you expect to see?
>>>>>> 
>>>>>> I would expect to see the memory footprint of the same program in 
>>>>>> similar environments be close. I look forward to your answers. Thank you 
>>>>>> very much.
>>> 
>> 
>>> -- 
>>> 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/d8a3e1d9-e578-4668-9b19-38b49e29cd11n%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/c524a157-7772-4bcd-9ce5-c04b95fb560en%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/1A6B3DA4-5AAA-407E-81A7-BA36F9F0EBBF%40ix.netcom.com.

Reply via email to