【转帖】系统软件工程师必备技能-进程内存的working set size(WSS)测量

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

2018年12月28日 18:43:01 Linuxer_ 阅读数:145

https://blog.csdn.net/juS3Ve/article/details/85333717
  • How To Measure the Working Set Size on Linux|来源:内核月谈

概述

本文主要摘自brendangregg大神的blog:

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

研究如何衡量一个特定业务程序的working set size。先不谈概念,让我们一起先思考一下为什么要研究WSS呢?举个例子来说,某些后台daemon为了性能,喜欢在程序在启动阶段就创建好各种fixed-size的内存池,且不支持动态grow/shrink,这些内存池的真实利用率如何?是否存在浪费?访问频率如何?读者可能会想到通过在内存池实现上做一些简单统计,不难得到程序的访问频率或者冷热内存页。那么如果是一个第三方程序呢?对测量的人来说是一个黑盒子,这种场景则只能尝试在操作系统层来考虑。本文从Linux的角度系统阐述了目前的常用手段,有什么缺陷以及一些优化手段。

作者

邓刚,马涛,Linux系统工程师,来自阿里云系统组。

本文中若有任何疏漏错误,有任何建议和意见,请回复内核月谈微信公众号,或通过gavin.dg at linux.alibaba.com>或者 tao.ma at linux.alibaba.com反馈。

阿里云系统团队,是由原淘宝内核组扩建而成,2013年淘宝内核组响应阿里巴巴集团的号召,整建制转入阿里云,开始为云计算底层系统构建完善的系统支持。 阿里云系统团队是由一群具有高度使命感和自我追求的内核开发人员组成,团队中的大多数人,都是活跃的社区内核开发人员。目前的工作领域主要涉及(但不限于) Linux内核的内存管理、文件系统、网络和内核维护构建,以及和内核相关联的用户态库和工具。如果你对我们的工作很感兴趣,欢迎加入我们,请将简历发送至 tao.ma at linux.alibaba.com或者 boyu.mt at alibaba-inc.com。

正文

Working Set Size(WSS)是指一个app保持正常运行所须的内存。比如一个应用在初始阶段申请了100G主存,在实际正常运行时每秒只需要50M,那么这里的50M就是一个WSS。评估WSS能干嘛呢?它可以用来进行内存容量规划并进行必要的内存扩容或者软件优化。这个问题并不新鲜而且非常重要,然而brendangregg却表示至今为止没有实际可用的有效工具(译者注:严重同意,而且在翻译这篇文章之前译者也开发了类似工具,在阿里巴巴内部使用)。有经验的读者可能会注意到Linux top命令的输出中,有两列分别是VIRT与RES,其中VIRT是进程使用的虚拟内存地址空间大小,而RES则是实际使用的物理内存(如果考虑共享映射等,则需要用到smaps proc文件的PSS或者top命令的SHARE,不过这两者对于理解WSS无益,故不在此展开)。比如,一个进程刚启动时通过私有匿名映射了(map_flags=MAP_PRIVATE | MAP_ANON)100G内存,然后实际只访问其中50G,那么VIRT=100G,RES=50G。那么问题来了,如何评估这50G内存的访存频率呢?是否存在明显的冷热区分呢?针对这个问题,brendangregg开发了两款基于Linux系统的小工具,下文将分别详细介绍。

Method 1: Referenced Page flag

这是基于Linux Kernel 2.6.22引入的一个特性:the ability to set and read the referenced page flag from user space, added for analyzing memory usage. brendangregg大神基于此实现了一个https://github.com/brendangregg/wss wss.pl工具,下面的案例在0.1s内存测量mysqld(PID=423)的WSS:

上面表示0.1秒内mysqld访问了28M物理内存(总内存403.66M)。为什么选取0.1s而不是更长?大神解释说这样短时间段内的测量可以帮助我们正确评估业务程序对CPU cache的使用(比如L1/L2/L3, TLB L1/L2等)。28M略大于CPU LLC的大小,所以cache并非工作得很完美。这个工具也支持累计模式,仅重置一次referenced flag然后以固定间隔持续采集,输出如下:

