Linux内存碎片


20

有没有一种方法可以检测Linux上的内存碎片?这是因为在某些长时间运行的服务器上,我注意到性能下降,并且只有在重新启动进程后,我才能看到更好的性能。在使用linux大型页面支持时,我注意到的更多-Linux中的大型页面是否更容易碎片化?

我特别看了/ proc / buddyinfo。我想知道是否有更好的方法(不仅仅是CLI命令本身,任何程序或理论背景都可以)查看它。


我不只是在寻找快速的命令行解决方案,任何简单的程序/理论都可以。因此,我没有问过serverfault。
拉格

1
我在这里一点都不明白。据我了解,内存碎片必定会导致内存不足,并导致内存分配错误。但是,您正在询问性能下降。是因为您有很多内存交换到磁盘上吗?如果是这样的话vmstat,该so怎么办?

@skwllsp-编辑我的答案以更具体。
蒂姆·波斯特

@Raghu-我不希望大多数系统管理员修改内核代码以使内存管理表现不同,但是,熟练的 Linux管理员至少应该了解Linux 如何管理内存的概述。这个问题的确存在。我投票决定迁移它只是因为我不能建议(在我的答案中)可以回答您问题的代码。从/ proc读取或使用vmstat是一种常见的用户体验。如果您编写的程序要执行相同的操作,那将有所不同。如果您打算使用bash收集此信息,请编辑您的问题,它将不会被关闭:)
Tim Post

@Tim-正如我建议的,不仅仅是我想知道的bash / cli命令,我需要这些信息来帮助我进行基准测试(分析结果,而不是运行结果)。
拉格

Answers:


12

我在回答标签。我的答案仅针对Linux

是的,大页面更容易分散。内存有两种视图,一种是进程获取的(虚拟的)视图,另一种是内核管理的(真实的)视图。任何页面越大,将其邻居分组(并与邻居保持)的难度就越大,尤其是当您的服务运行在一个系统上时,该系统还必须支持其他默认情况下会分配和写入更多内存的系统实际最终使用。

内核对(实际)授予地址的映射是私有的。用户空间在内核呈现它们时会看到它们是有很好的理由的,因为内核需要能够过度使用而不混淆用户空间。你的进程得到一个不错的,连续的“Disneyfied”地址空间来工作,根本不在意什么内核实际上是在做与幕后内存。

在长时间运行的服务器上看到性能下降的原因很可能是因为未显式锁定(例如mlock()/ mlockall()posix_madvise())并且在一段时间内未修改的已分配块已被调,这意味着您的服务在必须读取时会滑入磁盘他们。修改此行为会使您的进程成为邻居,这就是为什么许多人将RDBMS放置在与web / php / python / ruby​​ / whatever完全不同的服务器上的原因。修复此问题的唯一方法是减少对连续块的竞争。

仅在页面A处于内存中并且页面B已移动到交换位置时,​​碎片才真正显着(在大多数情况下)。自然地,重新启动服务似乎可以“治愈”此问题,但这仅是因为内核尚未有机会在其过量使用率范围内分出新分配的块(现在)。

实际上,在高负载下重新启动(让我们说)“ apache”很可能会将其他服务拥有的块直接发送到磁盘。所以是的,“ apache”将在短时间内得到改善,但是“ mysql”可能会遭受..至少直到内核仅使它们缺乏足够的物理内存时,它们才同样遭受痛苦。

添加更多内存,或拆分苛刻的malloc()使用者:)它不仅仅是您需要关注的碎片。

尝试vmstat大致了解实际存储在何处。


谢谢你的回答。我正在为MySQL-innodb缓冲池使用巨大的页面(每个大小= 2048KB),以查看它的运行情况(使用sysbench)。最初,当流程正常运行时间(甚至系统正常运行时间)很短时,它给出了很好的结果。但是,它的性能在数次运行后开始下降。关于您提到的页面,我当然注意到VM活跃,但是我想可能是因为基准测试和innodb日志刷新(有大量页面的vm活动比没有页面的活动高)。我还将vm.swappiness设置为1。我没有注意到任何大的变化。
拉格

根据精美的手册,“在内存压力下,大页不能换出。” 我认为这是带W / R / T标准内存的不错选择,但不适用于大页面。
丹·普里兹

5

核心

要获取当前的碎片索引,请使用:

sudo cat /sys/kernel/debug/extfrag/extfrag_index

要对内核内存进行碎片整理,请尝试执行:

sysctl vm.compact_memory=1  

您也可以尝试关闭“透明大页面”(又名THP)和/或禁用交换(或减少swappiness)。

用户空间

