专栏首页皮振伟的专栏[Linux][mm]TLB shootdown和读取smaps对性能的影响 ​

[Linux][mm]TLB shootdown和读取smaps对性能的影响 ​

作者遇到了业务的一个性能抖动问题,在这里介绍一下它的原因和解决办法。 分析 1,page fault 在Linux上,进程分配到的内存是虚拟内存,经过内核的页表管理,会把虚拟内存映射成物理内存。 a,在第一次访问内存的时候,会触发page fault,内核会给进程分配好内存,进程继续执行。 b,内核进行内存回收,可能会把进程的部分内存进行回收,swap到磁盘上,下次访问到再换回来。当然,这个在实际业务上未必会启用swap以防止性能下降。 c,进程自己判断,认为部分内存段时间内不会使用,会尝试把它归还给内核。它的好处是不需要修改进程的虚拟地址空间,只是把内存页面(page)归还给内核,下一次访问到的时候,会因为page fault而重新分配物理内存。 另外需要注意的时候,处理page fault的过程中,需要持有进程的内存的锁(current->mm->mmap_sem)。 2,TLB shootdown 例如某服务器有40CPU,那么就意味着可以同时运行40个task。 例如某业务有30个线程,且这30个线程都很忙,并行执行在30个CPU上。 因为30个线程共享地址空间,它们使用的是相同的页表(page table)。所以在运行这30个线程的CPU上,会加载相同的页表。 当代CPU为了加速TLB查找的速度,会使用cache,也就是说会把对应的页表项(page table entry)加载到TLB cache中。 在运行的某一个时刻,某1个线程执行了上述的page fault的case 3,也就是执行了系统调用int madvise(void *addr, size_t length, MADV_DONTNEED),想要释放1个page(4K大小),除了需要修改页表释放该page外,还需要确保CPU的TLB cache中也是没有该page的PTE的。因为如果TLB cache还有该PTE,那么CPU访问这个page就不会出错,而这个page已经被释放并分配给其他进程使用的话,就会造成安全问题。 在多核场景下,这个问题就变得更加复杂了。除了运行madvise的线程之后,还需要确保另外的29个线程运行的CPU的TLB cache也是没有该PTE的。为了实现这种效果,需要当前的CPU通知另外的29个CPU,执行clflush或者重新加载cr3。这个通知的过程需要发送IPI(inter processor interrup)。 发送IPI的这个过程,在x86上的体现就是需要CPU执行wrmsr指令,对应的操作是触发ICR。了解虚拟化的朋友应该知道,wrmsr这条指令在虚拟机上需要经过Hypervisor处理,性能更低一些。 除此之外,在执行madvise的过程中,还需要持有当前进程的内存的锁(current->mm->mmap_sem),而且这个锁的粒度比较大。 而jemalloc库,默认情况下,则会释放过期的内存,调用madvise(void *addr, size_t length, MADV_DONTNEED)。 3,smaps/smaps_rollup cat /proc/PID/smaps,可以查看进程的每一段VMA信息。

4.14以及以上版本的内核,也可以执行cat /proc/PID/smaps_rollup,或者总的汇总信息。当然,单次读取smaps_rollup比遍历smaps的性能更好一些。

这里面有一个Rss和Pss。其中Rss的意思是这个进程一共映射了1824K的内存,也就是456个page。 Pss的意思是,对于这个456个page,有的page是当前进程独占的,那么它就统计为4K,有的page是两个进程共享的,那么当前进程就统计为4K/2 = 2K,如果是4个进程共享,那么就是1K。那么就很容易理解,如果要统计出来一个进程的Pss,那么就需要遍历一个进程使用的所有的页面,根据每一个页面的refcount进行计算并求和。 作者统计某进程大约占用内存约50G,遍历一边接近1s。而在遍历的过程中,需要持有进程的内存的锁(current->mm->mmap_sem)。 4,atop 很多监控组件,包括但不限于atop,都有收集Pss使用的功能。 对于atop来说,一个是启动参数-R选项,或者/etc/atoprc里面配置flags R,都可以让atop收集进程的Pss。 在收集的过程中,如果进程的内存比较大,那么就容易出现长时间持锁,而影响进程本身的内存管理的能力。从而造成业务性能的抖动。 5,解决方案 TLB shootdown、page fault、smaps/smaps_rollup之间的互相影响,一般来说,在多线程场景下容易被放大,也容易在大内存场景下放大,还容易在虚拟机上放大。 如何解决呢? a,尽量避免监控组件收集Pss。这个需要点耐心,仔细排查。 b,可以考虑关闭jemalloc的dacay功能。可以参考https://github.com/jemalloc/jemalloc/issues/1422。当然,这个答复上不兼容低版本的jemalloc,需要到代码中确认(搜索decay相关逻辑即可)。

本文分享自微信公众号 - AlwaysGeek(gh_d0972b1eeb60),作者:AlwaysGeek

原文出处及转载信息见文内详细说明,如有侵权,请联系 yunjia_community@tencent.com 删除。

原始发表时间:2019-10-13

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

我来说两句

0 条评论
登录 后参与评论

相关文章

  • 郭健: 进程切换分析之——TLB处理

    进程切换是一个复杂的过程,本文不准备详细描述整个进程切换的方方面面,而是关注进程切换中一个小小的知识点:TLB的处理。为了能够讲清楚这个问题,我们在第二章描述在...

    Linux阅码场
  • 基于KVM虚拟化的混合部署

    KVM forum 2019上,作者和同事的演讲主题是《How KVM-based Hybrid Deployment Powers Bytedance’s B...

    皮振伟
  • Linux 系统性能评测基准系统配置及其原理

    开发人员在高性能系统的性能调优过程中,经常会碰到各种背景的噪声干扰, 从而使得收集的数据不够精确。本文主要从CPU 以及Linux操作系统的角度来分析各种噪声的...

    Linux阅码场
  • 系统软件工程师必备技能-进程内存的working set size(WSS)测量

    http://www.brendangregg.com/blog/2018-01-17/measure-working-set-size.html

    Linux阅码场
  • Linux内核线程kernel thread详解--Linux进程的管理与调度(十)

    Linux内核可以看作一个服务进程(管理软硬件资源,响应用户进程的种种合理以及不合理的请求)。

    233333
  • 向大家汇报,我们连续第二年登上KVM全球开源贡献榜

    用开源回馈社区,腾讯云是认真的。 10月25日,凭借向KVM (内核虚拟化技术)贡献的patch数,腾讯云再次登上KVM开源贡献排行榜,连续两年成为国内贡献度...

    腾讯开源
  • 详解Linux内核内存管理架构

    内存管理子系统可能是linux内核中最为复杂的一个子系统,其支持的功能需求众多,如页面映射、页面分配、页面回收、页面交换、冷热页面、紧急页面、页面碎片管理、页面...

    砸漏
  • 为什么 HugePages 可以提升数据库性能

    内存是计算机的重要资源,虽然今天大多数的服务对内存的需求都没有那么高,但是数据库以及 Hadoop 全家桶这些服务却是消耗内存的大户,它们在生产环境动辄占用 G...

    用户6543014
  • huge page 能给MySQL 带来性能提升吗?

    最近一直在做性能压测相关的事情,有公众号的读者朋友咨询有赞的数据库服务器有没有开启huge page,我听说过huge page会对性能有所提升,本文就一探究竟...

    用户1278550

扫码关注云+社区

领取腾讯云代金券