- 问题现象：
（1） 设备接入BBC（集中管理平台，会占用很大的虚拟内存空间）用top查看到系统free还有100多MB，此时启动golang程序会出现 out of memory.
（2） 设备不接入BBC，用top查看到系统free还有100多MB，此时启动golang程序成功（启动后的golang会占用10MB的物理内存）
疑问：
为什么free值差不多，并且剩余的值远大于golang程序启动需要的值，还会出现out of memory呢？
猜测：
（1） 是否是系统要预留了一部分内存，启动BBC之后再启动golang程序会导致剩余内存小于系统预留值，而导致分配内存失败呢？
验证：
用C语言写一个需要申请10MB物理内存的程序，看是否能否在设备接入BBC之后再启动。
结果：
能够启动。说明golang程序启动不了跟申请的物理内存大小无关。
（2） golang程序启动时会占用超大虚拟内存空间，是否跟系统的虚拟内存分配策略有关？
验证：系统虚拟内存分配策略跟overcommit_memory有关，原先设备的值为0，限制修改overcommit_memory的值，把值从0改为1.
结果：
设备接入BBC之后还能启动golang程序。说明golang程序启动不了跟设备系统的虚拟内存分配策略有关。启动BBC后再启动golang程序触发了CommitLimit，导致内存分配失败。
分析：
关于overcommit_memory说明：
取值为0，表示内核将检查是否有足够的可用内存供应用进程使用；如果有足够的可用内存，内存申请允许；否则，内存申请失败，并把错误返回给应用进程。系统在为应用程序分配虚拟地址空间时，会判断当前申请的虚拟地址空间大小是否超过剩余内存大小。如果超过，则虚拟地址空间分配失败。因此，也就是如果进程本身占用的虚拟地址空间比较大或者剩余内存比较小时，fork、malloc等调用可能会失败。
取值为1，表示内核允许分配所有的物理内存，而不管当前的内存状态如何。系统在为应用程序分配虚拟空间时，完全不进行限制，这种情况下，避免了fork可能产生的失败，但由于malloc是先分配虚拟地址空间，在内存不足的情况下，这相当于完全屏蔽了应用程序对系统内存状态的感知，即malloc总是能成功，一旦内存不足，会引起系统OOM杀进程，应用程序对于这种后果是无法预测的。
取值为2，表示内核允许分配超过所有物理内存和交换空间总和的内存。是根据系统内存状态确定了虚拟内存地址空间的上限，由于很多情况下，进程的虚拟地址空间占用远大于其实际占用的物理内存，这样一旦内存使用量上去以后，对于一些动态产生的进程（需要复制父进程地址空间）则很容易创建失败，如果业务过程没有过多的这种动态申请内存或者创建子进程，则影响不大，否在会产生比较大的影响。
综上：
最后把设备的overcommit_memory改为1，理由是：
（1）如果overcommit_memory为0的话, overcommit_ratio不启用的。
（2）如果overcommit_memory为2的话，因为程序占用的虚拟内存是远大于物理内存的，我们也无法在事前估算程序所占的虚拟内存，如果提前设置好一个值，那么还是会出现内存有剩余但是out of memory，那么本质的问题还是未能解决。
（3）如果overcommit_memory 为1的话可能会触发OOM（有策略的杀掉用户进程）,但这也是系统的一种保护机制，防止设备挂掉。
（4）另外虚拟内存又不值钱，该用多少就用多少。
overcommit_ratio是什么？
当overcommit_memory=2的时候，它一般是代表的是系统中总的内存的百分比
虚拟内存CommitLimit计算：
CommitLimit = SwapTotal + MemTotal * overcommit_ratio
总的虚拟内存 = 总的交换分区 + 总的物理内存 * overcommit_ratio
这些信息可以到cat /proc/meminfo中看到， 可以通过上述的计算公式可以计算就可以获得系统的CommitLimit的值
解决方法：
很简单，按提示的操作（将vm.overcommit_memory 设为1）即可：
有三种方式修改内核参数，但要有root权限：
（1）编辑/etc/sysctl.conf ，改vm.overcommit_memory=1，然后sysctl -p使配置文件生效
（2）sysctl vm.overcommit_memory=1
（3）echo 1 > /proc/sys/vm/overcommit_memory