You can tune the MHeapMap_Bits in malloc.h and arena_size in malloc.goc to reducememory usage, as long as they statisfy this:(1UL << (12 + MHeapMap_Bits)) >= arena_size(for example, I changed MHeapMap_Bits to 20, and arena_size to ”4LL<<30“, all testspassed, and the size of bss sections is dropped to about 10MB for bin/go:linux-amd64 go $ size bin/go # before text data bss dec hex filename4491897 97552
33672424 38261873 247d471 bin/golinux-amd64 go $ size bin/go # after text data bss dec hex filename4491924 97552
8506600 13096076 c7d48c bin/go)
And for the record, this problem is not caused by the reserved VM space (which is 16GBon 64-bit hosts, as they are mapped with PROT_NONE, i.e., they won't map to any physicalmemory). Its real cause is the big runtime.mheap.
$ vi malloc.hMHeapMap_Bits=16
$ vi malloc.gocarena_size=1LL<<28
$ go install -a -v stdThen rebuilt my app which reduce its VPS footprint from 60MB to 20MB!!!
Previously:MHeapMap_Bits=19arena_size=1LL<<28reduced the footprint to 24MB, so I imagine going lower has diminishing returns.
I can't help but wonder, if the memory usage is a bug, or whether these memory settings should be made available as flags in go build, or sometime in the future, the runtime will probably be improved to make good choices automatically. Is it worth putting in a feature request/bug report?
Given that the apps RSS is 2.5MB, I'm thinking the total footprint should be around 5-10MB? If so, there's probably more work to do and I would be happy to test.
However, knocking off ~70% of the ram requirements is absolutely fantastic, so thanks everyone for your time and helpful suggestions.
Cheers.
