overlayfs 差分文件系统原理

Posted on by remaper in 容器核心技术
overlay文件系统的主要目的是要实现文件系统重叠，docker中的查分机制所依赖的文件系统分层就是依赖这种技术来实现的

1. upper and lower

overlay机制允许将两个文件系统重叠成一个文件系统，其中一个是upper，另一个是lower，对用户的可视顺序是：
upper -> lower
简单来说，如果upper和lower同时存在一个相同的文件，那么用户看到的是upper中的文件，lower中的同路径文件会被自动隐藏
overlay只关心文件，目录是会被穿透的，所以严格来说，overlay重叠的是目录树，而不是“文件系统”
所有的修改都会写入upper，lower是只读的。upper的文件系统必须支持trusted.*扩展属性，所以upper是不支持NFS的

2. 用法

mount -t overlay overlay -olowerdir=/lower,upperdir=/upper,workdir=/work /merged
如果不写upper和workdir，就是只读挂载
mount -t overlay overlay -olowerdir=/lower /merged

逻辑回归的代价函数

Posted on by remaper in 数学基础

线性回归：2 – 2 – Cost Function (8 min).mkv

逻辑回归：6 – 4 – Cost Function (11 min).mkv

在看吴恩达的机器学习教程时，逻辑回归的代价函数怎么来的一开始没看懂，后来想了一下想明白了，记录一下

我们都知道，线性回归（不管是单变量还是多变量）

docker image 存储剖析

Posted on by remaper in 容器核心技术
从docker pull开始，看 docker image 的存储过程
# docker pull ubuntu
Using default tag: latest
latest: Pulling from library/ubuntu
5ba4f30e5bea: Pull complete
6874f9870f5f: Pull complete
4c876570bd7d: Pull complete
10fb34ebccea: Pull complete
Digest: sha256:f1b592e2de671105255a0c0b7b2f71a92b829403e8fc845e3482667ecc301780
Status: Downloaded newer image for ubuntu:latest
# docker images
REPOSITORY          TAG                 IMAGE ID            CREATED             SIZE
ubuntu              latest              12543ced0f6f        2 weeks ago         122.4 MB
其中image名字是ubuntu，image的id是12543ced0f6f，在docker中，几乎所有的ID都是通过UUID或者sha256等方式计算出来的

深入理解L1、L2正则化

Posted on by remaper in 机器学习

原文链接：https://zhuanlan.zhihu.com/p/29360425

正则化（Regularization）是机器学习中一种常用的技术，其主要目的是控制模型复杂度，减小过拟合。最基本的正则化方法是在原目标（代价）函数 中添加惩罚项，对复杂度高的模型进行“惩罚”。其数学表达形式为：

[公式]

式中 [公式] 、 [公式]为训练样本和相应标签， [公式] 为权重系数向量； [公式] 为目标函数， [公式] 即为惩罚项，可理解为模型“规模”的某种度量；参数[公式] 控制控制正则化强弱。不同的 [公式] 函数对权重 [公式] 的最优解有不同的偏好，因而会产生不同的正则化效果。最常用的 [公式] 函数有两种，即 [公式] 范数和 [公式] 范数，相应称之为 [公式] 正则化和 [公式] 正则化。此时有：

[公式]
[公式]

本文将从不同角度详细说明 [公式] 、 [公式] 正则化的推导、求解过程，并对 [公式] 范数产生稀疏性效果的本质予以解释。

文件系统隔离之 – 深入 prjquota，源码剖析

Posted on by remaper in 容器核心技术, 文件系统

ext4 prjquota 实现原理，参考了 xfs prjquota，并且复用了linux 内核的磁盘配额管理机制的大部分实现，所以源码上分析起来还是非常简单的

linux内核本身就已经支持user、group级别的磁盘配额管理，用法可以参考：https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/storage_administration_guide/ch-disk-quotas

从文件系统实现层面来看，文件系统本身并不了解什么是uid，gid，因此disk quota的实现一定是在raw file system 之上的。正因为是如此，所以 prjquota 得以复用原有 disk quota 的大量实现，之需要在原有基础之上，扩展一个新的 quota 类型而已

具体内核提交的 patch：https://lore.kernel.org/patchwork/patch/541891/

4.14 内核时，已经进入主干，因此可以参考：https://lxr.missinglinkelectronics.com/linux+v4.14/fs/ext4/

简述一下其基本设计：

  1. 在 super block 中，有一块专门用来存储 project id 用量的元数据区
  2. 每个文件，属于哪个 project id，是记录在文件的 xattr 属性里面的（正是因为 ext4 文件系统支持 xattr 扩展，所以才很方便的移植这个特性）
  3. 文件写入的时候，先查找这个文件的 project id，然后判断当前 project 的 usage + 文件的增量的大小，是否超过 project 的 hardlimit，如果超过，返回 EDOUT，文件写入失败

实践 pytorch.nn.linear 线性回归

Posted on by remaper in 神经网络

nn.Linear 定义：https://pytorch.org/docs/stable/generated/torch.nn.Linear.html#torch.nn.Linear

class torch.nn.Linear(in_features: int, out_features: int, bias: bool = True)

其中：

  • in_features – 每次输入的样本数，默认是1
  • out_features – 每次输出的样本数，默认也是1
  • bias – If set to False, the layer will not learn an additive bias. Default: True

