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

内核对(真实)授权地址的映射是私有的.用户空间在内核呈现它们时有一个很好的理由,因为内核需要能够过度使用而不会混淆用户空间.你的进程得到了一个漂亮的,连续的“迪士尼”地址空间,可以在其中工作,无视内核在幕后实际使用的内存.

您在长时间运行的服务器上看到性能下降的原因很可能是因为未明确锁定的已分配块(例如mlock()/ mlockall()或posix_madvise())并且暂时未被修改,这意味着您的当必须读取它们时,服务滑动到磁盘.修改此行为会使您的进程成为一个糟糕的邻居,这就是为什么许多人将他们的RDBMS放在一个完全不同于web / PHP / python / ruby​​ / whatever的服务器上的原因.理所当然地解决这个问题的唯一方法是减少对连续区块的竞争.

当页面A在内存中并且页面B已经移动到交换时,碎片只是非常明显(在大多数情况下).当然,重新启动您的服务似乎可以“解决”这个问题,但这只是因为内核还没有机会在其过度使用率的范围内将(现在)新分配的块分页出来.

事实上,在高负载下重新启动(假设)’apache’可能会将其他服务拥有的块直接发送到磁盘.所以是的,’apache’会在短时间内得到改善,但’MysqL’可能会受到影响……至少在内核使得它们在没有足够的物理内存的情况下遭受同等程度时会受到影响.

添加更多内存,或拆分要求苛刻的malloc()消费者:)它不仅仅是你需要关注的碎片.

尝试使用vmstat来概述实际存储的位置.