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.