作者: remaper
AIFM – High-Performance, Application-Integrated Far Memory
- 更低的延迟:相比 fastswap,有6倍吞吐的提升
- 更高的灵活性:用户可以显式指定一块内存是local还是far(指向 remote memory)
1. 一些背景
Distributed Shared Persistent Memory
1. 场景
2. DSPM 的挑战
Mix Precision Training 混合精度训练
- Binaryconnect: Training deep neural networks withbinary weights during propagations @2015
- Binarized neural networks. InAdvances in Neural Information Processing Systems @2016
1. 背景
Year
|
Name
|
Param
|
From
|
2018
|
110M
|
OpenAI
|
|
2018
|
349M
|
Google
|
|
2020
|
175B
|
OpenAI
|
|
2022
|
540B
|
Google
|
2. 实现
- 大幅减少内存消耗:50%?
- 运算加速,FP16肯定要比FP32要快
Singularity:Planet-Scale, Preemptive and Elastic Scheduling of AI Workloads
摘要
原文:https://arxiv.org/pdf/2202.07848.pdf
Singularity,微软的全局分布式调度服务,用于高效可靠地执行深度学习训练和推理工作负载。Singularity 的核心是一种新颖的、负载感知的调度器,它可以透明地抢占深度学习工作负载以及进行弹性伸缩,在不影响AI加速器(如 GPU、FPGA)的正确性和性能的前提下,提高利用率。
Singularity中的所有作业默认都是可抢占、可迁移、可动态调整(弹性)大小的:一个运行的作业可以动态透明地:
(a) 被抢占并迁移到不同的节点、集群、数据中心或区域,并从执行被抢占的位置恢复;
(b) 在给定类型的不同加速器上弹性伸缩resize;
我们的机制是透明的,因为它们不需要用户对代码做任何更改,也不需要使用任何可能限制灵活性的自定义库。此外,我们的方法显著提高了深度学习工作负载的可靠性。
结果表明,Singularity 提高了系统的效率和可靠性,对稳态性能的影响可以忽略不计。而且,Singularity 的设计与 DNN 架构无关,可以处理各种并行策略(例如,数据/管道/模型并行)。
1. 简介
Singularity 核心实现了 AI 任务的可抢占、可迁移、可动态调整,并且该实现与模型架构无关、与模型训练的并行策略无关,可以认为做到了用户无感。
1.1. 设计目标
Singularity 为了最大化整个集群的吞吐量,采用以下设计原则:
- 不闲置资源:Singularity 将整个加速器集群视为单个逻辑共享集群,并避免任何资源碎片化或静态容量预留。Singularity 适时调度使用全球范围内的任何空闲资源,跨集群、AZ和工作负载边界(训练与推理)。
- 提供作业级别的 SLA:在适时使用空闲容量的同时,Singularity 通过遵守作业级别的 SLA 来提供隔离。例如,当推理作业的负载增加时,Singularity 通过弹性缩小或抢占训练作业来释放容量。
- 故障弹性恢复:DNN 训练作业运行时间长达数小时、数天甚至数周,因此从头开始成本损失巨大。在 Singularity 中,作业从它们被抢占的地方恢复,从而将故障重启成本最小化。
1.2. 关健机制
为实现上面的目标,整个 Singularity 系统的底层由两大重要的机制来支撑。它们分别是:
1) 抢占和迁移机制:Singularity 可以透明地设置检查点、抢占和迁移节点间甚至跨集群和区域的所有 DNN 作业。检查点是通过高效的的同步屏障 (synchronization barrier) 来实现分布式作业的所有参与者之间分布式状态的 一致性切分 (consistent cut)。
2) 伸缩和弹性机制:Singularity 使所有工作能够使用可变数量的 AI 加速器,以透明的方式 动态地、弹性地 伸缩资源。
Singularity 系统架构
- 这里涵盖了所有的 AI 算力,包括 GPU、FPGA、CPU、ASIC 等不同的硬件形态。
- 所有的算力资源都被容器化了
- 硬件抽象层(HAL)竟然 在一层基础软件之上,这层基础软件包括 NVML、NCCL、CUDA,也就是设备管理、设备通信、设备计算这三类功能。
- 硬件抽象层这里的 CUDA 指的是 CUDA Driver API f. 核心调度原语。高层原语包括:Failover、Suspend、Resume、Migrate、Scale Up/Down ,底层原语包括:Checkpoint、Restore、Distributed Barrier 。
vm template 原理浅析
1. 背景
2. vm template 原理
RunD – A Lightweight Secure Container Runtime
1. 设计目标
2. 问题分析
2.1 并发启动的开销
2.2 高密部署的瓶颈
kata 系统架构解读
https://github.com/kata-containers/kata-containers/tree/main/docs/design/architecture
https://github.com/kata-containers/kata-containers/tree/main/docs/design
1. 整体架构
如下图:
kata-containers 的核心 binary 就2个:
- containerd-shim-kata-v2,对应源代码目录 src/runtime
- kata-agent,对应源码目录 src/agent
containerd 实现了 cri 协议,可以天然直接无缝对接到 kublet 上,而 containerd-shim-kata-v2 实现了 containerd 的 shim-v2 协议,直接实现了对 kata-agent 以及 hypervisor 通讯的封装。
nr_dying_descendants 引发的在线业务性能抖动
最近发现一则比较奇怪的业务性能抖动问题
简单来说,就是离线作业频繁的触发oom,导致在线业务指标陡增。理论上来说,离线作业触发自身硬限,不应该导致其他容器出问题才是
先来说一下我们的 memory cgroup 层级结构,可以简单理解为如下:
/cgroups/v2/kubepods/
/cgroups/v2/kubepods/online/a -> a为在线服务
/cgroups/v2/kubepods/offline/job1 -> job1 为离线服务
通常来说,为了解决混部的内存争抢问题,我们会对整个 offline 大框设置一个内存上限,防止离线作业使用内存太多,导致在线服务出现内存压力。这看起来似乎没什么问题。
不过最近一个问题,发现离线 job1 频繁 oom,引发了在线的性能抖动
最后定位的结论如下:
- /cgroups/v2/kubepods/offline/cgroup.stat 下看到有大量的 nr_dying_descendants
- offline 大框频繁出发 oom
- oom 的回收过程有个效率不太好的地方,导致 oom 回收效率底下 -> 导致内核各种锁争抢严重 -> 进程sys高 -> cpu排队严重 -> 在线业务性能抖动
根因分析:nr_dying_descendants 的原因是由于容器被销毁时,容器内还有未完全回收干净的 page cache,所以内核不会立即释放这个 cgroup(用户态操作系统从 /cgroups 文件系统下已经看不到了,但是内核态的数据结构还在)
cat /cgroups/v2/kubepods/online/cgroup.stat
nr_descendants 10
nr_dying_descendants 4172
这就有一个问题,如果有大量的dying cgroups,内核在oom处理过程中:
- 如果是cgroup oom,会优先尝试从 dying cgroups 回收内存,但是最多只回收5个 -> 这个地方有效率问题
- 如果是整机回收,不处理dying cgroups内存
TMO – Transparent Memory Offloading in Datacenters
1. INTRODUCTION
- google的方案,g-swap
- facebook的方案,tmo
- 核心是压缩
- 非常简单
- 好处:不用解决异构这些复杂的问题(感觉解决了?做了负载分类)
- 坏处:不利于最大化的 memory-cost saving
- promotion rate 的设定依赖离线分析
- 所有应用的 promotion rate 是一样的。没有考虑不同业务对内存的敏感性,以及不同分层设备的 performance(后者其实有简单的考虑,具体的 P% 的设备就取决于 far memory 到 near memory 的性能表现)
- g-swap的观点:为了保证应用程序的性能,memory offloading 应该控制在一个预先配置好的比例下面
- tmo的观点:facebook 对它们部署规模最大的程序,发现,在一些高速设备上,提高 memory offloading 比例,可以提高性能。 –> 反人类假设??
- 核心是卸载(但是卸载的backend 支持 compressed memory pool,也支持 NVMe SSDs)
- 不需要离线分析,依赖 PSI 的反馈,直接单机决定不同的 offloading 比例。不依赖app的任何先验知识(g-swap的方案就有一个冷启动问题,新app默认不回收任何内存)
- PSI accounts for application’s sensitivity to memory-access slowdown(这里其实是比较误导的,facebook认为psi观测出来的内存延迟一定是对业务敏感的,但是实际上不同的业务对延迟的敏感性是不一样的,简单来说这个是充分不必要条件)