可以看到WSS在逐渐增加。其中各列的含义:

Est(s): 采集时刻;

RSS(MB):物理内存使用(MBytes);

PSS(MB):按共享映射的次数,均摊算出的物理内存使用量(MBytes);

Ref(MB):在Est(s)内,进程实际访问过的内存(MBytes)。

细心的读者可能会发现,数据中的Est并非恰好是整数秒。这里的原因是因为程序本身在重置referenced flag或者从proc接口读取都需要消耗一定的时间,而且随着进程使用的内存越多,开销越大。

这个小工具的原理什么呢?对x86 MMU架构有了解的读者应该知道PTE有一个bit为 accessed bit。它的特性是:一旦CPU访问了一个内存地址,那么该地址相应的PTE的accessed bit将会被置上。这是一个硬件特性,至于如果利用它则需要我们一起发挥想象力了。著名的linux mm 子系统里的LRU页框回收算法,在除了以软件的方式打tag之外,就依赖了该bit来区分页的冷热程度。这里多说一句,其实WSS这个小工具的目的是找出特定时间段内被访问过的页,而LRU则是找出最近一段时间段内未被访问过或访问频率低的页,本质上是不是很像呢?所以大家都是用了相同的bit,做了类似的事情。回到正题,David Rientjes在2007年提了一个patchhttp://lkml.iu.edu/hypermail/linux/kernel/0702.1/0628.html,用于从内核导出文件/proc/PID/clear_refs,用户可以在用户态通过对特定进程清理page referenced flag,这样在/proc/PID/smaps文件中就可以查看被访问过的内存大小了。

这个工具的缺陷非常明显,比如可能影响到被测试的业务进程(比如延迟增加10%,对于100G内存的进程,影响时间超过1s),而且该工具自身也需要消耗system time。另外,该工具由于从用户态接口清理了page referenced flag,这也将影响到LRU算法的准确度,尤其是swap打开以后,很可能将一些热内存页判定为冷内存并swap到disk。更严重的是,一些老内核还有panic风险。在Linux 4.3+版本中的引入了idle page flag特性可以解决此处提到的部分缺陷,后文再详细介绍。

WSS profile charts

brendangregg大神尤其擅长将各种性能数字图形化,本文当然也不例外。wss.pl支持profile模式(-P),以等比数列步长(即当前步长 = 上一次步长 * 2)进行统计,输出如下:

每相邻两行的采集间隔成等比递增:短采样间隔可以用来评估进程对cpu cache的利用,长采样间隔则用来评估进程的物理内存使用趋势。注意这仅是采集一轮的数据(译者注:仅在采样的初始阶段清理一次page referenced flag,可以理解为 1* write + N * read,如果读者想得到更一般化的数据,则应该采集多轮)。将上面的采集数据图形化展示:

uniform 是指100M地址空间内uniform access distribution (译者注:应是指“匀速”访问100M地址空间),可以看到除第一个点外,其他点均稳定在100M,这是因为此时uniform访问的进程还没来得及访问整个地址空间。为了对比,将地址空间调整为2G,如下图所示(分别是对数坐标曲线以及线性曲线):

Method 2: Idle Page Flag

Idle page flag 是Vladimir Davydov在Linux4.3中实现的一个新特性,引入了两种新的page flag:idle和young,它弥补了方案一的一个重要缺陷:影响page reclaim的逻辑。该方案仍然是基于PTE的accessed bit,通过在page_ext_flags引入了额外的idle&&young page flag来保证page reclaim的逻辑不受此影响(译者注:此处关于idle page tracking实现的描述不够准确,译者理解如下:方案一的缺陷在于清理PTE的accessed bit会导致page reclaim的逻辑误判某些热页为冷页,那么通过引入一个软件上的young flag来辅助记录此页为热页,清理accessed bit时将flag置位。这样page reclaim如果遇到young flag置位的页则认为其最近同样被访问过)。另外,上述两个flag在64bit的kernel中被直接定义为page flag,在32bit的kerne中由于page flags空间不够用,则基于page extension特性来定义。以下摘自内核源码树中的文档Documentation/vm/idle_page_tracking.txt vm/idle_page_tracking.txt:

That said, in order to estimate the amount of pages that are not used by a workload one should:

  1. Mark all the workload’s pages as idle by setting corresponding bits in /sys/kernel/mm/page_idle/bitmap. The pages can be found by reading /proc/pid/pagemap if the workload is represented by a process, or by filtering out alien pages using /proc/kpagecgroup in case the workload is placed in a memory cgroup.
  2. Wait until the workload accesses its working set.
  3. Read /sys/kernel/mm/page_idle/bitmap and count the number of bits set. If one wants to ignore certain types of pages, e.g. mlocked pages since they are not reclaimable, he or she can filter them out using /proc/kpageflags.

brendangregg基于此特性写了两个版本的工具,在github https://github.com/brendangregg/wss 可以获取源码,运行截图如下:

这里v1与v2在统计结果上没有差别,主要在于实现方式上:v1每次是一个page为单位进行处理,而v2是batch处理,以maps文件中的每一行(即vma)为单位进行处理,时间消耗从44s降为0.8s。(译者注:之前提到的译者自己写的工具也实现了类似的功能,采用的是v1与v2的折中方案,每次以65536个page为单位处理,不过考虑到测量进程本身的CPU开销以及内存使用,最后放弃该方案)。brendangregg还提到了如果pagemap,idlebitmap,kpagecgroup等支持mmap(2)系统调用,可以避免过多的系统调用。同时大神还想一次性把系统所有page的idle flag都设置上,这样可以得到整机的快照(译者注:idle page tracking只支持扫描LRU链表上的页,对net/kmalloc等kmem是透明的)。另外,第一次采样间隔预期是0.01s(而目前扫描一次最小消耗0.8s),为了实现这个目标,brendangregg提到可以通过发送SIGSTOP以及SIGCONT让被测量的进程停止运行,显然这很可能影响进程的正常逻辑,比如影响tcp窗口,触发超时等。(译者注:brendangregg似乎更关注于细粒度的采样,辅助性能分析;其实粗粒度采样也有参考价值,可以分析内存利用率或者集群调度等,此为后话)。

结语

由于目前没有有效的工具来测量WSS,所以brendangregg大神尝试写了两个小工具。同时他还有一篇文章提到了一些其他方案来预估WSS,比如PMC,见

http://www.brendangregg.com/wss.html

里面有一些更深入的讨论,读者有兴趣可自行前往一观。另外,译者在阿里内部也实现了几个不同版本的工具,实现原理类似,方法则有不小的差异,欢迎大家来阿里一起切磋。

原文地址:https://www.cnblogs.com/jinanxiaolaohu/p/10674805.html

时间: 2024-07-28 12:34:09

【转帖】系统软件工程师必备技能-进程内存的working set size(WSS)测量的相关文章

前端工程师必备技能

前端工程师必备技能 金刚 前端 前端工程师 今天在技术群里看到几张讲前端的图片,好棒,记录下.以后慢慢扩展相关领域. 前端技术汇总.jpg 前端工程师所需要掌握的技能.jpg 前端工程师所需要掌握的技能.jpg

前端工程师必备技能汇总