为了减少用户空间碎片,您可能需要尝试使用其他分配器,例如jemalloc(它具有强大的自省功能,这将使您有机会深入了解分配器内部碎片)。

你可以或者只是通过运行程序通过重新编译它你的程序切换到自定义的malloc LD_PRELOADLD_PRELOAD=${JEMALLOC_PATH}/lib/libjemalloc.so.1 app (提防THP和内存的内存分配之间的相互作用

虽然与内存碎片(与内存压缩/迁移有关)稍有关系,但您可能希望运行服务的多个实例,每个NUMA节点一个实例,并使用绑定它们numactl


1
您为什么认为禁用交换功能会有所帮助?对我来说,禁用交换似乎更有可能带来更大的伤害。
kasperd 2015年

1
因为原始帖子中没有足够的信息,所以可能只是流程泄漏并开始交换。我也没有看到在几乎任何生产系统上使用交换的任何正当理由(mb仅用于学生的共享工作站)。
SaveTheRbtz 2015年

2
拥有足够的交换空间将提高性能。如果交换空间不足,则会出现性能问题,这足以启用交换。
kasperd 2015年

1
@SaveTheRbtz在生产系统上使用交换的一个很好的理由是,它给系统提供了更多的选项,只有当它认为它们是有益的时才使用。此外,它还允许从宝贵的物理内存中弹出几个小时未访问过(并且可能永远无法访问)的已修改页面。最后,它允许系统合理地处理保留的内存比使用的内存大得多的情况。
大卫·史瓦兹

2
“仅当它认为它们是有益的时”-这增加了其他启发式方法,并使系统难以预测。同样,页面替换算法(用于swap和anonymous mmap)在不同的内核(例如Linux与FreeBSD)甚至同一操作系统的不同版本(2.6.32与3.2与3.10)上以不同的方式实现。 ..]从物理内存中弹出“-将隐藏内存泄漏。“处理保留的内存比使用的内存多得多的情况”-慢速系统比停机系统差很多,因此“理智”是有问题的。
SaveTheRbtz

4

使用大页面不会在Linux上引起额外的内存碎片;Linux对大页面的支持仅用于共享内存(通过shmget或mmap),并且所用的任何大页面都必须由系统管理员明确请求并预先分配。一旦存入内存,它们便固定在此处,不会被交换出去。面对内存碎片,交换大页面所面临的挑战正是为什么它们仍固定在内存中的原因(分配2MB的大页面时,内核必须找到512个连续的免费4KB页面,甚至可能不存在)。

大型页面上的Linux文档:http : //lwn.net/Articles/375098/

在一种情况下,内存碎片可能会导致大页面分配变慢(但在大页面导致内存碎片的情况下则不会这样),那就是如果系统将应用程序配置为增长大页面池。如果/ proc / sys / vm / nr_overcommit_hugepages大于/ proc / sys / vm / nr_hugepages,则可能会发生这种情况。


确实-它通常应该有助于提高性能,因为它将防止TLB遗漏(请参阅链接的文章以获取解释)。
Dan Pritts 2013年

0

/proc/buddyinfo一个非常有用的。良好的输出格式更有用,例如此Python脚本可以做到:

https://gist.github.com/labeneator/9574294

对于大页面,您需要一些2097152(2MiB)或更大的免费片段。对于透明的大页面,当请求内核时,它将自动压缩,但是如果要查看可以获取的数量,请以root身份运行:

echo 1 | sudo tee /proc/sys/vm/compact_memory

同样可以,巨大的页面会导致较大的碎片问题。您可能无法获得任何大页面,或者它们的存在会导致内核花费大量额外时间来尝试获取一些页面。

我有一个适合我的解决方案。我在几台服务器和笔记本电脑上使用它。它非常适合虚拟机。

kernelcore=4G选项添加到Linux内核命令行。在我的服务器上,我使用8G。请小心该数字,因为它会阻止内核在该内存之外分配任何内容。需要大量套接字缓冲区或将磁盘流写入数百个驱动器的服务器不会像这样受到限制。必须为平板或DMA“固定”的任何内存分配都在此类别中。

然后,所有其他内存将变为“可移动”,这意味着可以将其压缩为漂亮的块,以进行大量页面分配。现在,透明的大页面可以真正起飞并按预期工作。每当内核需要更多2M页面时,它都可以将4K页面重新映射到其他地方。

而且,我不太确定这与零拷贝直接IO如何相互作用。不应固定“可移动区域”中的内存,但是直接IO请求将完全针对DMA。它可能会复制它。无论如何,它可能会将其固定在可移动区域中。无论哪种情况,它可能都不是您想要的。

By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.