互动平台网站建设营销渠道的三个类型

互动平台网站建设,营销渠道的三个类型,淄博网站建设企业,四川建设厅电话网站背景 在云原生场景中#xff0c;为了最大化资源利用率#xff0c;越来越多的集群采用资源超卖策略和混合部署方式。然而#xff0c;这种模式在提升集群效率的同时#xff0c;也显著增加了宿主机与容器化应用之间的资源竞争风险。 在资源紧张的场景中#xff0c;CPU 延时…背景在云原生场景中为了最大化资源利用率越来越多的集群采用资源超卖策略和混合部署方式。然而这种模式在提升集群效率的同时也显著增加了宿主机与容器化应用之间的资源竞争风险。在资源紧张的场景中CPU 延时和内存申请延迟Memory Reclaim Latency等内核级延迟问题往往会直接传导至应用层造成响应时间RT波动甚至引发业务抖动。对于依赖低延迟和稳定性的关键业务而言这类问题可能意味着性能瓶颈、用户体验下降甚至业务中断。然而现实中由于缺乏足够的可观测性数据工程师通常很难将应用层抖动与系统层面的延迟精确关联排查效率低下。为了解决这一挑战本文将结合实战案例介绍如何在 Kubernetes 环境中使用 ack-sysom-monitor Exporter [1]对内核延迟进行可视化分析与定位帮助你快速识别问题根因并高效缓解由延迟引发的业务抖动。内存申请延时进程陷入内存分配的慢速路径往往是造成业务时延抖动的元凶之一。如下图所示在进程内存分配的过程中如果系统或容器内存达到了low 水线会触发系统内存的异步回收kswapd 内核线程回收如果剩余内存进一步低于 min 水线就会进入直接内存回收direct reclaim和直接内存规整direct compact阶段这两个动作正是可能引起长业务进程时间延时的罪魁祸首。直接内存回收是指进程在申请内存的过程中由于内存紧缺进程被迫阻塞等待内存的同步回收。直接内存规整是指进程在申请内存的过程中由于内存碎片太多进程被迫阻塞等待内核将内存碎片规整成连续可用的一片内存。因为直接内存回收和规整的过程可能会消耗一定的时间所以进程会阻塞在内核态造成长时间的延时和 CPU 利用率的升高从而导致系统负载飙高和业务进程的延时抖动。图 Linux内存水线CPU 延时CPU 延时是指从任务变为可运行状态即它已准备好运行不再受阻塞到它真正被操作系统调度器选中并执行的时间间隔。长时间的 CPU 延时可能会对业务造成影响如网络数据包到达后业务进程没有被及时调度运行进行收包从而导致网络延时等。延时抖动场景常见 caseCASE1: 容器内存紧张导致容器内应用抖动容器启动时设置了内存限制Limit。当容器内进程申请内存且容器内存使用量达到容器内存限制时容器内进程就会发生直接内存回收和规整导致应用阻塞。CASE2: 宿主机内存紧张导致容器内应用抖动虽然容器内存富余但容器所在宿主机内存紧张。当容器内进程申请内存且节点内存可用内存低于节点 min 内存水位时容器内进程就会发生直接内存回收CASE3: 就绪队列等待时间长导致应用抖动应用进程被唤醒进入就绪队列但是由于就绪队列较长当前 CPU 存在阻塞任务等原因导致长时间没有被调度至 CPU 运行导致应用抖动。CASE4中断阻塞时间长导致应用抖动当系统资源紧张或发生资源争抢时大量网络等软件中断或硬件中断会持续触发。此时内核处理这些中断的耗时会显著增加导致 CPU 长时间被内核占用。应用程序在运行系统任务时需要争夺同一个锁但此时锁资源长期被占用无法释放最终引发进程卡死。CASE5内核路径持锁阻塞引发网络抖动延时当进程通过系统调用进入内核态执行路径后由于路径中可能涉及访问大量系统资源从而长时间持有内核自旋锁当某个 CPU 在持有自旋锁后便可能关闭当 CPU 中断和不再发生调度从而导致内核 ksoftirq 软中断无法正常调度收包从而引发网络抖动。如何识别解决系统抖动延时ACK 团队与操作系统团队合作推出了 SysOMSystem Observer Monitoring 操作系统内核层的容器监控的产品功能目前为阿里云独有通过查看 SysOM 容器系统监控 -None 和 Pod 维度中的相关大盘可以洞悉节点和容器的抖动延时。内存申请延时查看SysOM 容器系统监控-容器维度中的Pod Memory Monitor 中的Memory Global Direct Reclaim Latency和Memory Direct Reclaim Latency 和 Memory Compact Latency 监控大盘可以直观地观察到 pod/ 容器中的进程因为发生直接内存回收和直接内存规整而被阻塞的时长。查看SysOM 容器系统监控-节点维度中的 System Memory 中的 Memory Others 大盘可以观察到节点上是否发生了直接内存回收。具体指标解析Memory Others该大盘中的 pgscan_direct 折线表示节点中在直接内存回收阶段扫描的页数只要该折线的数值不为 0说明在节点中发生了直接内存回收。Memory Direct Reclaim Latency该大盘表示当前采样点与上一采样点由于容器内存使用量达到容器内存限制或者节点内存可用内存低于节点内存水位导致的容器中发生的直接内存回收在不同阻塞时长的次数增量如 memDrcm_lat_1to10ms 表示直接内存回收延时时间在 1-10ms 的增量次数。memDrcm_glb_lat_10to100ms 表示直接内存回收延时时间在 10-100ms 的增量次数。Memory Compact Latency该大盘表示当前采样点与上一采样点由于节点内存碎片太多导致的容器中无法申请连续内存而发生的直接内存规整次数增量。问题解决内存回收延时最直接的原因就是节点/容器内存资源紧张。要优化内存使用就需要看清内存和用好内存要看清内存可以通过阿里云操作系统控制台推出的功能-节点 /Pod 内存全景分析[2]该功能对节点 /Pod 使用的内存进行了详细的拆解细粒度到每个 Pod 的详细内存组成。通过 Pod Cache缓存内存、InactiveFile非活跃文件内存占用、InactiveAnon非活跃匿名内存占用、Dirty Memory系统脏内存占用等不同内存成分的监控展示发现常见的 Pod 内存黑洞问题。要用好内存可以通过 ACK 容器服务团队推出 Koordinator QoS 精细化调度功能[3]通过精细化调整容器的内存水线提早进行异步回收缓解直接内存回收带来的性能影响。CPU 延时监控查看SysOM 容器系统监控-节点维度中的 System CPU and Schedule 大盘具体指标解析WaitOnRunq Delay该大盘表示系统中所有可运行进程在运行队列中等待运行的时间的平均值通过该大盘用户可以了解到系统中是否存在调度延时情况如果存在超过 50ms 的毛刺就可以说明系统中存在比较严重的调度延时大部分进程都无法得到及时的调度。Sched Delay Count该大盘表示系统没有发生调度的时间分布统计。如 SchedDelay 100ms 表示系统中有 100ms 没有发生调度的次数统计。如果观察到 SchedDelay 100ms 折线发生了陡增那么可以说明系统中发生了长时间不调度系统上的业务进程可能因为得不到调度而受到影响。问题解决造成系统调度延时的原因有很多如在 CPU 中运行的任务在内核态运行时间过长当前 CPU 出现长时间的关中断等。如果需要进一步定位产生调度延时的具体原因可以使用阿里云操作系统团队推出的产品-阿里云操作系统控制台中的调度抖动诊断[4]进行进一步的根因分析。案例分析 - 快速定位由 CPU 延时导致的网络抖动背景某金融行业客户在ACK上创建的集群中某两个节点中业务pod连接redis经常出现连接失败报错在经过网络同学的初步排查后基本可以锁定是由于节点内核收包慢延时500ms导致redis客户端断开连接。问题识别定位1. 通过查看网络抖动应时间的 Sched Delay Count 大盘可以看到在对应的时间点中伴随着多次 1ms 以上的 sched delay这说明了系统中这个时间点发生多次某个 CPU 不发生调度 500ms 以上那么很有可能 ksoftirq 得不到调度从而引发了网络延时抖动。2. 通过操作系统控制台的节点异常详情我们可以看到发生了调度抖动异常和 cgroup 泄漏异常3. 查看操作系统控制台中的调度抖动诊断的诊断报告获得了如下图的诊断报告4. 结合抖动诊断和 cgroup 泄漏异常基本可以确定是 memory cgroup 泄漏且 kubelt 访问 memory cgroup 的 memory.numa_stat 文件时由于 numa_stat 中的数据在 Alinux2 内核中多次遍历 cgroup 层级导致调度抖动进而影响 softirq 收包。5. 最后结合操作系统团队的 memory cgroup 泄漏工具分析可以确定由于客户使用 cronjob 定时拉起容器读取日志导致 cgroup 泄漏容器创建时会创建一个新的mem cgroup读取文件会产生page cache并统计在该cgroup中容器退出后由于page cache未释放使当前cgroup处于僵尸状态未被完全清除。问题解决所以问题从解决网络抖动变为了解决 memory cgroup 泄漏问题1、临时止血方法通过 drop cache 回收 page cache从而使对应的僵尸 cgroup被正常清除。2、使用 Alinux 的自研特性开启僵尸 cgroup 回收功能具体使用可参考[5]中“回收 zombie memcgs”章节。您在使用操作系统控制台功能的过程中有任何疑问和建议可以加入钉钉群群号94405014449反馈欢迎大家入群交流。参考链接[1]SysOM 内核层容器监控https://help.aliyun.com/zh/ack/ack-managed-and-ack-dedicated/user-guide/sysom-kernel-level-container-monitoring?spm5176.12818093_47.console-base_help.dexternal.5adc2cc9tyH8cMscm20140722.S_help%40%40%E6%96%87%E6%A1%A3%40%402560259.S_BB2%40bl%2BRQW%40ag0%2BBB1%40ag0%2Bos0.ID_2560259-RL_acksysom-LOC_console~UND~help-OR_ser-PAR1_2150446b17585225858645349e5d87-V_4-P0_0-P1_0[2]操作系统控制台内存全景分析https://help.aliyun.com/zh/alinux/user-guide/memory-panorama-analysis-function-instructions?spma2c4g.11186623.help-menu-2632541.d_2_0_1_0_0_0.38175c4dMUXuc5scm20140722.H_2848894._.OR_help-T_cn~zh-V_1[3]容器内存 QoShttps://help.aliyun.com/zh/ack/ack-managed-and-ack-dedicated/user-guide/memory-qos-for-containers[4]阿里云操作系统控制台调度抖动诊断https://help.aliyun.com/zh/alinux/user-guide/scheduling-jitter-diagnosis?spma2c4g.11186623.help-menu-2632541.d_2_0_1_0_3_0.2020583fVqI7fUscm20140722.H_2848564._.OR_help-T_cn~zh-V_1[5]龙蜥操作系统资源隔离使用简介https://openanolis.cn/sig/Cloud-Kernel/doc/659601505054416682[6]阿里云操作系统控制台PC端链接https://alinux.console.aliyun.com/