摘自golang nut
You can tune the MHeapMap_Bits in malloc.h and arena_size in malloc.goc to reduce
memory 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 tests
passed,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 filename
4491897 97552 3367242438261873247d471 bin/go
linux-amd64 go $ size bin/go # after
4491924 97552 850660013096076c7d48c bin/go
)
And for the record,this problem is not caused by the reserved VM space (which is 16GB
on 64-bit hosts,as they are mapped with PROT_NONE,i.e.,they won't map to any physical
memory). Its real cause is the big runtime.mheap.
$ vi malloc.h
MHeapMap_Bits=16
$ vi malloc.goc
arena_size=1LL<<28
$ go install -a -v std
Then rebuilt my app which reduce its VPS footprint from 60MB to 20MB!!!
PrevIoUsly:
MHeapMap_Bits=19
arena_size=1LL<<28
reduced 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.
