这段代码非常简单，就是先用mmap的方式，为该进程分配10GiB的虚拟内存，然后再用page写的方式，让操作系统为这10GiB虚拟内存，分配对应的物理内存，最后sleep，等待我们测试。
今天要探讨的是最近不知道为什么突然间火起来的面试题：当JAVA程序出现OOM之后，程序还能正常被访问吗？答案是可以的，很多时候他并不会直接导致程序崩溃，而是JVM会抛出一个error，告知你程序内存溢出了。当然也要分操作系统。
The OOM Killer 是内核中的一个进程，当系统出现严重内存不足时，它就会启用自己的算法去选择某一个进程并杀掉. 之所以会发生这种情况，是因为Linux内核在给某个进程分配内存时，会比进程申请的内存多分配一些. 这是为了保证进程在真正使用的时候有足够的内存，因为进程在申请内存后并不一定立即使用，当真正使用的时候，可能部分内存已经被回收了。
问题背景：一次启动本地应用，两分钟过后自动退出，通过日志并未发现任何异常状况，莫名其妙的应用就自动被杀掉了；
那个傻子是不是疯了？不知道作为所谓的“技术”人员，大家是如何面对的，如何解决？本文将聚焦于 Linux 内存结构、内存分析以及 OOM killer 等 3 个方面以及笔者多年的实践经验总结进行“吹牛逼”，当然，若吹的不好，欢迎大家扔砖、鸡蛋。
Linux 内核有个机制叫OOM killer（Out-Of-Memory killer），该机制会监控那些占用内存过大，尤其是瞬间很快消耗大量内存的进程，为了防止内存耗尽而内核会把该进程杀掉。
当系统内存不足时，Linux内核会触发OOM来选择一些进程kill掉，以便能回收一些内存，尽量继续保持系统继续运行。具体选择哪个进程杀掉，这有一套算分的策略，参考因子是进程占用的内存数，进程页表占用的内存数等，oom_score_adj的值越小，进程得分越少，也就越难被杀掉，oom_score_adj的取值为[-1000,1000]
最近线上遇到了好几次由于内存泄漏导致OOM的问题，且大部分都是整个模块被kill掉woker进程，只剩下接入的epoll进程和统计进程的情况，从而导致拨测程序在没有做逻辑拨测的情况下，不会重新拉起程序，导致机器无法服务。
Linux alarm 2.6.9-67.ELsmp #1 SMP Wed Nov 7 13:58:04 EST 2007 i686 i686 i386
这件事是真实的发送在我们的生产环境上，其中的一台服务器上跑着 4 个 jar 程序，隔三差五的会发送进程突然消失的问题。
业务在上容器云的过程中发现容器不知原因被重建,查看message信息可以看到当 oom_score_adj配置为1，对应score值为0的进程杀完后如果系统还是触发oom时就开始杀pause进程。
本文是描述Linux virtual memory运行参数的第二篇，主要是讲OOM相关的参数的。为了理解OOM参数，第二章简单的描述什么是OOM。如果这个名词对你毫无压力，你可以直接进入第三章，这一章是描述具体的参数的，除了描述具体的参数，我们引用了一些具体的内核代码，本文的代码来自4.0内核，如果有兴趣，可以结合代码阅读，为了缩减篇幅，文章中的代码都是删减版本的。按照惯例，最后一章是参考文献，本文的参考文献都是来自linux内核的Documentation目录，该目录下有大量的文档可以参考，每一篇都值得细细品味。
这个标题很吸引眼球实际上内容也应该很好玩. 问题的产生是最近我们在各个数据库进行数据库安装规范的事情,而在规范后,安装的第一台机器,进行压测就惨遭崩溃.
有时候我们会发现系统中某个进程会突然挂掉，通过查看系统日志发现是由于 OOM机制 导致进程被杀掉。
原文：http://blog.csdn.net/guomsh/article/details/6536915
QOS是K8S中的一种资源保护机制，其主要是针对不可压缩资源比如内存的一种控制技术。比如在内存中，其通过为不同的Pod和容器构造OOM评分，并且通过内核策略的辅助，从而实现当节点内存资源不足的时候，内核可以按照策略的优先级，优先kill掉那些优先级比较低（分值越高，优先级越低）的Pod。
Open Container Initiative(OCI)目前有2个标准：runtime-spec以及image-spec。前者规定了如何运行解压过的filesystem bundle。OCI规定了如何下载OCI镜像并解压到OCI filesystem bundle，这样OCI runtime就可以运行OCI bundle了。OCI(当前)相当于规定了容器的images和runtime的协议，只要实现了OCI的容器就可以实现其兼容性和可移植性。implements中列出了部分OCI标准的实现。本文不讨论windows下的实现，具体参见Open Container Initiative Runtime Specification
最近看了一篇文章：Tracking Down “Invisible” OOM Kills in Kubernetes，其讲述的是由于内存不足导致Pod中的进程被killed，但Pod并没有重启，也没有任何日志或kubernetes事件，只有一个"Exit Code: 137"的信息，导致难以进一步定位问题。最后还是通过查看节点系统日志才发现如下信息：
本来，写了个智能抠图的接口，本地运行正常，结果部署到服务器，发现，各种失败或服务器错误，查看log日志发现是本kill了
Linux系统内存管理中存在着一个称之为OOM killer（Out-Of-Memory killer）的机制，该机制主要用于内存监控，监控进程的内存使用量，当系统的内存耗尽时，其将根据算法选择性地kill了部分进程。本文分析的内存溢出保护机制，也就是OOM killer机制了。
Android底层还是基于Linux，在Linux中低内存是会有oom killer去杀掉一些进程去释放内存，而Android中的lowmemorykiller就是在此基础上做了一些调整来的。因为手机上的内存毕竟比较有限，而Android中APP在不使用之后并不是马上被杀掉，虽然上层ActivityManagerService中也有很多关于进程的调度以及杀进程的手段，但是毕竟还需要考虑手机剩余内存的实际情况，
oom_killer（out of memory killer）是Linux内核的一种内存管理机制，在系统可用内存较少的情况下，内核为保证系统还能够继续运行下去，会选择杀掉一些进程释放掉一些内存。通常oom_killer的触发流程是：进程A想要分配物理内存（通常是当进程真正去读写一块内核已经“分配”给它的内存）->触发缺页异常->内核去分配物理内存->物理内存不够了，触发OOM。
Linux开发一般会遇到“/proc/sys/vm/overcommit_memory”，即文件/etc/sysctl.conf中的vm.overcommit_memory，Overcommit的意思如同其字面意思，即进程可申请超出可用内存大小的内存（对进程而言实为虚拟内存，一个进程占用的虚拟内存空间通常比物理空间要大，甚至可能大许多）。overcommit_memory有三种取值（注：overcommit_memory并不控制OOM，是否开启OOM由panic_on_oom控制）：
研究过Kubernetes Resource QoS的同学，肯定会有一个疑问：QoS中会通过Pod QoS和OOM Killer进行资源的回收，当发生资源紧缺的时候。那为什么Kubernetes会再搞一个Kubelet Eviction机制，来做几乎同样的事呢？ 首先，我们来谈一下kubelet通过OOM Killer来回收资源的缺点： System OOM events本来就是对资源敏感的，它会stall这个Node直到完成了OOM Killing Process。 当OOM Killer干掉某些cont
现在越来越多应用云原生化跑在k8s上面，k8s为应用提供了自动限制、自动重启、服务发现等各种能力。这些能力让开发减少了对运维相关属性的关注，但也让一些开发把一些错误当成了特性来使用，比如针对一些无状态的服务，利用 OOM 和自动重启来恢复。这看起来大多数时候似乎没有问题，借助自动恢复，OOM的应用会被重新来起来工作。但这种坏习惯会让系统在某些时候变得更不稳定，比如 OOM Killer 导致的死锁问题。
在对MySQL 8.0.26 vs GreatSQL 8.0.25的对比测试过程中，有一个环节是人为制造磁盘满的场景，看看MGR是否还能正常响应请求。
作者简介：许庆伟，Linux Kernel Security Researcher & Performance Developer 众所周知，Linux内核和CPU处理器负责将虚拟内存映射到物理内存。为了提高效率，在一个称为页的内存组中创建一个内存映射，其中每个页的大小根据处理器的实际情况而来。尽管大多数处理器也支持更大的页，但默认通常是4 KB,。内核可以从页空闲列表中为物理内存页的申请提供分配，并且为了提高效率，为每个DRAM组和CPU均设计了维护这些请求的方案。内核程序可以通过分配器(比如slab分配
http://xjjdog.cn 对200+原创文章进行了细致的分类，阅读更流畅，欢迎收藏。
从 Linux 内核 2.6.25 开始，CGroup 支持对进程内存的隔离和限制，这也是 Docker 等容器技术的底层支撑。
Postgresql 需要打开和关闭，一般我们都使用 pg_ctl 命令来进行，实际上一般我们的LINUX 上的系统的一般是可以通过 systemctl 的方式来启动和关闭以及操纵一些相关的功能。
值此七夕佳节，烟哥放弃了无数妹纸的邀约，坐在电脑面前码字，就是为了给读者带来新的知识，这是一件伟大的事业！ 好吧，实际情况是没人约。为了化解尴尬，我决定卖力写文章，嗯，一定是我过于屌丝！ 好了，开始说重点。今天讲的这个问题
包含一个标志（0或1）来开启或者关闭cgroup的OOM killer。如果开启（1），任务如果尝试申请内存超过允许，就会被系统OOM killer终止。OOM killer在每个使用cgroup内存子系统中都是默认开启的。如果需要关闭，则可以向memory.oom_control文件写入1.
默认情况下，一个容器是没有任何资源限制的，它能够耗尽当前主机内核能够调度给容器的所有资源，就像拥有饥饿者能力的猪头帝一样，永远吃不饱。这显然是不合理的，因为资源吃多了会被制裁的。在 linux 系统中，如果内核探测到当前主机已经没有可用的内存分配给某些重要的系统进程，它就会启动 OOM killer 或者触发 kernel panic，详情请查看另一篇文章Linux OOM killer。OOM killer 会杀死符合条件的进程，docker daemon 也有可能会被 kill。为此 docker 调整了 docker daemon 的 OOM 优先级，但是 docker container的优先级没有被调整啊，怎么办？小场面，道友慢慢听我道来。
不允许容器消耗宿主机太多的内存是非常重要的。在 Linux 主机上，如果内核检测到没有足够的内存来执行重要的系统功能，它会抛出 OOME 或 Out of Memory 异常，并开始终止进程以释放内存。任何进程都会被杀死，包括 Docker 和其他重要的应用程序。如果杀错进程，可能导致整个系统瘫痪。
最近加群的人太多了，可能是因为这篇 Peace and love，从今天开始我们群正式加入 ORACLE ，因为群里的ORACLE 大佬也很多，所以基本上市面上能见到的常见的数据库产品，群里都有大佬和各种厂商，和工作者，我们准备把 Peace and love 发扬光大，都是数据库，大家一起学。
在使用 docker 运行容器时，默认的情况下，docker没有对容器进行硬件资源的限制，当一台主机上运行几百个容器，这些容器虽然互相隔离，但是底层却使用着相同的 CPU、内存和磁盘资源。如果不对容器使用的资源进行限制，那么容器之间会互相影响，小的来说会导致容器资源使用不公平；大的来说，可能会导致主机和集群资源耗尽，服务完全不可用。
之前文章《Linux服务器性能评估与优化(一)》太长，阅读不方便，因此拆分成系列博文：
业务进程异常停止或重启，可以根据 /var/log/messages 日志判断是否发生OOM，如果是，又是什么进程占用了大量内存空间触发 OOM Killer
今天对一个pod进行内存资源调整后, 一直卡在ContainerCreating的状态, 执行describe命令查看该 Pod 详细信息后发现如下 。
内核和处理器负责将虚拟内存映射到物理内存。为了提高效率，会在称为页面的内存组中创建内存映射，其中每个页面的大小是处理器的详细信息。尽管大多数处理器也支持更大的容量，但通常有4 KB，Linux称其为 hugepage大页面。内核可以从其自己的空闲列表中为物理内存页面请求提供服务，内核为每个DRAM组和CPU维护这些请求以提高效率。内核自己的软件也通常通过内核分配器(例如slab分配器)从这些空闲列表中消耗内存。
Perfetto 是一个用于性能检测和跟踪分析的生产级开源堆栈。它提供用于记录系统级和应用程序级跟踪的服务和库、本机 + java 堆分析、使用 SQL 分析跟踪的库以及用于可视化和探索多 GB 跟踪的基于 Web 的 UI。
在启动一个Springboot工程时，抛出一项“Cannot allocate memory”异常，很明显，是因为内存分配原因导致的OOM异常导致JVM宕掉。跟随log，查看JVM hs_err_pid24442.log文件。
为什么使用容器 docker设计目标: 提供简单的应用打包工具 开发人员和运维人员职责逻辑分离 多环境保持一致性 轻量级 kubernetes设计目标: 集中管理所有容器 资源编排 资源调度 弹性伸缩 资源隔离 容器与虚拟机 [image-20200308101459743.png] 虚拟机比容器多了一层完整的os系统 docker寄居于底层系统之上,能够节省资源开销. [image-20200308103159625.png] docker的资源隔离和网络限制 1. namespace 实现了资源的隔
1.Out of swap space：该错误表示所有可用的虚拟内存已被耗尽。虚拟内存（Virtual Memory）由物理内存（Physical Memory）和交换空间（Swap Space）两部分组成。当运行时程序请求的虚拟内存溢出时就会报 Outof swap space 错误。
最近总有开发小伙伴来找我，为什么我的容器总退出呢，在哪能看到原因。故写篇文章整理下docker退出的状态码。
Docker 上手很容易，但如果将其应用于生产环境，则需要对它有更深入的理解。只有这样，才能确保应用符合我们的预期，或在遇到问题时可及时解决。所以，要想真正掌握 Docker 的核心知识，只靠网络上零散的信息往往是不够的，必须系统性地学习。
问题 最近总有开发小伙伴来找我，为什么我的容器总退出呢，在哪能看到原因。故写篇文章整理下docker退出的状态码。
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
ICP备案
对象存储
即时通信 IM
实时音视频
