htop和golang readmemstats之间的差异

Question

我的程序在启动时加载了大量数据，然后调用debug.FreeOSMemory（），以便立即返回任何额外的空间。

loadDataIntoMem()
debug.FreeOSMemory()

加载到内存后，htop显示了以下过程

 VIRT    RES     SHR
 11.6G   7629M   8000

但是对runtime.ReadMemStats的调用显示了以下内容

Alloc         5593336608   5.3G
BuckHashSys   1574016      1.6M
HeapAlloc     5593336610   5.3G
HeapIdle      2607980544   2.5G
HeapInuse     7062446080   6.6G
HeapReleased  2607980544   2.5G
HeapSys       9670426624   9.1G
MCacheInuse   9600         9.4K
MCacheSys     16384        16K
MSpanInuse    106776176    102M
MSpanSys      115785728    111M
OtherSys      25638523     25M
StackInuse    589824       576K
StackSys      589824       576K
Sys           10426738360  9.8G
TotalAlloc    50754542056  48G

1. Alloc是从系统获得但尚未释放的数量（这是 居民记忆吧？）但两者之间存在很大差异。
2. 我依靠HeapIdle杀死我的程序，即如果HeapIdle超过2 GB，重新启动 - 在这种情况下它是2.5，并且即使在一段时间后也不会停止。 Golang在将来分配更多时应该从堆空闲中使用，从而减少堆空闲权吗？
3. 如果假设1错误，哪个stat可以准确地告诉我htop中的RES值是什么。
4. 如何降低HeapIdle的值？

这是在1.4.2,1.5.2和1.6.beta1

上试过的

Answer 1

程序的有效内存消耗为Sys-HeapReleased。这仍然不是操作系统报告的内容，因为操作系统可以根据程序的请求选择分配内存的方式。

如果您的程序运行了相当长的时间，超出的内存将提供给操作系统，因此无需拨打debug.FreeOSMemory()。保持内存尽可能低也不是垃圾收集器的工作;目标是尽可能有效地使用内存。这需要一些开销，并为将来的分配留出空间。

如果您在使用内存方面遇到问题，那么分析您的程序并查看为什么要分配的内容超出预期会更高效，而不是基于对内存的错误假设来杀死您的进程。