摘自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
33672424 38261873 247d471 bin/go
linux-amd64 go $ size bin/go # after
text
data
bss
dec
hex
filename
4491924
97552
8506600 13096076 c7d48c 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.
有疑问加站长微信联系（非本文作者）
