这段代码非常简单，就是先用mmap的方式，为该进程分配10GiB的虚拟内存，然后再用page写的方式，让操作系统为这10GiB虚拟内存，分配对应的物理内存，最后sleep，等待我们测试。
今天要探讨的是最近不知道为什么突然间火起来的面试题：当JAVA程序出现OOM之后，程序还能正常被访问吗？答案是可以的，很多时候他并不会直接导致程序崩溃，而是JVM会抛出一个error，告知你程序内存溢出了。当然也要分操作系统。
Linux内核有个机制叫OOM killer（Out-Of-Memory killer），该机制会监控那些占用内存过大，尤其是瞬间很快消耗大量内存的进程，为了防止内存耗尽,内核会把该进程杀掉，监控是正常的。 防止重要的系统进程触发(OOM)机制而被杀死：可以设置参数/proc/PID/oom_adj为-17，临时关闭linux内核的OOM机制。
Linux内核给每个进程都提供了一个独立的虚拟地址空间，并且这个地址空间是连续的。Linux的空间又分为内核空间和用户空间，在32位中，内核空间占1G，用户空间占3G；而在64位中，内核空间和用户空间各占128T。如图3-24所示。
那个傻子是不是疯了？不知道作为所谓的“技术”人员，大家是如何面对的，如何解决？本文将聚焦于 Linux 内存结构、内存分析以及 OOM killer 等 3 个方面以及笔者多年的实践经验总结进行“吹牛逼”，当然，若吹的不好，欢迎大家扔砖、鸡蛋。
Linux 内核有个机制叫OOM killer（Out-Of-Memory killer），该机制会监控那些占用内存过大，尤其是瞬间很快消耗大量内存的进程，为了防止内存耗尽而内核会把该进程杀掉。
这件事是真实的发送在我们的生产环境上，其中的一台服务器上跑着 4 个 jar 程序，隔三差五的会发送进程突然消失的问题。
The OOM Killer 是内核中的一个进程，当系统出现严重内存不足时，它就会启用自己的算法去选择某一个进程并杀掉. 之所以会发生这种情况，是因为Linux内核在给某个进程分配内存时，会比进程申请的内存多分配一些. 这是为了保证进程在真正使用的时候有足够的内存，因为进程在申请内存后并不一定立即使用，当真正使用的时候，可能部分内存已经被回收了。
值此七夕佳节，烟哥放弃了无数妹纸的邀约，坐在电脑面前码字，就是为了给读者带来新的知识，这是一件伟大的事业！ 好吧，实际情况是没人约。为了化解尴尬，我决定卖力写文章，嗯，一定是我过于屌丝！ 好了，开始说重点。今天讲的这个问题
问题背景：一次启动本地应用，两分钟过后自动退出，通过日志并未发现任何异常状况，莫名其妙的应用就自动被杀掉了；
本文是描述Linux virtual memory运行参数的第二篇，主要是讲OOM相关的参数的。为了理解OOM参数，第二章简单的描述什么是OOM。如果这个名词对你毫无压力，你可以直接进入第三章，这一章是描述具体的参数的，除了描述具体的参数，我们引用了一些具体的内核代码，本文的代码来自4.0内核，如果有兴趣，可以结合代码阅读，为了缩减篇幅，文章中的代码都是删减版本的。按照惯例，最后一章是参考文献，本文的参考文献都是来自linux内核的Documentation目录，该目录下有大量的文档可以参考，每一篇都值得细细品味。
https://www.cnblogs.com/poloyy/category/1806772.html
Linux alarm 2.6.9-67.ELsmp #1 SMP Wed Nov 7 13:58:04 EST 2007 i686 i686 i386
作者简介：许庆伟，Linux Kernel Security Researcher & Performance Developer 众所周知，Linux内核和CPU处理器负责将虚拟内存映射到物理内存。为了提高效率，在一个称为页的内存组中创建一个内存映射，其中每个页的大小根据处理器的实际情况而来。尽管大多数处理器也支持更大的页，但默认通常是4 KB,。内核可以从页空闲列表中为物理内存页的申请提供分配，并且为了提高效率，为每个DRAM组和CPU均设计了维护这些请求的方案。内核程序可以通过分配器(比如slab分配
Linux内核涉及进程和程序的所有算法都围绕一个名为task_struct的数据结构建立，该结构定义在/usr/include/sched.h中;task_struct数据结构提供了两个链表表头，用于实现进程家族关系;
内核和处理器负责将虚拟内存映射到物理内存。为了提高效率，会在称为页面的内存组中创建内存映射，其中每个页面的大小是处理器的详细信息。尽管大多数处理器也支持更大的容量，但通常有4 KB，Linux称其为 hugepage大页面。内核可以从其自己的空闲列表中为物理内存页面请求提供服务，内核为每个DRAM组和CPU维护这些请求以提高效率。内核自己的软件也通常通过内核分配器(例如slab分配器)从这些空闲列表中消耗内存。
之前文章《Linux服务器性能评估与优化(一)》太长，阅读不方便，因此拆分成系列博文：
原文：http://blog.csdn.net/guomsh/article/details/6536915
不允许容器消耗宿主机太多的内存是非常重要的。在 Linux 主机上，如果内核检测到没有足够的内存来执行重要的系统功能，它会抛出 OOME 或 Out of Memory 异常，并开始终止进程以释放内存。任何进程都会被杀死，包括 Docker 和其他重要的应用程序。如果杀错进程，可能导致整个系统瘫痪。
在启动一个Springboot工程时，抛出一项“Cannot allocate memory”异常，很明显，是因为内存分配原因导致的OOM异常导致JVM宕掉。跟随log，查看JVM hs_err_pid24442.log文件。
本文旨在介绍下几种常见的调试方法gdb、crash、kgdb and kdb 以及dynamic debug. 关于在 Linux 内核上使用debuggers，Linus Torvalds 长期以来对它们不太喜欢。简短地解释这种态度是，依赖调试器可能鼓励用权宜之计而非深思熟虑来解决问题，这会导致代码质量恶化。详细解释可以参考https://lwn.net/2000/0914/a/lt-debugger.php3
有时候我们会发现系统中某个进程会突然挂掉，通过查看系统日志发现是由于 OOM机制 导致进程被杀掉。
理解硬件访问内存的原理,MMU和页表；澄清Linux内核ZONE，buddy，slab管理；澄清用户空间malloc与内核关系，Lazy分配机制；澄清进程的内存消耗的vss,rss,pss,uss概念；澄清内存耗尽的OOM行为；澄清文件背景页面与匿名页，page cache与swap；澄清内存的回收、dirty page的写回，以及一些内存管理/proc/sys/vm sysctl配置的幕后原理；DMA和cache一致性，IOMMU等;给出一些内存相关的调试和优化方法；消除网上各种免费资料的各种误解。
查看系统日志，显示内存不足，杀死了一个java进程，可以推测，就是tomcat惨遭了毒手，
这些参数主要是用来调整virtual memory子系统的行为以及数据的写出（从RAM到ROM）。 这些节点（参数）的默认值和初始化的过程大部分都可以在mm/swap.c中找到。 目前，/proc/sys/vm目录下有下面这些节点：
通常来看，Redis开发和运维人员更加关注的是Redis本身的一些配置优化，例如AOF和RDB的配置优化、数据结构的配置优化等，但是对于操作系统是否需要针对Redis做一些配置优化不甚了解或者不太关心，然而事实证明一个良好的系统操作配置能够为Redis服务良好运行保驾护航。
现在越来越多应用云原生化跑在k8s上面，k8s为应用提供了自动限制、自动重启、服务发现等各种能力。这些能力让开发减少了对运维相关属性的关注，但也让一些开发把一些错误当成了特性来使用，比如针对一些无状态的服务，利用 OOM 和自动重启来恢复。这看起来大多数时候似乎没有问题，借助自动恢复，OOM的应用会被重新来起来工作。但这种坏习惯会让系统在某些时候变得更不稳定，比如 OOM Killer 导致的死锁问题。
所谓假死现象，是指 Linux 内核 Alive，但是其上的某个或所有操作的响应变得很慢的现象。
最近一台 CentOS 服务器，发现内存无端损失了许多，free 和 ps 统计的结果相差十几个G，非常奇怪，后来Google了许久才搞明白。
「 原谅和忘记就意味着扔掉了我们获得的最贵经验 -------《人生的智慧》叔本华」
PostgreSQL某些时候会耗尽操作系统的各种资源限制，当同一个系统上运行着多个拷贝的服务器或在一个非常大的安装中时尤其如此。本节解释了PostgreSQL使用的内核资源以及你可以采取的用于解决内核资源消耗相关问题的步骤。
在前面的文章Android进程保活一文中，对于LowMemoryKiller的概念做了简单的提及。LowMemoryKiller简称低内存杀死机制。简单来说，LowMemoryKiller(低内存杀手)是Andorid基于oomKiller原理所扩展的一个多层次oomKiller，OOMkiller(Out Of Memory Killer)是在Linux系统无法分配新内存的时候，选择性杀掉进程，到oom的时候，系统可能已经不太稳定，而LowMemoryKiller是一种根据内存阈值级别触发的内存回收的机制
KIND 是我一直参与，也日常一直在使用的项目，用于快速的在本地或者 CI 环境中启动 Kubernetes 集群。
第一个是在AmS中进行，即Android所声称的当系统内存低时，优先释放没有任何Activity的进程，然后释放非前台Activity对应的进程。
Perfetto 是一个用于性能检测和跟踪分析的生产级开源堆栈。它提供用于记录系统级和应用程序级跟踪的服务和库、本机 + java 堆分析、使用 SQL 分析跟踪的库以及用于可视化和探索多 GB 跟踪的基于 Web 的 UI。
业务在上容器云的过程中发现容器不知原因被重建,查看message信息可以看到当 oom_score_adj配置为1，对应score值为0的进程杀完后如果系统还是触发oom时就开始杀pause进程。
先来说说第一个问题：虚拟内存有什么作用？（如果你还不知道虚拟内存概念，可以看这篇：真棒！20 张图揭开内存管理的迷雾，瞬间豁然开朗）
作者简介： 程磊，一线码农，在某手机公司担任系统开发工程师，日常喜欢研究内核基本原理。 1.1 内存管理的意义 1.2 原始内存管理 1.3 分段内存管理 1.4 分页内存管理 1.5 内存管理的目标 1.6 Linux内存管理体系 2.1 物理内存节点 2.2 物理内存区域 2.3 物理内存页面 2.4 物理内存模型 2.5 三级区划关系 3.1 Buddy System 3.1.1 伙伴系统的内存来源 3.1.2 伙伴系统的管理数据结构 3.1.3 伙伴系统的算法逻辑 3.1.4 伙伴系统的接口 3.1
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
也许你很少面临这一情况，但是一旦如此，你一定知道出什么错了：可用内存不足或者说内存用尽(OOM)。结果非常典型：你不能再分配内存，内核会杀掉一个任务(一般是正在运行那个)。一般半随着大量的交换读写，你可以从屏幕和磁盘动向看出来。
之前在实习时，听了 OOM 的分享之后，就对 Linux 内核内存管理充满兴趣，但是这块知识非常庞大，没有一定积累，不敢写下，担心误人子弟，所以经过一个一段时间的积累，对内核内存有一定了解之后，今天才写下这篇文章记录，分享。
本来，写了个智能抠图的接口，本地运行正常，结果部署到服务器，发现，各种失败或服务器错误，查看log日志发现是本kill了
在这篇文章中，我们将深入分析Kubernetes中的典型退出码127与137，解释它们是什么，K8s和Docker中常见的原因是什么，以及如何修复
在Android系统中，进程可以大致分为系统进程和应用进程两大类。
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
ICP备案
对象存储
即时通信 IM
实时音视频
