老铁们，大家好，相信还有很多朋友对于抖音cpu直播和直播cpu推荐的相关问题不太懂，没关系，今天就由我来为大家分享分享抖音cpu直播以及直播cpu推荐的问题，文章篇幅可能偏长，希望可以帮助到大家，下面一起来看看吧！
直播OOM问题比较棘手难以定位，主要体现在涉及的业务很多，从定位到解决花费时间比较久。为了提前触达问题，提高定位的效率，也是对现有工具的补充，提出直播内存抖动解决方案-MemoryThrashing。
为什么要提出这个方案？
现有的“MemoryGraph”工具可以通过抓取的“MemoryGraph”文件分析OOM成因，比如内存泄漏、内存占用过高导致的OOM问题，但因为性能开销很大，所以是采样上报且采样率很低，不容易触达问题，只能定向对已知用户开启才行。期望自研一个工具，在内存增长时可以发现问题，也能用于OOM发生后的分析，同时具备性能开销小、全采样的能力；“MemoryGraph”生成时可能不是内存高位，比如设备内存是4G，生成的“MemoryGraph”可能是1G，会影响OOM分析；
什么是Thrashing（抖动）？
维基百科中thrashing定义:
Incomputerscience,thrashingoccurswhenacomputer'svirtualmemoryresourcesareoverused,leadingtoaconstantstateofpagingandpagefaults,inhibitingmostapplication-levelprocessing.([1])Thiscausestheperformanceofthecomputertodegradeorcollapse.
从业务视角定义内存thrashing：
通俗讲就是性能数据有大的波动，拿内存来讲，当内存短时间从600M涨到800M叫作一个抖动。希望通过自研工具找出这200M内存增长来自于哪里，在实际的OOM案例中因内存突增导致的OOM是比较常见的，具体现象如下：
内存未回落：内存突增一般发生在一两分钟内，内存从1G涨到3G，这部分内存会一直滞留在内存中不会被释放掉或者没有机会释放掉直接OOM，同时助高了内存水位很容易发生OOM问题；内存回落：内存突增到一定水位开始回落未形成OOM，这种现象通常是内存问题不够劣化，或者机器本身内存足够大不容易OOM，虽然没有造成OOM但也是一个潜在的问题；
以临时对象、内存堆积为例来阐述如何定位该类问题，通过“AllocTimeSummary”描述临时对象分配次数，通过“MemorySummary”描述内存堆积。
临时对象
临时对象：短时间分配大量对象，导致直播稳定性波动较大，可能使内存、CPU负载变高。这类问题通常表现为短时间内存冲高或者直接OOM，或之后开始迅速回落到正常水位，这类对象不会驻留内存过久，通过监控“临时对象”可以提前发现这类问题。
以上是按分配次数（AllocTimeSummary）统计的TOP临时对象，“AllocTimeSummary1”代表第一次采样Class的分配次数其它依次类推。举例：通过diff“AllocTimeSummary2”与“AllocTimeSummary1”差值可知“LivexxxA”在采样周期分配了7803次，由于未采集到“MemorySummary”信息，可认为未有内存驻留。
内存堆积
内存堆积：内存驻留了大量对象，而且这类对象短时间不会释放掉，导致内存水位居高不下，很容易触发OOM问题。
以上是按内存驻留统计的TOP实例，“MemorySummary1”代表第一次采样实例数量的内存驻留信息其他依次类推。举例：通过diff“MemorySummary2”与“MemorySummary1”可知“LivexxxA”在采样周期内增长了56791个，根据最后一次采样可知内存驻留了总共69904个实例，通过采样可知“LivexxxA”每次都是递增的。
MemoryThrashing方案
方案调研
方案思路是做内存差值找出增长，通过采样多个时刻的内存信息（目前主要监控Class的实例个数），Diff出内存信息找出TOP增长，达到归因的目的。
内存区：通过内存节点遍历统计Class实例个数；Runtime：通过alloc、dealloc计数实现统计实例存活数量；
内存区
通过内存节点遍历与已注册的Class比较统计实例个数，该方案的优点是可以监控整个APP的OC对象实例个数，面对直播业务场景需不需监控整个APP的对象，目前看暂时用不到，需求出发点是监控直播场景且满足一定条件。比如：直播观播一段时间后内存的大幅波动，场景比较聚焦。另一个考虑是如果当前内存比较大，遍历zone会比较耗时，如果不挂起线程会有潜在的崩溃问题、以及数据不准问题。
RunTime
通过Hook的方式，统计Class实例的分配、释放次数，达到记录实例存活个数的目的，可监控固定场景的OC实例增长情况，如直播间内的内存突增，范围比较小不需要统计过多的无用对象。该方案相对内存区遍历耗时小，且不会有野指针问题。但需要注意的是监控对象时对性能的影响，目前采用的是RunTime方案，从线下直播间测试情况看对主线程的影响忽略不计。
方案设计
在实际开发过程中发现对象的创建、释放处于复杂的多线程环境中，处理不当会对业务产生潜在的影响，影响到业务执行效率或者造成稳定性问题：
容器置于多线程下会有线程安全问题；过度的使用锁会阻塞业务代码执行，也可能触发Watchdog机制导致APP被kill；
经过优化采用多级缓存方案解决主线程的性能开销问题，达到主线程几乎零开销。
监控流程
在进入直播间一段时间后开启监控，通过监控内存值变化来区分是否开启采样功能，开启采样后会进入连续多次采样阶段，多次采样完成后进行数据上报，上报完成后会继续监控内存。
数据展示
在高热直播间多次采样的内存快照，采集TOP100数据，以“LivexxxA”为例两次采样中第二次增长了4125个实例，可以简单归因“LivexxxA”相关业务导致“MemoryThrashing”，可以从“LivexxxA”相关业务入手排查。
方案优缺点
方案
优点
缺点
“MemoryThrashing”
可以多次采样，对比内存增长趋势；性能开销小，可线上全量；提前感知内存问题；上手简单，通过对象数量就可以排查问题；
不支持多语言，只限于oc语言；不具备通过内存节点关系分析内存泄漏问题，只能找出堆积的对象；不具备分析多个内存区的能力；Hook方式影响方法缓存；
“MemoryGraph”
问题发现能力强：可以通过内存节点关系分析内存泄漏导致的OOM问题；可以统计内存区的内存占用情况；适用多语言；上手复杂，需要梳理内存节点引用关系；
线程挂起会影响业务执行，用户感知明显；内存使用越高，内存区遍历越耗时；只能少量采样；
实践案例
目前“MemoryThrashing”已经部署了，可以监控测试环境，后续将部署到线上。通过线下看提前暴露了很多问题，相对以往方式只有问题发生了或者产生了明显影响才能感知到，需要QA反馈到RD，通过“MemoryThrashing”大大提升了排查效率，很好的将劣化问题前置发现，以下抽取其中两个案例。
内存堆积
如下，多个采样周期内出现了大量对象的分配问题，且这些对象未释放，并且导致了内存明显上涨，采样周期3比采样周期2多分配了234024个对象，且最后内存驻留了238800个“LivexxxBigDataRead”对象，占用内存10.9M。
临时对象
如下，是开播场景抓到的问题，在主播端开启弹幕狂欢时，过Effect认出人脸后，就会创建一个对应的轮廓模型给到中台去画轮廓，频率会很高，每5秒周期（实际时间更小）临时对象增量高峰可到6w个（后两次采样差值），由于未生成“MemorySummary”信息可认为未驻留内存，累计过百万次对象分配，对开播性能会产生直接影响：
未来规划
归因能力
只统计OC对象数据在某些情况下可能不够，比如公共基础对象异常增长，则没有办法追踪到具体成因，如果带有对象引用关系可以进一步锁定问题。当然这些都是对“MemoryGraph”能力的补充，如果“MemoryGraph”已经抓到了数据，可以结合“MemoryGraph”锁定对象引用链路继而找到业务。
“MemoryThrashing”可以加上对象引用关系计算，从效率上讲没必要对所有的对象查找其引用关系，查找引用关系是比较耗时的。只需查找TOP增长点的关键对象引用关系，实测可能只需要查找几个对象的引用关系。通过线程堆栈采样记录信息；
关于本次抖音cpu直播和直播cpu推荐的问题分享到这里就结束了，如果解决了您的问题，我们非常高兴。