Golang linux RSS 显示的字节数比 pprof 运行时的字节数多。MemStats
我有一个套接字客户端 Golang 程序。刚启动时，Linux /proc/PID/status 显示进程 RSS 为 15204 kB，但 pprof 报告显示 HeapAlloc 约为 1408 kB，存在约 14000kB 的差距。 我的问题：
1、为什么差别这么大？
2、Go应用内存是如何分配的？除了堆和栈之外，还有其他内存区域吗？我怎样才能找到这些区域？
3、更重要的是，如何降低它的RSS？
cat /proc/PID/status:
Umask: 0000
State: S (sleeping)
Tgid: 3393
Ngid: 0
Pid: 3393
PPid: 2882
TracerPid: 0
Uid: 500 500 500 500
Gid: 500 500 500 500
FDSize: 32
Groups: 500
NStgid: 3393
NSpid: 3393
NSpgid: 2881
NSsid: 2881
VmPeak: 806492 kB
VmSize: 806492 kB
VmLck: 0 kB
VmPin: 0 kB
VmHWM: 15204 kB
VmRSS: 15204 kB
RssAnon: 5024 kB
RssFile: 10180 kB
RssShmem: 0 kB
VmData: 10988 kB
VmStk: 132 kB
VmExe: 5164 kB
VmLib: 8 kB
VmPTE: 28 kB
VmPMD: 0 kB
VmSwap: 0 kB
Threads: 6
SigQ: 0/937
SigPnd: 0000000000000000
ShdPnd: 0000000000000000
SigBlk: 0000000000000000
SigIgn: 0000000000000001
SigCgt: fffffffe7fc1fefe
CapInh: 0000000000000000
CapPrm: 0000000000000000
CapEff: 0000000000000000
CapBnd: 0000003fffffffff
CapAmb: 0000000000000000
Cpus_allowed: 3
Cpus_allowed_list: 0-1
voluntary_ctxt_switches: 261951
nonvoluntary_ctxt_switches: 21327
go tool pprof 堆:
# runtime.MemStats
# Alloc = 1408048
# TotalAlloc = 45071968
# Sys = 10828924
# Lookups = 0
# Mallocs = 889174
# Frees = 885421
# HeapAlloc = 1408048
# HeapSys = 7929856
# HeapIdle = 5677056
# HeapInuse = 2252800
# HeapReleased = 5480448
# HeapObjects = 3753
# Stack = 458752 / 458752
# MSpan = 25120 / 32768
# MCache = 1736 / 16384
# BuckHashSys = 725549
# GCSys = 886912
# OtherSys = 778703
# NextGC = 4194304
# LastGC = 1645757614280889245
I have a socket client Golang program. when it just start up, Linux /proc/PID/status show the process RSS is 15204 kB, but the pprof report shows that HeapAlloc is about 1408 kB, there is a gap of about 14000kB.
My Questions:
1、Why is there such a big difference?
2、How is the go application memory distributed? Besides heap and stack, are there other memory areas? and how can I find these areas?
3、More importantly, how can I lower its rss?
cat /proc/PID/status:
Umask: 0000
State: S (sleeping)
Tgid: 3393
Ngid: 0
Pid: 3393
PPid: 2882
TracerPid: 0
Uid: 500 500 500 500
Gid: 500 500 500 500
FDSize: 32
Groups: 500
NStgid: 3393
NSpid: 3393
NSpgid: 2881
NSsid: 2881
VmPeak: 806492 kB
VmSize: 806492 kB
VmLck: 0 kB
VmPin: 0 kB
VmHWM: 15204 kB
VmRSS: 15204 kB
RssAnon: 5024 kB
RssFile: 10180 kB
RssShmem: 0 kB
VmData: 10988 kB
VmStk: 132 kB
VmExe: 5164 kB
VmLib: 8 kB
VmPTE: 28 kB
VmPMD: 0 kB
VmSwap: 0 kB
Threads: 6
SigQ: 0/937
SigPnd: 0000000000000000
ShdPnd: 0000000000000000
SigBlk: 0000000000000000
SigIgn: 0000000000000001
SigCgt: fffffffe7fc1fefe
CapInh: 0000000000000000
CapPrm: 0000000000000000
CapEff: 0000000000000000
CapBnd: 0000003fffffffff
CapAmb: 0000000000000000
Cpus_allowed: 3
Cpus_allowed_list: 0-1
voluntary_ctxt_switches: 261951
nonvoluntary_ctxt_switches: 21327
go tool pprof heap:
# runtime.MemStats
# Alloc = 1408048
# TotalAlloc = 45071968
# Sys = 10828924
# Lookups = 0
# Mallocs = 889174
# Frees = 885421
# HeapAlloc = 1408048
# HeapSys = 7929856
# HeapIdle = 5677056
# HeapInuse = 2252800
# HeapReleased = 5480448
# HeapObjects = 3753
# Stack = 458752 / 458752
# MSpan = 25120 / 32768
# MCache = 1736 / 16384
# BuckHashSys = 725549
# GCSys = 886912
# OtherSys = 778703
# NextGC = 4194304
# LastGC = 1645757614280889245
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
这是两个不同的指标。人们所说的“内存消耗”是
在现代机器上定义都非常困难。
这是一个实施细节，并且有所不同。这里没有什么可操作的。
“除了堆和栈之外，还有其他内存区域吗？”
不，但请注意，堆/堆栈二分法是某个（尽管常见）编译器/编译器版本/系统组合的实现细节。
“我怎样才能找到这些区域？”你不能。
通过减少分配的内存量。但请注意，降低 RSS 很可能根本不需要。您可能高估了“大”RSS 的“问题”程度。
These are two different metrics. What people call "memory consumption" is
incredibly hard to even define on modern machines.
This is an implementation detail and varies. Nothing actuable to know here.
"Besides heap and stack, are there other memory areas?"
No, but note that the heap/stack dichotomy is an implementation detail of a certain (albeit common) compiler/compiler version/system combination.
"and how can I find these areas?" You cannot.
By reducing how much memory you allocate. But note that lowering RSS most probably simply isn't needed. You probably overestimate how "problematic" a "large" RSS is.