我正在调查为什么我们的两个进程被 Linux OOM 杀手杀死 - 尽管似乎有足够的 RAM 和大量可用的 SWAP。
当我通过这个答案解释它时，第一个内存请求要求 2^2=4 页（16KB）的内存（顺序标志）并希望它来自“正常”区域。
Jan 27 04:26:14 kernel: [639964.652706] java invoked oom-killer: gfp_mask=0x26000c0, order=2, oom_score_adj=0
如果我正确解析输出，就会有足够的空间：
Node 0 Normal free:178144kB min:55068kB low:68832kB high:82600kB
几分钟后第二次有同样的请求——而且似乎也有足够的可用空间。
为什么当时触发了OOM杀手？我解析的信息有误吗？
vm.overcommit_memory设置设置为“0”（启发式），这可能不是最佳的。实例一：
Jan 27 04:26:14 kernel: [639964.652706] java invoked oom-killer: gfp_mask=0x26000c0, order=2, oom_score_adj=0
Jan 27 04:26:14 kernel: [639964.652711] java cpuset=/ mems_allowed=0
Jan 27 04:26:14 kernel: [639964.652716] CPU: 5 PID: 2152 Comm: java Not tainted 4.4.0-59-generic …我最近遇到了某种安全设备 (BlueCoat)，它要求所有到 Internet 的连接都必须通过它进行代理（你好，中间人），因此使用特殊的 SSL 证书来拦截所有流量。
这阻止了 Git 的正常操作，即使设置了适当的http.proxy和http.sslCAInfo属性以确保 SSL 连接本身有效。
使用环境变量GIT_CURL_VERBOSE=1，我们发现在使用时git clone，会出现HTTP 407（需要代理认证）。Git 正确完成此身份验证，最后，设备返回带有 cookie 标头的 HTTP 200 Set-Cookie。
Git 然后将连接到目标服务器，但没有cookie，导致 HTTP 401。
解决这个问题的方法是设置git配置选项 http.saveCookies=true
问题： 中间代理添加cookies真的是RFC标准允许的吗？
Anthony Rich向 http-state 邮件列表提出了同样的问题，但没有任何回应。他确实注意到在
RFC 2965 HTTP 状态管理机制，3.5 缓存代理角色它说：代理不得在代理响应（请求）中引入自己的 Set-Cookie2 (Cookie) 标头。
但是，取代的 RFC 6265根本不再提及这一点。