首先,看一张前端知识结构图:  (原文: ithomer) 图片的形式具有诸多的不便.缺失源图的我们,无法为此图贡献些什么,随着时间的迁移,或许有些技术点会发生改变,所以有了这个GitHub项目.我们可以通过协作的方式来共同维护这个项目.Git的历史记录也可以见证前端行业的一些变迁. 尽管会变成文字的方式来维护这些内容,但是我承诺写一个小工具帮大家生成更好玩的图形(基于DataV项目). 前端开发知识结构 前端工程师 浏览器 IE6/7/8/9/10/11 (Trident) Firefox (

解读前端开发工程师必备技能

看到这个标题的大都是前端开发边缘的同学,有多少能直言不讳的说自己是前端工程师呢?不是打击谁谁谁,而是我们需要反思一个问题:什么才是真正意义上的前端开发呢? 前端开发这个职业始于几年前,至今已发展的初步成熟了.如果你打算进入这个行业,你要做好的准备,因为要学的要懂得的实在不少:如果你已经在这个行业一两年了,也请你不要放弃对前端开发的继续追寻和研究:更老一点的,浩子也就不能说什么了,是你们让更好的前端发展至今,在此抱以感激! 上述一段,也就是把前端的开发者总概了一下,下面我们来看看前端需要什么技能?

web前端开发工程师必备技能

看到这个标题的大都是前端开发边缘的同学,有多少能直言不讳的说自己是前端工程师呢?不是打击谁谁谁,而是我们需要反思一个问题:什么才是真正意义上的前端开发呢? 前端开发这个职业始于几年前,至今已发展的初步成熟了.如果你打算进入这个行业,你要做好的准备,因为要学的要懂得的实在不少:如果你已经在这个行 业一两年了,也请你不要放弃对前端开发的继续追寻和研究:更老一点的,也就不能说什么了,是你们让更好的前端发展至今,在此抱以感激! 上述一段,也就是把前端的开发者总概了一下,下面我们来看看前端需要什么技能?

分析软件工程师必备技能

关于软件测试专业知识有很多,那么作为一个软件测试人员应该掌握哪些基础专业技能,作为自己的知识储备呢?以下从专业出发,整理了一些有用的 ⒈    测试主页技能掌握 关于软件测试,所需要的专业技能: 基础测试技术:黑盒测试.白盒测试.测试用例设计等: 软件测试方法:单元测试.功能测试.集成测试.系统测试.性能测试: 软件测试知识:基础的测试流程管理.缺陷管理.自动化测试技术等. ⒉    简单的软件编程技能 仅仅拥有测试的技能,还远远不够.测试人员的必备技能之一软件编程能力,很多测试人员都拥有多年的

这是一份集合一线大厂Android工程师必备技能体系+学习路线!

一份学习路线图,非常赞,推荐给大家. 目录 Java基础 Java Object类方法 HashMap原理,Hash冲突,并发集合,线程安全集合及实现原理 HashMap 和 HashTable 区别 HashCode 作用,如何重载hashCode方法 ArrayList与LinkList区别与联系 GC机制 Java反射机制,Java代理模式 Java泛型 Synchronized原理 Volatile实现原理 方法锁.对象锁.类锁的意义和区别 线程同步的方法:Synchronized.lo

web前端工程师必备技能汇总

web前端知识结构图. 图片的形式具有诸多的不便.缺失源图的我们,无法为此图贡献些什么,随着时间的迁移,或许有些技术点会发生改变,所以有了这个github项目.我们可以通过协作的方式来共同维护这个项目.Git的历史记录也可以见证前端行业的一些变迁. 尽管会变成文字的方式来维护这些内容,但是我承诺写一个小工具帮大家生成更好玩的图形(基于DataV项目). 前端开发知识结构 前端工程师 SVG/Canvas/VML SVG: D3/Raphaël/Snap.svg/DataV Canvas: Cre

前端工程师必备技能储备

前端开发知识结构 前端工程师 浏览器 IE6/7/8/9/10/11 (Trident) Firefox (Gecko) Chrome/Chromium (Blink) Safari (WebKit) Opera (Blink) 编程语言 JavaScript/Node.js CoffeeScript TypeScript 切页面 HTML/HTML5 CSS/CSS3 PhotoShop/Paint.net/Fireworks/GIMP 开发工具 编辑器和IDE VIM/Sublime Tex

精华总结:网络工程师必备技能-如何用PPT画出精美拓扑视频教程

具备5年IT从业经验,资深IT经理,项目经理,产品经理.精通思科.H3C.华为.深信服.信锐.迪普.网康.Juniper.山石等网络设备:精通虚拟化.云计算.云桌面.服务器.存储.数据备份等项目实施交付,具有丰富的网络规划设计.项目实施经验. 课程目标本课程讲解如何用PPT画出精美拓扑,帮助大家解除画不出漂亮拓扑的困扰,免除被领导批评的痛苦,加速职位晋升,PPT提供华为.H3C.思科.深信服常用图标库,同时直接提供常用场景网络拓扑原图,可以直接修改或者直接使用,方便快捷!课程链接http://e