工作集大小估计

　　工作集大小（WSS）是应用程序保持工作所需的内存量。您的应用程序可能分配了100GB的主内存并进行了页面映射，但它每秒只能接触50MB来完成其工作。这就是工作集大小：经常使用的热内存。了解容量规划和可伸缩性分析非常有用。
　　您可能从未见过用任何工具测量的WSS（当我创建此页面时，我也没有）。操作系统通常会向您显示以下指标：虚拟内存：不是真实内存。它是虚拟内存系统的工件。对于像Linux这样的按需内存系统，malloc（）会立即返回虚拟内存，该内存仅在以后使用时提升为真实内存（通过页面错误提升）。驻留内存或驻留集大小（RSS）：主内存。当前映射的实际内存页。比例集大小（PSS）：RSS在用户之间分配共享内存。
　　内核在管理虚拟和主内存分配时很容易跟踪这些。但是，当您的应用程序处于用户模式时，在其WSS中加载和存储指令时，内核（通常）不参与。因此，内核没有明显的方法来提供WSS指标。
　　在本页上，我将总结适用于任何操作系统的WSS目标和不同的WSS估计方法。这包括我的Linuxwss工具，它们通过使用引用和空闲页面标志进行基于页面的WSS估计，以及我的WSS配置文件图表。
　　目录估计观察：分页交换指标实验：主内存收缩观察：PMC实验：CPU缓存刷新实验：PTE访问位Linux引用页面标志Linux空闲页面标志实验：MMU失效窗口参考集目标
　　您打算使用WSS的目的将指导您如何测量它。请考虑以下三种情况：A）您正在调整应用程序的主内存大小，目的是防止其分页（交换）。WSS将在较长的时间间隔内以字节为单位进行测量，例如一分钟。B）您正在优化CPU缓存。WSS将在短时间间隔（例如一秒或更短）内访问的唯一缓存行中进行测量。缓存行大小取决于体系结构，通常为64字节。C）您正在优化TLB缓存（转换后备缓冲区：用于虚拟到物理转换的内存管理单元缓存）。WSS将以在短时间间隔（例如一秒或更短）内访问的唯一页面进行测量。页面大小取决于体系结构和操作系统配置，通常使用4KB。
　　您可以使用cpuid计算Linux上的缓存行大小，并使用pmapXX计算页面大小。1。估算
　　您可以尝试估计它：您的应用程序将触及多少内存来为请求提供服务，或者在短时间间隔内？如果您有权访问应用程序的开发人员，他们可能已经有一个合理的想法。根据您的目标，您需要询问将引用多少个唯一字节、缓存行或页面。2。观察：分页交换指标
　　分页指标通常在不同的操作系统中可用。Linux，BSD和其他Unix在vmstat中打印它们，在vmstat中打印OSX。通常还有扫描指标，显示系统内存不足，并且花费更多时间填充空闲列表。
　　这些指标的基本思想是：持续分页交换WSS大于主内存。没有分页交换，但持续扫描WSS接近主内存大小。无分页交换或扫描WSS小于主内存大小。
　　与其他内存计数器（如驻留内存又名RSS：驻留集大小、虚拟内存、Linux活动非活动内存等）相比，持续分页的有趣之处在于，持续页输入告诉我们应用程序实际上正在使用该内存来完成其工作。使用驻留集大小（RSS）等计数器，您不知道应用程序每秒实际使用了多少。
　　在Linux上，这需要将交换设备配置为分页的目标，而在许多系统上并非如此。如果没有交换设备，Linux内存不足（OOM）杀手可以杀死牺牲进程以释放空间，这并不能告诉我们很多关于WSS的信息。2。1。分页交换
　　查找寻呼交换计数器通常很容易。它们在Linux上（输出列与标题不对齐）：vmstat1procsmemoryswapiosystemcpurbswpdfreebuffcachesisobiboincsussyidwast1106416678836348539638000011190910001064166656363485396388000184323185100097300106416727636348539635600021504359551009730〔。。。〕
　　Linux将分页称为交换（在其他Unix中，交换是指将整个线程移动到交换设备，而分页仅指页面）。上面的示例显示没有处于活动状态的交换。2。2。扫描
　　较旧的Unix使用页面扫描程序在所有内存中搜索最近未使用的页面以进行分页，并在vmstat中报告扫描速率。当系统内存不足时，扫描速率仅不为零，并根据需求增加。该扫描速率可以用作系统即将耗尽主内存的早期警告（如果它还没有分页），并将速率用作量级。请注意，需要持续扫描（例如，30秒）以指示WSS。应用程序可以分配和填充已扫描和分页但随后不再使用的内存，从而导致扫描和分页突发。那是冷记忆：它不是WSS。WSS处于活动状态，如果分页，将很快再次分页，从而导致分页改动：持续扫描和分页。
　　Linux维护活动和非活动内存列表，以便可以通过浏览非活动列表快速找到符合条件的页面。在不同的时间点，页面将从活动列表移动到非活动列表，在那里它们有机会被回收并移回活动状态，然后在需要时换出。活动非活动内存大小在procmeminfo中可用。要检查系统是否接近交换点，可以使用vmscan跟踪点。例如：perfstatevmscan：aCPerformancecounterstatsforsystemwide：1vmscan：mmvmscankswapdsleep16vmscan：mmvmscankswapdwake8vmscan：mmvmscanwakeupkswapd4vmscan：mmvmscandirectreclaimbegin0vmscan：mmvmscanmemcgreclaimbegin0vmscan：mmvmscanmemcgsoftlimitreclaimbegin4vmscan：mmvmscandirectreclaimend0vmscan：mmvmscanmemcgreclaimend0vmscan：mmvmscanmemcgsoftlimitreclaimend1，407vmscan：mmshrinkslabstart1，407vmscan：mmshrinkslabend10，280vmscan：mmvmscanlruisolate0vmscan：mmvmscanwritepage8，567vmscan：mmvmscanlrushrinkinactive1，713vmscan：mmvmscanlrushrinkactive2，743vmscan：mmvmscaninactivelistislow
　　您可以只选择vmscan：mmvmscankswapdwake跟踪点作为低开销（因为它是低频率）指示器。每秒测量：perfstatevmscan：mmvmscankswapdwakeI1000atimecountsunitevents1。0035866060vmscan：mmvmscankswapdwake2。0136011310vmscan：mmvmscankswapdwake3。0236230810vmscan：mmvmscankswapdwake4。03363443330vmscan：mmvmscankswapdwake5。04365351824vmscan：mmvmscankswapdwake6。0536703170vmscan：mmvmscankswapdwake7。0636900600vmscan：mmvmscankswapdwake
　　您可能还会看到kswapd显示在进程监视器中，消耗CPU。3。实验：主内存收缩
　　值得一提但不推荐：我多年前在Unix系统上看到这种方法，其中分页更常用的配置和使用，并且可以在观察分页的强度的同时实验性地减少正在运行的应用程序可用的内存。有一段时间，应用程序通常满意（低分页），然后不是（突然高分页）。这一点是WSS的度量。4。观察：PMC
　　性能监视计数器（PMC）可以为WSS提供一些线索，并且可以在Linux上使用perf进行测量。以下是使用我的pmcarch工具从pmccloudtools测量的几个工作负载：workloadA。pmcarchKCYCLESKINSTRIPCBRRETIREDBRMISPREDBMRLLCREFLLCMISSLLC306254442187741。384985851365402180。1145511642068067699。85305380842172321。384991443305249380。1145477056766797099。85313268142595051。365158829296803360。1345765672798098399。79〔。。。〕workloadB。pmcarchKCYCLESKINSTRIPCBRRETIREDBRMISPREDBMRLLCREFLLCMISSLLC307923923141480。752731597705128620。1924320255514851818238。93307991223086550。752737887044948200。1824515993514909340139。19309070723165910。752747705785230500。1924381913214839005439。14〔。。。〕
　　工作负载A的上一级缓存（LLC，又名L3）命中率超过99。8。它的WSS可能小于LLC大小吗？可能。LLC大小为24MB（CPU为：英特尔（R）至强（R）铂金8124MCPU3。00GHz）。这是一个具有统一访问分布的综合工作负载，我知道WSS是10MB。
　　工作负载B的LLC命中率为39。一点也不合适。它也是合成和统一的，WSS为100MB，比LLC大。所以这是有道理的。
　　怎么样？workloadB。pmcarchKCYCLESKINSTRIPCBRRETIREDBRMISPREDBMRLLCREFLLCMISSLLC307637365096952。129312823406200130。078408422327377461。07308637964580252。099266211706161740。0711152959438813560。65309425064873652。109321538726296230。078865611340217061。63
　　对于61的LLC命中率，您可能会猜测它介于工作负载A（10MB）和B（100MB）之间。但是不，这也是100MB。我通过使访问模式不统一来提高其LLC命中率。我们能做些什么呢？有很多PMC：用于缓存、MMU和TLB以及内存事件，所以我认为我们可以对CPU进行建模，插入所有这些数字，并让它不仅估计WSS，还估计访问模式。我还没有看到有人尝试过这个（肯定有人尝试过），所以我没有任何参考资料。它在我的待办事项清单上已经尝试了一段时间。它还涉及真正了解每个PMC：它们通常有测量注意事项。
　　以下是cpucache的屏幕截图，这是我刚刚添加到pmccloudtools中的一个新工具，它显示了其中一些额外的PMC：。cpucacheAllcountercolumnsarex1000CYCLESINSTRIPCL1DREFL1DMISSL1DL2REFL2MISSL2LLCREFLLCMISSLLC1365208859590200。4415529831299399。1619437851256。2010224430657。88707476858367830。8315212681296599。15211821038051。0013081421367。79706520758265420。8215201931290599。1519397861255。6010319411860。09〔。。。〕
　　请注意，CPU缓存通常在缓存行（例如，64字节）上运行，因此随机1字节读取的工作负载变为64字节读取，从而膨胀了WSS。虽然，如果我正在分析CPU缓存可伸缩性，我无论如何都想知道WSS的缓存行，因为这就是将被缓存的内容。
　　至少，PMC可以告诉您：
　　如果L1、L2或LLC具有100的命中率和高引用计数，则基于单线程缓存行的WSS小于该缓存，并且可能比它之前的任何缓存都大。
　　如果L2为8MB，LLC为24MB，LLC具有100的命中率和高引用计数，您可能会得出结论，WSS介于8到24MB之间。如果它小于8MB，那么它将适合L2，并且LLC将不再具有高引用计数。我说可能是，因为较小的工作负载可能由于其他原因而无法在L2中缓存：例如，设置关联性。
　　我还必须将其限定为单线程。多线程有什么问题？考虑一个运行多线程应用程序的多核多套接字服务器，其中每个线程实际上都有自己的工作集。应用程序的组合工作集大小可由多个CPU缓存缓存：多个L1、L2和LLC。它可能具有100的LLC命中率，但WSS比单个LLC大，因为它存在于多个LLC中。5。实验：CPU缓存刷新
　　只是一个想法。我找不到任何人这样做的例子，但对于CPU缓存，我想缓存刷新与PMC相结合可用于WSS估计。刷新缓存，然后测量LLC填充并再次开始逐出所需的时间。速度越慢，WSS就越小（可能）。通常有CPU指令来帮助缓存刷新，前提是它们已启用：cpuid1grepiflushCLFLUSHlinesize0x8（8）CLFLUSHinstructiontrueCLFLUSHOPTinstructiontrue
　　还可以应用此方法的其他缓存。MMUTLB可以刷新（至少内核知道如何刷新）。Linux文件系统缓存可以用procsysvmdropcaches刷新，然后通过操作系统指标（例如，免费）随着时间的推移跟踪增长。6。实验：PTE访问位
　　这些方法使用页表条目（PTE）访问位，该位通常在访问内存页时由CPUMMU更新，并且可以由内核读取和清除。这可用于提供基于页的WSS估计，方法是清除进程所有页面上的访问位，等待间隔，然后检查该位返回到的页数。它的优点是在更新访问位时没有额外的开销，因为MMU无论如何都会这样做。6。1。Linux参考页标志
　　这使用了Linux2。6。22中添加的内核功能：从用户空间设置和读取引用的页面标志的功能，为分析内存使用情况而添加。引用的页面标志实际上是PTE访问位（在Linux中PAGEBITACCESSED）。我开发了wss。pl作为此功能的前端。以下内容在MySQL数据库服务器（mysqld）PID423上使用它，并测量其工作集大小0。1秒（100毫秒）：。wss。pl4230。1WatchingPID423pagereferencesduring0。1seconds。。。Est（s）RSS（MB）PSS（MB）Ref（MB）0。107403。66400。5928。02
　　在100毫秒内，mysqld在其404MB的总主内存中触及了28MB的页面。为什么我使用了100毫秒的间隔？较短的持续时间对于了解WSS在CPU缓存（L1L2L3、TLBL1L2等）中的适应程度非常有用。在这种情况下，28MB比此CPU的LLC大一点，因此可能无法很好地缓存（无论如何，在单个LLC中）。
　　此处打印的列是：估计：估计的WSS测量持续时间：这说明了设置和读取页面图数据的延迟。RSS（MB）：驻留集大小（MB）。主内存大小。PSS（MB）：成比例的集大小（MB）。共享页面的会计处理。引用（MB）：在指定持续时间内引用（MB）。这是工作集大小指标。
　　我将在第6。7节中详细介绍估计持续时间。6。1。1。工作原理
　　它的工作原理是在内存页上重置引用的标志，然后稍后检查此标志返回到的页数。我想起了旧的Unix页面扫描器，它将使用类似的方法来查找最近未使用的页面，这些页面有资格分页到交换设备（也称为交换）。我的工具使用procPIDclearrefs和procPIDsmaps中的引用值，该值由DavidRientjes于2007年添加。他还在他的补丁中描述了内存占用估计。我只看过这个功能的另一个描述：我到底使用了多少内存？，作者是JonathanCorbet（lwn。net编辑）。我将其归类为一种实验性方法，因为它修改了系统的状态：更改引用的页面标志。
　　我之前的PMC分析将WSS四舍五入到缓存行大小（例如，64字节）。这种方法将其四舍五入到页面大小（例如，4KB），因此可能会向您显示最坏情况的WSS。对于巨大的页面，2MB的页面大小，它可能会使WSS膨胀得超出现实。但是，有时基于页面大小的WSS正是您想要的：了解存储页面映射的TLB命中率。6。1。2。警告
　　此工具使用procPIDclearrefs和procPIDsmaps，它们可以导致内核遍历页面时应用程序延迟略高（例如，10）结构。对于大型进程（100GB），此持续时间更高的延迟可能会持续1秒以上，在此期间此工具会消耗系统CPU时间。考虑这些开销。这还会重置引用的标志，这可能会使内核混淆哪个要回收的页面，尤其是在交换处于活动状态时。这也激活了一些以前可能未在您的环境中使用过的旧内核代码，以及修改页面标志：我猜存在未被发现的风险内核恐慌（Linuxmm社区也许可以说这种风险有多真实是）。在实验室环境中测试内核版本，并考虑这一点实验性：使用风险自负。
　　有关在Linux4。3上使用空闲页标志更安全的方法，请参阅第7节，该标志还跟踪未映射的文件IO内存。6。1。3。累积增长
　　这是相同的过程，但测量WSS的时间为1、10和60秒（这不会产生额外的开销，因为该工具无论如何都会休眠）：。wss。plpgrepnmysqld1WatchingPID423pagereferencesduring1seconds。。。Est（s）RSS（MB）PSS（MB）Ref（MB）1。012403。66400。7569。44。wss。plpgrepnmysqld10WatchingPID423pagereferencesduring10seconds。。。Est（s）RSS（MB）PSS（MB）Ref（MB）10。019403。66400。7580。79。wss。plpgrepnmysqld60WatchingPID423pagereferencesduring60seconds。。。Est（s）RSS（MB）PSS（MB）Ref（MB）60。068403。66400。6084。50
　　一秒钟后，此进程引用了69MB，十秒后引用了81MB，这表明在第一秒内已经引用了大部分WSS。
　　此工具具有累积模式（C），它将在其中生成滚动输出，显示工作集如何增长。这的工作原理是仅在开始时重置引用的标志一次，然后为每个间隔打印当前引用的大小。显示滚动的一秒输出：。wsspgrepnmysqld1WatchingPID423pagereferencesgrow，outputevery1seconds。。。Est（s）RSS（MB）PSS（MB）Ref（MB）1。014403。66400。5986。002。034403。66400。5990。753。054403。66400。5994。294。074403。66400。5997。535。094403。66400。59100。336。114403。66400。59102。447。134403。66400。59104。588。154403。66400。59106。319。174403。66400。59107。7610。194403。66400。59109。14〔。。。〕6。1。4。与PMC的比较
　　作为测试，我在一些大小不断增加的MySQL系统支架OLTP工作负载上运行了它。下面是oltptablesize10000：。wss。plCpgrepnxmysqld1WatchingPID423pagereferencesgrow，outputevery1seconds。。。Est（s）RSS（MB）PSS（MB）Ref（MB）1。014403。66400。7712。462。033403。66400。7712。643。043403。66400。7712。704。053403。66400。7712。795。063403。66400。7712。886。073403。66400。7712。98〔。。。〕。pmcarchKCYCLESKINSTRIPCBRRETIREDBRMISPREDBMRLLCREFLLCMISSLLC392494849009671。2598384256482990560。844901299442331299。14374150949460341。3298471235883977320。854753262447610599。00373766349033521。3198700394982192150。834808481946991999。02377295448987141。3098037386782599700。844734747044553399。06376249149157391。3198327974283208590。854803476439861699。17376467349120871。3098323726783082380。844798963947904299。00〔。。。〕
　　wss工具显示一个12MB的工作集，pmcarch显示99的LLC命中率。此CPU上的LLC为24MB，因此这是有道理的。
　　现在oltptablesize10000000：。wss。plCpgrepnxmysqld1WatchingPID423pagereferencesgrow，outputevery1seconds。。。Est（s）RSS（MB）PSS（MB）Ref（MB）1。010403。66400。5986。882。020403。66400。5990。403。040403。66400。5993。714。050403。66400。5996。195。060403。66400。5999。026。080403。66400。59100。80〔。。。〕。pmcarchKCYCLESKINSTRIPCBRRETIREDBRMISPREDBMRLLCREFLLCMISSLLC385766343615491。1387590530682704780。9457942970447885992。27367435644038511。2086967176483074500。9657444045451895592。13385882844837051。1689399231284802710。9557808518484347691。62370174443218341。1786174400281444260。9556775802445681792。15406788949320421。21994934844125708301。2663358558500130292。11370303043785431。1887432940783077690。9558147001452938892。21〔。。。〕
　　现在WSS超过80MB，这应该会破坏LLC，但是，它的命中率仅下降到92。这可能是因为访问模式是不均匀的，并且该工作集的较热区域从LLC冲击的次数比较冷的区域更大。6。1。5。工作集大小分析
　　我在wss工具中添加了一个配置文件模式，以阐明访问模式。它将采样持续时间提高2的幂。这是相同的MySQL工作负载：。wss。plP16pgrepnmysqld0。001WatchingPID423pagereferencesgrow，profilebeginningwith0。001seconds，16steps。。。Est（s）RSS（MB）PSS（MB）Ref（MB）0。008403。66400。768。790。018403。66400。7613。980。027403。66400。7617。690。038403。66400。7621。700。058403。66400。7627。830。088403。66400。7635。510。128403。66400。7643。430。209403。66400。7655。080。349403。66400。7669。950。620403。66400。7684。181。150403。66400。7686。182。190403。66400。7689。434。250403。66400。7694。418。360403。66400。76101。3816。570403。66400。76107。4932。980403。66400。76113。05
　　下面是一个合成工作负载，它通过统一的访问分布达到100MB：。wss。plP16pgrepnbench0。001WatchingPID34274pagereferencesgrow，profilebeginningwith0。001seconds，16steps。。。Est（s）RSS（MB）PSS（MB）Ref（MB）0。008201。11200。1146。290。017201。11200。11100。030。027201。11200。11100。030。037201。11200。11100。030。048201。11200。11100。030。067201。11200。11100。030。107201。11200。11100。030。177201。11200。11100。030。318201。11200。11100。030。577201。11200。11100。031。098201。11200。11100。032。128201。11200。11100。034。188201。11200。11100。038。298201。11200。11100。0316。508201。11200。11100。0332。918201。11200。11100。03
　　这为WSS的不同用途提供了信息：研究WSSCPU缓存的持续时间较短，研究主内存驻留的持续时间较长。
　　由于工作负载可能会有所不同，请注意，这只是显示工具运行时的WSS增长。您可能需要多次收集此配置文件，以确定正常的WSS配置文件的外观。6。1。6。WSS配置文件图表
　　绘制前两个配置文件的图形：
　　请注意，我使用了对数x轴（这里是线性版本）。一个陡峭的斜率，然后是一个平坦的轮廓是我们对均匀分布的期望：初始测量尚未达到其WSS，因为间隔太小，并且没有足够的CPU周期来接触所有页面。至于mysqld：需要更长的时间才能稍微平衡一点，它在16毫秒后达到80MB，然后在256毫秒时再次拾取并爬升更多。看起来80MB比其他的更热。由于工作负载可以逐秒变化，因此我不会相信单个配置文件：我想将几个配置文件绘制在一起，以寻找趋势。
　　上面均匀分布的尖锐斜率只有一个数据点。这是一个2GB的WSS，也是一个均匀分布，程序引用需要更长的时间，为我们提供了更多的绘图点：
　　它向上弯曲，因为它是一个对数轴。这里是线性（缩放）。虽然看起来很有趣，但此曲线仅反映WSS样本持续时间，而不是访问分布。分布确实是均匀的，如大约0。3秒后的平线所示。此图中的拐点显示了我们可以识别此WSS和程序逻辑的统一访问分布的最小间隔。超出此点的配置文件反映了访问分布。超出此点的配置文件反映了访问分布，并且对于了解主内存使用情况很有意思。它前面的配置文件很有趣，原因不同：了解CPU缓存在短时间间隔内处理的工作负载。6。1。7。估计持续时间和准确性
　　以下是您可能想象此工具的工作方式：重置进程的引用页面标志（瞬时）睡眠时间读取引用的页面标志（瞬时）
　　以下是实际发生的情况：重置进程的第一页标志〔。。。重置下一页标志，然后是下一页，然后是下一页，依此类推。页面标志重置完成睡眠一段时间阅读流程的第一页标志〔。。。阅读下一页标志，然后是下一页，然后是下一页，等等。阅读完成
　　工作集只应在步骤4（预期的持续时间）中测量。但是在步骤2中设置标志之后，以及在步骤4中开始持续时间之前，应用程序可以触摸内存页。步骤6中的读取也会发生同样的情况：在检查标志之前，应用程序可能会在此阶段触摸内存页。因此，步骤2和6有效地增加了睡眠持续时间。大型进程（100GB）的这些阶段可能需要超过500毫秒的CPU时间，因此10毫秒的目标持续时间实际上可能是反映100毫秒的内存变化。
　　为了通知最终用户此持续时间膨胀，此工具提供了一个估计持续时间，从第2阶段的中点到阶段的中点第6阶段。对于小型进程，此估计持续时间可能等于预期持续时间。但是对于大型过程，它会显示膨胀的时间。6。1。8。精确的工作集大小持续时间
　　我已经尝试了一种获得精确持续时间的方法：发送目标过程SIGSTOP和SIGCONT信号，以便在设置和读取页面地图时暂停它，并且仅在预期的测量持续时间内运行。这很危险6。2。实验：Linux空闲页面标志
　　这是VladimirDavydov在Linux4。3中添加的一种较新的方法，它引入了Idle和Young页面标志，用于更可靠的工作集大小分析，并且没有缺点，例如使用引用的标志可能会混淆内核回收逻辑。JonathanCorbet再次写过这个主题：跟踪实际内存利用率。Vladimir称之为空闲内存跟踪，不要与多年前的空闲页面跟踪补丁集混淆，后者在sys中引入了用于页面扫描和摘要统计信息的kstaled（未合并）。
　　这仍然是一种PTE访问位方法：这些额外的空闲和年轻标志仅在内核的扩展页表条目（pageextflags）中，用于帮助回收逻辑。
　　使用空闲内存跟踪需要更多。从内核文档vmidlepagetracking。txt：Thatsaid，inordertoestimatetheamountofpagesthatarenotusedbyaworkloadoneshould：1。Markalltheworkloadspagesasidlebysettingcorrespondingbitsinsyskernelmmpageidlebitmap。Thepagescanbefoundbyreadingprocpidpagemapiftheworkloadisrepresentedbyaprocess，orbyfilteringoutalienpagesusingprockpagecgroupincasetheworkloadisplacedinamemorycgroup。2。Waituntiltheworkloadaccessesitsworkingset。3。Readsyskernelmmpageidlebitmapandcountthenumberofbitsset。Ifonewantstoignorecertaintypesofpages，e。g。mlockedpagessincetheyarenotreclaimable，heorshecanfilterthemoutusingprockpageflags。
　　我已经编写了两个使用它的概念验证工具，它们在wss集合中。6。2。1。WSSv1：小流程优化
　　此工具的此版本逐个遍历页面结构，仅适用于小型进程。在大型进程（100GB）上，此工具可能需要几分钟才能写入。请参阅wssv2。c，它使用页面数据快照，对于大型进程（50倍）要快得多，以及wss。pl，它甚至更快（尽管使用引用的页面标志）。
　　下面是一些示例输出，将此工具与前面wss。pl进行比较：。wssv1335830。01WatchingPID33583pagereferencesduring0。01seconds。。。Est（s）Ref（MB）0。05510。00。wss。pl335830。01WatchingPID33583pagereferencesduring0。01seconds。。。Est（s）RSS（MB）PSS（MB）Ref（MB）0。01121。0720。1010。03
　　输出显示该进程引用了10MB的数据（这是正确的：它是一个合成工作负载）。
　　列：估计：估计的WSS测量持续时间：这说明了设置和读取页面图数据的延迟。引用（MB）：在指定持续时间内引用（MB）。这是工作集大小指标。6。2。2。WSSv1警告
　　此工具设置和读取流程页面标志，对于大型进程（100GB）可能需要几分钟时间（使用WSSv2相反）。在此期间，此工具会消耗一个CPU，并且应用程序潜伏期可能略高（如5）。考虑这些开销。此外，这是激活Linux4。3中添加的一些新内核代码，您可能以前从未执行过。与任何此类代码一样，存在未发现的内核恐慌的风险（我没有具体的理由担心，只是偏执）。在实验室环境中测试内核版本，并考虑这个实验性：使用风险自负。6。2。3。WSSv2：大型流程优化
　　此工具的此版本可拍摄系统空闲页面标志的快照，从而加快对大型进程的分析，但不能加快对小型进程的分析。请参阅wssv1。c，对于小型进程可能更快，以及wss。pl，它甚至更快（尽管使用引用的页面标志）。
　　下面是一些示例输出，将此工具与wssv1（运行速度慢得多）以及较早的wss。pl进行比较：。wssv2273570。01WatchingPID27357pagereferencesduring0。01seconds。。。Est（s）Ref（MB）0。80615。00。wssv1273570。01WatchingPID27357pagereferencesduring0。01seconds。。。Est（s）Ref（MB）44。57116。00。wss。pl273570。01WatchingPID27357pagereferencesduring0。01seconds。。。Est（s）RSS（MB）PSS（MB）Ref（MB）0。08020001。1220000。1415。03
　　输出显示该进程引用了15MB的数据（这是正确的：这是一个合成工作负载）。
　　列：估计：估计的WSS测量持续时间：这说明了设置和读取页面图数据的延迟。引用（MB）：在指定持续时间内引用（MB）。这是工作集大小指标。6。2。4。WSSv2警告
　　此工具设置和读取系统和进程页面标志，这可以占用超过一秒钟的CPU时间，在此期间应用程序可能会遇到潜伏期稍高（如5）。考虑这些开销。另外，这是激活Linux4。3中添加的一些您可能从未添加过的新内核代码之前执行。与任何此类代码一样，存在以下风险：未发现的内核恐慌（我没有具体的理由担心，只是偏执狂）。在实验室环境中测试内核版本，并考虑此实验性：使用风险自负。7。实验：MMU无效
　　此方法会使MMU中的内存页失效，以便MMU在下次访问时出现软故障。这会导致加载存储操作将控制权交给内核以处理故障，此时内核只需重新映射页面并跟踪它被访问。它可以由内核或用于监视来宾WSS的虚拟机管理程序来完成。7。2。窗口参考集
　　微软有一个很棒的页面：参考集和系统范围对内存使用的影响。一些术语差异：Linux驻留内存Windows工作集Linux工作集Windows参考集
　　此方法使用WPR或Xperf来收集引用集，这是对访问页面的跟踪。我自己还没有做过这些，但它似乎使用MMU失效方法，然后是页面错误的事件跟踪。该文档记录了开销：
　　警告：记录引用集的跟踪可能会对系统性能产生重大影响，因为所有进程都必须在其工作集清空后将大量页面错误地返回到其工作集中。
　　一旦我使用它，我将更新此页面以提供更多详细信息。到目前为止，这些是我见过的唯一工具（除了我写的工具）来进行WSS估计。其他
　　WSS估计的其他技术包括：应用程序指标：这取决于应用程序，但有些可能已经跟踪正在使用的内存作为WSS近似值。应用程序修改：我已经看到过这方面的研究，其中修改了应用程序代码以跟踪正在使用的内存对象。这可能会增加大量开销，并且需要更改代码。CPU模拟：跟踪负载存储。应用在此类模拟器中的运行速度可以慢10倍或更多。内存断点：例如调试器可以配置的断点。我预计会有巨大的开销。内存观察点：可以构建一种方法来使用这些；观察点最近得到了BPFtrace的支持。MMU页面失效：强制页面在访问时出错，揭示正在使用的页面。这可以由内核或用于监视来宾WSS的虚拟机监控程序来完成。处理器跟踪：以及可以记录加载存储的类似处理器级功能。处理日志的预期开销很高。内存总线侦听：使用物理连接到内存总线的自定义硬件和软件来汇总观察到的访问。
　　我没有看到的是用于进行WSS估计的现成通用工具。这就是促使我基于Linux引用和空闲页面标志编写wss工具的原因，尽管每个工具都有自己的警告（尽管不像其他方法那么糟糕）。
　　地址：https：www。brendangregg。comwss。html