使用huge page，可以在TLB容量固定的情况下，提高TLB的命中率，即便TLB miss，因为减少了页表级数，也可以减少查找页表的时间。在内存虚拟化中，由于地址转换需要的级数更多，huge page能发挥的作用就显得更为重要。
前言： 前文《[linux][redis]bgsave引起的latency突刺问题分析》分析了redis-server执行bgsave因为fork引起的latency突刺问题。 而在http://antirez.com/news/84中也提到了“However this is definitely not the full story”，剩下的story则是Linux的THP对redis的影响。 分析： 1，THP vs Normal page 配置了THP策略分别是always和never，redis-server和redis-benchmark配置相同的参数，执行bgsave的latency对比：
最近一直在做性能压测相关的事情，有公众号的读者朋友咨询有赞的数据库服务器有没有开启huge page，我听说过huge page会对性能有所提升，本文就一探究竟。对过程没有兴趣的可以直接看结论。
HugePage，就是指的大页内存管理方式。与传统的4kb的普通页管理方式相比，HugePage为管理大内存(8GB以上)更为高效。本文描述了什么是HugePage，以及HugePage的一些特性。
在《一文读懂 HugePages的原理》一文中介绍了 HugePages（大内存页）的原理和使用，现在我们来分析一下 Linux 内核是怎么实现 HugePages 分配的。
前面介绍了Oracle的基本参数，从这节开始讲其他的参数，参数从v$parameter中提取
Huge pages ( 标准大页 ) 和 Transparent Huge pages( 透明大页 )
Linux下的大页分为两种类型：标准大页（Huge Pages）和透明大页（Transparent Huge Pages）。
内核文档Documentation/arm64/memory.rst描述了ARM64 Linux内核空间的内存映射情况，应该是此方面最权威文档。
https://www.percona.com/blog/why-linux-hugepages-are-super-important-for-database-servers-a-case-with-postgresql/
用过不少种类的数据库的人会遇到一个问题, transparent Hugepages 在不少的数据库中都被提到 disabled, turn off . Why should we turn off
调用 mmap 系统调用 , 先检查 " 偏移 " 是否是 " 内存页大小 " 的 " 整数倍 " , 如果偏移是内存页大小的整数倍 , 则调用 sys_mmap_pgoff 函数 , 继续向下执行 ;
在博客 【Linux 内核 内存管理】虚拟地址空间布局架构 ⑦ ( vm_area_struct 结构体成员分析 | vm_start | vm_end | vm_next | vm_prev |vm_rb) 中 , 分析了 vm_start vm_end vm_next vm_prev vm_rb 这
处理大内存的性能关键计算应用程序工作集已经运行在libhugetlbfs之上，然后依次运行 hugetlbfs。透明的巨型页面支持是另一种使用大页为虚拟内存提供大页支持的方法， 该支持自动提升和降低页面大小和没有hugetlbfs的缺点。
以前经常遇到2C3G的vmware续集上环境上安装上vpp后，能直接运行，而每次当系统重启后总是报内存不足的问题。当把系统内存调整到4G后，就能正常运行了。一直也不清楚原因。最近工作中遇到一个问题在2c2g的环境上跑vpp，一段时间后，总是报内存不足。后来查询发现hugepage内存大小是1G，但是只使用了不到三分之一的大页内存。
· Ubuntu 14.04.4（3.13.0-100 Errata 47 patched kernel）
在介绍 HugePages 之前，我们先来回顾一下 Linux 下 虚拟内存 与 物理内存 之间的关系。
前言 前文《[linux][redis]bgsave引起的latency突刺问题分析》中记录了在执行bgsave的时候，因为fork子进程之后，会出现page fault导致了redis的延迟受到了影响。 前文《[THP][redis]THP对redis的影响》中分析了THP（transparent hugepage）对redis的延迟突刺的影响。 大约两年半以前，作者给redis提了PR(https://github.com/redis/redis/pull/5124)，但是maintainer并没有回复，一段时间后关闭。 几个月前，第二次提PR（https://github.com/redis/redis/pull/7381）希望解决这个问题，新任的maintainer Oran对THP问题比较感兴趣，同时也把三年多以前的另外一个PR（https://github.com/redis/redis/pull/4001）翻了出来。大约经过一周的讨论和修改，两个PR都已经合入了upstream。 分析 THP的内核逻辑 内核提供了THP开关可以控制，/sys/kernel/mm/transparent_hugepage/enabled，这个开关需要root权限，且是系统级别的影响。 always表示所有的进程都会被khugepaged扫描，尝试使用2M的透明大页。 madvise表示如果有进程调用了THP开关，则打开/关闭。 never表示khugepaged不会对任何进程生效，包括使用madvise的进程。 warning判断 redis的原有的逻辑是在启动阶段检查系统的THP配置，如果不是never，就会产生一个warning。redis自身并没有使用过madvise进行THP操作，即使使用了jemalloc，也不会对主要的内存进行THP操作。所以改成不是always就应该是安全的，所以，Oran接受了这个改动（https://github.com/redis/redis/pull/4001）。 关闭redis的进程THP 更加理想的做法是不管系统配置如何，redis都可以把自己进程的THP开关禁用掉，这样子不需要root权限控制，且不会影响其他的进程。Linux恰好提供了这样了一个syscall，所以在（https://github.com/redis/redis/pull/7381）中，会关闭掉。同时，根据Oran的意见，增加了配置项，在多数情况下，默认都是会自动关闭掉THP，除非用户强制指定了不关闭的配置。这样下来，在大多数情况下，用户都可以避免THP引起的fork之后的剧烈抖动问题。 关于conf的描述 在redis.conf中增加了一个新的配置项“disable-thp”，作者最初的描述是
iomem=str mem=str Fio can use various types of memory as the io unit buffer. The allowed values are: malloc Use memory from malloc(3) as the buffers. shm Use shared memory as the buffers. Allocated through shmget(2). shmhuge Same as shm, but use huge pages as backing. mmap Use mmap to allocate buffers. May either be anonymous memory, or can be file backed if a filename is given after the option. The format is mem=mmap:/path/to/file. mmaphuge Use a memory mapped huge file as the buffer backing. Append filename after mmaphuge, ala mem=mmaphuge:/hugetlbfs/file mmapshared Same as mmap, but use a MMAP_SHARED mapping. The area allocated is a function of the maximum allowed bs size for the job, multiplied by the io depth given. Note that for shmhuge and mmaphuge to work, the system must have free huge pages allocated. This can normally be checked and set by reading/writing /proc/sys/vm/nr_hugepages on a Linux system. Fio assumes a huge page is 4MB in size. So to calculate the number of huge pages you need for a given job file, add up the io depth of all jobs (normally one unless iodepth= is used) and multiply by the maximum bs set. Then divide that number by the huge page size. You can see the size of the huge pages in /proc/meminfo. If no huge pages are allocated by having a non-zero number in nr_hugepages, using mmaphuge or shmhuge will fail. Also see hugepage-size. mmaphuge also needs to have hugetlbfs mounted and the file location should point there. So if it'smountedin/huge,youwouldusemem=mmaphuge:/huge/somefile.iomem_align=intThisindiciatesthememoryalignmentoftheIOmemorybuffers.NotethatthegivenalignmentisappliedtothefirstIOunitbuffer,ifusingiodepththealignmentofthefollowingbuffersaregivenbythebsused.Inotherwords,ifusingabsthatisamultipleofthepagesizedinthesystem,allbufferswillbealignedtothisvalue.Ifusingabsthatisnotpagealigned,thealignmentofsubsequentIOmemorybuffersisthesumoftheiomem_alignandbsused.hugepage-size=intDefinesthesiz
熊军（老熊） 云和恩墨西区总经理 Oracle ACED，ACOUG核心会员 PC Server发展到今天，在性能方面有着长足的进步。64位的CPU在数年前都已经进入到寻常的家用PC之中，更别说是更高端的PC Server；在Intel和AMD两大处理器巨头的努力下，x86 CPU在处理能力上不断提升；同时随着制造工艺的发展，在PC Server上能够安装的内存容量也越来越大，现在随处可见数十G内存的PC Server。正是硬件的发展，使得PC Server的处理能力越来越强大，性能越来越高。而在稳定性
/proc/PID/smaps 文件是基于 /proc/PID/maps 的扩展，他展示了一个进程的内存消耗，比同一目录下的maps文件更为详细。
随着计算需求规模的不断增大，应用程序对内存的需求也越来越大。为了实现虚拟内存管理机制，操作系统对内存实行分页管理。自内存“分页机制”提出之始，内存页面的默认大小便被设置为 4096 字节（4KB），虽然原则上内存页面大小是可配置的，但绝大多数的操作系统实现中仍然采用默认的 4KB 页面。 4KB 大小的页面在“分页机制”提出的时候是合理的，因为当时的内存大小不过几十兆字节，然而当物理内存容量增长到几 G 甚至几十 G 的时候，操作系统仍然以 4KB 大小为页面的基本单位，是否依然合理呢？
本文主要介绍内存管理中的HVO（HugeTLB Vmemmap Optimization）特性，通过HVO可以节省管理HugeTLB 页面元数据（struct page）的内存占用，甚至在缓存的空间局部性表现上也更好。本文通过图解结合源代码分析的方式让大家彻底理解HVO的实现原理，且本文主要以2M大小的HugeTLB 页面为例讲解。
对于用户空间的应用程序，我们通常根本不关心page的物理存放位置，因为我们用的是虚拟地址。所以，只要虚拟地址不变，哪怕这个页在物理上从DDR的这里飞到DDR的那里，用户都基本不感知。那么，为什么要写一篇论述页迁移的文章呢？
你熟悉的Android Root方式有哪些？ 如何在无需任何特殊权限条件下 控制用户手机设备？ 安小妹无意中发现了乐固一枚技术GG的文档 于是整理分享给大家 喜欢的话别忘了分享噢 [附视频演示] 不依赖于软件漏洞的 Android Root 方式 引言： 安全界有四大著名的顶级会议： S&P,CCS,USENIX Security,NDSS 这四个会议论文通过率都非常之低，也从侧面透露出其发表的研究论文含金量极高。在其中2016年的CCS会议上，来自阿姆斯特丹自由大学与加利福尼亚大学圣巴巴拉分校的研究员V
随着anroid 系统越来越庞大。“得屌丝者，得天下！” 是手机厂商的血液基因。“屌丝”代表成本的节省！而memory 显然是可以扣一口成本的。
前面我们提到Linux内核仅使用了较少的分段机制，但是却对分页机制的依赖性很强，其使用一种适合32位和64位结构的通用分页模型，该模型使用四级分页机制，即
前言： 乍一看，hugetlb和hugepage还挺像的，好像都是所谓的“大页”。然而，却很难说出来它们的差异。作者也是花了写时间翻翻代码，写了几个测试的例子，加上用工具据实测了几个关键参数，才明白。 分析： 1，page fault 用户大多数情况下申请内存的方法： a，使用malloc函数族，其实是glibc封装了brk/mmap。这种情况下分配的是虚拟内存，并没有直接分配物理内存。 b，调用brk分配，这种情况很少见，并只分配虚拟内存。 c，使用mmap，分配出来虚拟内存。如果flags带有MAP
页迁移技术是内核中内存管理的一种比较重要的技术，最早该技术诞生于NUMA系统中（Page migration [LWN.net]），后续由于内存规整以及CMA和COW技术的出现，也需要用到页迁移技术，逐渐称为内核内存子系统中占有比较重要地位。
常见的内存分配函数有malloc，mmap等，但大家有没有想过，这些函数在内核中是怎么实现的？换句话说，Linux内核的内存管理是怎么实现的？
本人最近会把proc目录详解给大家弄一下，欢迎翻译，有问题则留言。虽然是英文的，但都比较好理解，如有问题，请留言，我们共同为Linux社区而努力。我们翻译效果还不一定好，因为这玩意毕竟是老外搞的吗！！！咯咯，翻译可能引起误解。这玩意看懂需要tcp/ip方面的知识，学好proc对于linux性能优化是非常重要。这来自本人的整理。希望对大家有用。/proc/sys/vm主要是关于虚拟存储的相关信息。这个目录如下：
终于可以进入Linux kernel内存管理的世界了，但是从哪里入手是一个问题，当面对一个复杂系统的时候，有时候不知道怎么开始。遵守“一切以人为本”的原则，我最终选择先从从userspace的视角来看内核的内存管理。最开始的系列文章选择了vm运行参数这个主题。执行ls /proc/sys/vm的命令，你可以看到所有的vm运行参数，本文选择了overcommit相关参数来介绍。
除了 CPU 虚拟化，另一个关键是内存虚拟化，通过内存虚拟化共享物理系统内存，动态分配给虚拟机。虚拟机的内存虚拟化很象现在的操作系统支持的虚拟内存方式，应用程序看到邻近的内存地址空间，这个地址空间无需和下面的物理机器内存直接对应，操作系统保持着虚拟页到物理页的映射。
前面提到了虚拟内存需要映射物理内存才能使用，这个映射关系被保存在内存中的页表（Page Table）。现代 CPU 架构中一般有 TLB （Translation Lookaside Buffer，翻译后备缓冲，也称为页表寄存器缓冲）存在，在里面保存了经常使用的页表映射项。TLB 的大小有限，一般 TLB 如果只能容纳小于 100 个页表映射项。 我们能让程序的虚拟内存对应的页表映射项都处于 TLB 中，那么能大大提升程序性能，这就要尽量减少页表映射项的个数：页表项个数 = 程序所需内存大小 / 页大小。我们要么缩小程序所需内存，要么增大页大小。我们一般会考虑增加页大小，这就大页分配的由来，JVM 对于堆内存分配也支持大页分配，用于优化大堆内存的分配。那么 Linux 环境中有哪些大页分配的方式呢？
按照提示分别修复: 1.第一个提示somaxconn这个值为128太小了,这个值是系统的网络连接队列大小,而redis的TCP backlog设置的值为511,因此受限,所以修改下系统的值
我们之前在生产环境上遇到过很多起由操作系统的某些特征引起的性能抖动案例，其中 THP 作案次数较多，因此本文将和大家分享 THP 引起性能抖动的原因、典型的现象，分析方法等，在文章的最后给出使用THP 时的配置建议及关闭方法。
在 Linux 中大页分为两种： Huge pages (标准大页) 和 Transparent Huge pages(透明大页)。
HugePages是通过使用大页内存来取代传统的4kb内存页面，使得管理虚拟地址数变少，加快了从虚拟地址到物理地址的映射以及通过摒弃内存页面的换入换出以提高内存的整体性能。尤其是对于8GB以上的内存以及较大的Oracle SGA size，建议配值并使用HugePage特性。本文基于x86_64 Linux下来描述如何配值 HugePages。 有关HugePages的特性请参考：Linux HugePage 特性
前段时间在vpp交流群讨论bihash在默认条件下初始化的时候使用的是系统内存，还是大页内存。讨论也修正我的知识库，对bihash的理解也还停留在20.09版本之前。
作者简介： 周文嘉: 曾服务于ARM、阿里系子公司、HTC等公司。10年以上工作经验，主要从事系统软件开发，涵盖：系统库开发、指令集优化、Linux内核开发等。累计为某些开源社贡献过一定数量的patch。 在 Linux 内核启动之后，对于 32 位的系统来说，他会把 0 ~ 896M 这部分低端内存（low memory）都做线性映射，不管这部分内存是否需要用到。对于 64 位的系统，内核会把所有的物理（一般情况如此，除非物理内存特别大）内存都映射出来。这么做的目的是啥？这里先说结论，然后分析代码。 这么
Redis 利用了多路 I/O 复用机制，处理客户端请求时，不会阻塞主线程；Redis 单纯执行（大多数指令）一个指令不到 1 微秒，如此，单核 CPU 一秒就能处理 1 百万个指令（大概对应着几十万个请求吧），用不着实现多线程（网络才是瓶颈）。
最近有同事问了几个关于大内存页(HugePage)的问题，就顺便复习并拓展的看了下相关的内容，根据自己的理解做个简单总结，如有纰漏欢迎指正。
在Linux内核，对于进程的内存使用与Cgroup的内存使用统计有一些相同和不同的地方。
这部分将简要介绍下NUMA架构的成因和具体原理，已经了解的读者可以直接跳到第二节。
页是信息的物理单位, 分页是为了实现非连续分配, 以便解决内存碎片问题, 或者说分页是由于系统管理的需要. 段是信息的逻辑单位,它含有一组意义相对完整的信息, 分段的目的是为了更好地实现共享, 满足用户的需要.
程序是代码和数据的集合，进程是运行着的程序；操作系统需要为进程分配内存；进程运行完毕需要释放内存；内存管理就是内存的分配和释放；
前面分析了伙伴管理算法的初始化，在切入分析代码实现之前，例行先分析一下其实现原理。
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
ICP备案
对象存储
腾讯会议
实时音视频
