I cannot say what the difference is, but I would do two things to solve the mystery:
1) Compare /proc/<pid>/limits for differences. 2) Compare the output of egrep '^Rss:|^[0-9a-f]' /proc/<pid>/smaps for the processes on the different machines. Report the results and share the outputs. On Friday, May 6, 2022 at 2:16:51 PM UTC+2 ren...@ix.netcom.com wrote: > https://www.arp242.net/static-go.html > > On May 5, 2022, at 11:27 PM, garenchan <garen...@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 >> >> <https://groups.google.com/d/msgid/golang-nuts/d8a3e1d9-e578-4668-9b19-38b49e29cd11n%40googlegroups.com?utm_medium=email&utm_source=footer> >> . >> >> -- > 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/c524a157-7772-4bcd-9ce5-c04b95fb560en%40googlegroups.com > > <https://groups.google.com/d/msgid/golang-nuts/c524a157-7772-4bcd-9ce5-c04b95fb560en%40googlegroups.com?utm_medium=email&utm_source=footer> > . > > -- 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/594408e5-769a-45c5-acb4-f3c6792a1fabn%40googlegroups.com.