pytorch 本身是没有神经网络层的概念的，所以如果我们要定义一个神经网络，需要通过 torch.nn.Module 来实现

假设我们有很多样本数据，符合模型 y = wx + c，我们也可以用 torch 来直接生成一些随即样本数据

x = torch.unsqueeze(torch.linspace(0, 1, 300),dim=1)
y = 2 * x + torch.rand(x.size())

CFS 调度算法的基本原理

Posted on by remaper in 进程调度

调度单元有三种状态：

  1. 睡眠：不在 CPU 运行队列里
  2. PENDING：调度单元被唤醒，比如网络数据包到达，IO ready等，进程被唤醒，进入运行队列，但是还没得到 CPU 时间片
  3. 运行：调度单元得到 CPU 控制权，开始运行

调度延时其实就是指进程被唤醒，进入运行队列到得到 CPU 时间片之间的等待时间，也就是处于 PENDING 状态的时间

Linux 通过一个红黑树来维护所有进程的状态，每个 CPU 都会有一个运行队列，管理所有进程和进程组【注意，进程组也是内核的一个基本的调度单元】

每个调度单元都会有一个 vruntime 的属性，用来记录当前调度单元以运行的虚拟时间

CPI2: CPU performance isolation for shared compute clusters

Posted on by remaper in 混部技术

这是google在13年发表的一片论文：https://dl.acm.org/doi/10.1145/2465351.2465388

这篇论文里，最有价值的地方在于建立了一个对业务透明，能够实时感知在线业务运行质量，并且能自动优化的机制

基本概念

  • CPI：uses cycles-per-instruction，平均每条指令消耗的时钟周期（时间），相当于指令执行的代价。

现代处理器均有多级缓存，类似下面这样的一条指令：“ mov 0x200160(%rip),%rax ”，其执行时间由缓存是否命中决定（L0/L1/L2）。

cpu iowait 到底算 busy 还是 idle？

Posted on by remaper in 进程调度

我们在追查线上问题的时候，经常会碰到 cpu iowait 很高的 case，并且通常这种机器伴随着难登录、操作卡顿等现象，一看 cpu idle 还非常低，以为机器 cpu 被打爆了

其实不然，真正的罪魁祸首是 io，而不是 cpu。你看到的 cpu idle 很低，其实是因为部分 idle 时间被算到了 iowait 里面，导致看起来 cpu idle 很低而已。而纯粹的 iowait 很高，并不会引起系统卡顿，如果你发现系统卡顿，大概率是因为 io 异常的磁盘正好是根分区而已，不过今天我们不讨论 io，只讨论 cpu

那么问题来了，cpu iowait 到底是算 busy 还是 idle？

  1. 如果 cpu iowait 不算 busy，那衡量一个 cpu 的繁忙程度的指标到底是什么？
  2. 如果 cpu iowait 算 busy，这和直觉又不符合啊？既然是 io wait，cpu 都被切换出去执行其他进程了，又何来 busy 一说
  3. 初次之外，内核是如何统计 cpu iowait 的？

文件系统隔离之 – 初识 prjquota，原理、实践

Posted on by remaper in 容器核心技术, 文件系统

prjquota 的前身其实是 subtreequota，最早由 openvz 提出，2010年之后好像就没有消息了，没有进入内核主干，有点遗憾。后来我们移植过一次，但是由于设计过于复杂，功能不稳定，并且缺少社区的技术支持，最终选择了放弃。

prjquota 是 xfs 文件系统的一个原生特性，其设计简单，功能健壮。并且有人尝试把他移植到了 ext4 文件系统上。4系内核已经进入主干

prjquota 功能和 subtreequota 一样，能够限制一组具有相同 prjid 属性的文件的总大小。这些具有相同属性的 prjid，可能散落在不同的目录下，但属于同一个项目的文件拥有一个想同的project id标示，正如同一个用户的文件，或者同一个用户组的文件有相同的UserID，或者GroupID

具体实现，可以参考内核 patch：https://lwn.net/Articles/671627/

1）使能 prjquota 特性

磁盘project quota初始化，如下任意一种方法都可以：

  • 重新格式化一个磁盘来支持project quota： /root/ext4/e2fsprogs/misc/mke2fs /dev/hdb -O quota,project
  • 或者在已有的磁盘上使能project quota：/root/ext4/e2fsprogs/misc/tune2fs /dev/hdb  -O quota,project

mount设备支持project quota：

  • mount -t ext4 -o prjquota /dev/hdb xxxx/   或者：
  • mount -t ext4 /dev/hdb xxxx/； /root/ext4/quota-tools/quotaon  xxxx/，但是这个方法，需要在磁盘上没有任何文件被打开的时候才能执行

创建 project id和quota限制管理

  1. 设置一个目录属于一个project id：/root//ext4/e2fsprogs/misc/chattr -p 1001 xxxx/test1
  2. 使得这个目录下的文件默认继承这个project id：/root//ext4/e2fsprogs/misc/chattr  +P xxxx/test1
  3. 设置project的配额：/root/ext4/quota-tools/setquota -P 1001 100 100 400 500 xxxx，可以重复设置，例如更新quota，立即生效