281 lines
13 KiB
Markdown
281 lines
13 KiB
Markdown
|
# 加餐福利 | 课后思考题答案合集
|
|||
|
|
|
|||
|
|
你好，我是程远，好久不见。
|
|||
|
|
|
|||
|
|
距离我们的专栏更新结束，已经过去了不少时间。我仍然会在工作之余，到这门课的留言区转一转，回答同学的问题。大部分的疑问，我都通过留言做了回复。
|
|||
|
|
|
|||
|
|
除了紧跟更新的第一批同学，也很开心有更多新朋友加入到这个专栏的学习中。那课程的思考题呢，为了给你留足思考和研究的时间，我选择用加餐的方式，给你提供参考答案。
|
|||
|
|
|
|||
|
|
这里我想和你说明的是，我这里给你提供的参考答案，都是我能够直接给你特定答案的问题。至于操作类的题目，有的我引用了同学回复的答案。
|
|||
|
|
|
|||
|
|
另外一类操作题，是为了帮你巩固课程内容知识的，相信你可以从课程正文里找到答案。我还是建议你自己动手实战，这样你的收获会更大。
|
|||
|
|
|
|||
|
|
## 必学部分思考题
|
|||
|
|
|
|||
|
|
[第2讲](https://time.geekbang.org/column/article/309423)
|
|||
|
|
|
|||
|
|
Q：对于这一讲的最开始，有这样一个C语言的init进程，它没有注册任何信号的handler。如果我们从Host Namespace向它发送SIGTERM，会发生什么情况呢？
|
|||
|
|
|
|||
|
|
A：即使在宿主机上向容器1号进程发送SIGTERM，在1号进程没有注册handler的情况下，这个进程也不能被杀死。
|
|||
|
|
|
|||
|
|
这个问题的原因是这样的：开始要看内核里的那段代码，“ !(force && sig\_kernel\_only(sig))”，
|
|||
|
|
|
|||
|
|
虽然由不同的namespace发送信号， 虽然force是1了，但是sig\_kernel\_only(sig)对于SIGTERM来说还是0，这里是个&&, 那么 !(1 && 0) = 1。
|
|||
|
|
|
|||
|
|
```shell
|
|||
|
|
#define sig_kernel_only(sig) siginmask(sig, SIG_KERNEL_ONLY_MASK)
|
|||
|
|
#define SIG_KERNEL_ONLY_MASK (\
|
|||
|
|
rt_sigmask(SIGKILL) | rt_sigmask(SIGSTOP))
|
|||
|
|
|
|||
|
|
```
|
|||
|
|
|
|||
|
|
[第3讲](https://time.geekbang.org/column/article/310060)
|
|||
|
|
|
|||
|
|
Q：如果容器的init进程创建了子进程B，B又创建了自己的子进程C。如果C运行完之后，退出成了僵尸进程，B进程还在运行，而容器的init进程还在不断地调用waitpid()，那C这个僵尸进程可以被回收吗？
|
|||
|
|
|
|||
|
|
A：这道题可以参考下面两位同学的回答。
|
|||
|
|
|
|||
|
|
Geek2014用户的回答：
|
|||
|
|
|
|||
|
|
> 这时C是不会被回收的，只有等到B也被杀死，C这个僵尸进程也会变成孤儿进程，被init进程收养，进而被init的wait机制清理掉。
|
|||
|
|
|
|||
|
|
莫名同学的回答：
|
|||
|
|
|
|||
|
|
> C应该不会被回收，waitpid仅等待直接children的状态变化。
|
|||
|
|
|
|||
|
|
> 为什么先进入僵尸状态而不是直接消失？觉得是留给父进程一次机会，查看子进程的PID、终止状态（退出码、终止原因，比如是信号终止还是正常退出等）、资源使用信息。如果子进程直接消失，那么父进程没有机会掌握子进程的具体终止情况。
|
|||
|
|
|
|||
|
|
> 一般情况下，程序逻辑可能会依据子进程的终止情况做出进一步处理：比如 Nginx Master 进程获知 Worker 进程异常退出，则重新拉起来一个Worker进程。
|
|||
|
|
|
|||
|
|
[第4讲](https://time.geekbang.org/column/article/310804)
|
|||
|
|
|
|||
|
|
Q：请你回顾一下基本概念中最后的这段代码，你可以想一想，在不做编译运行的情况下，它的输出是什么？
|
|||
|
|
|
|||
|
|
```shell
|
|||
|
|
#include <stdio.h>
|
|||
|
|
#include <signal.h>
|
|||
|
|
|
|||
|
|
typedef void (*sighandler_t)(int);
|
|||
|
|
|
|||
|
|
void sig_handler(int signo)
|
|||
|
|
{
|
|||
|
|
if (signo == SIGTERM) {
|
|||
|
|
printf("received SIGTERM\n\n");
|
|||
|
|
// Set SIGTERM handler to default
|
|||
|
|
signal(SIGTERM, SIG_DFL);
|
|||
|
|
}
|
|||
|
|
}
|
|||
|
|
|
|||
|
|
int main(int argc, char *argv[])
|
|||
|
|
{
|
|||
|
|
//Ignore SIGTERM, and send SIGTERM
|
|||
|
|
// to process itself.
|
|||
|
|
|
|||
|
|
signal(SIGTERM, SIG_IGN);
|
|||
|
|
printf("Ignore SIGTERM\n\n");
|
|||
|
|
kill(0, SIGTERM);
|
|||
|
|
|
|||
|
|
//Catch SIGERM, and send SIGTERM
|
|||
|
|
// to process itself.
|
|||
|
|
signal(SIGTERM, sig_handler);
|
|||
|
|
printf("Catch SIGTERM\n");
|
|||
|
|
kill(0, SIGTERM);
|
|||
|
|
|
|||
|
|
|
|||
|
|
//Default SIGTERM. In sig_handler, it sets
|
|||
|
|
//SIGTERM handler back to default one.
|
|||
|
|
printf("Default SIGTERM\n");
|
|||
|
|
kill(0, SIGTERM);
|
|||
|
|
|
|||
|
|
return 0;
|
|||
|
|
}
|
|||
|
|
|
|||
|
|
```
|
|||
|
|
|
|||
|
|
A：可以参考用户geek 2014同学的答案。输出结果如下：
|
|||
|
|
|
|||
|
|
Ignore SIGTERM
|
|||
|
|
Catch SIGTERM
|
|||
|
|
received SIGTERM
|
|||
|
|
Default SIGTERM
|
|||
|
|
|
|||
|
|
[第5讲](https://time.geekbang.org/column/article/311054)
|
|||
|
|
|
|||
|
|
Q：我们还是按照文档中定义的控制组目录层次结构图，然后按序执行这几个脚本：
|
|||
|
|
|
|||
|
|
* [create\_groups.sh](https://github.com/chengyli/training/blob/main/cpu/cgroup_cpu/create_groups.sh)
|
|||
|
|
* [update\_group1.sh](https://github.com/chengyli/training/blob/main/cpu/cgroup_cpu/update_group1.sh)
|
|||
|
|
* [update\_group4.sh](https://github.com/chengyli/training/blob/main/cpu/cgroup_cpu/update_group4.sh)
|
|||
|
|
* [update\_group3.sh](https://github.com/chengyli/training/blob/main/cpu/cgroup_cpu/update_group3.sh)
|
|||
|
|
|
|||
|
|
那么，在一个4个CPU的节点上，group1/group3/group4里的进程，分别会被分配到多少CPU呢?
|
|||
|
|
|
|||
|
|
A：分配比例是: 2 : 0.5 : 1.5
|
|||
|
|
|
|||
|
|
**可以参考geek 2014的答案：**
|
|||
|
|
|
|||
|
|
> group1 的shares为1024，quota 3.5，尝试使用4，
|
|||
|
|
|
|||
|
|
> group2的shares默认为1024，quota设置为-1，不受限制，也即是，如果CPU上只有group2的话，那么group2可以使用完所有的CPU（实际上根据group3和group4，group2最多也就能用到1.5+3.5 core）
|
|||
|
|
|
|||
|
|
> 故而，group1和group2各分配到2。把group2分到的2CPU，看作总量，再次分析group3和group4。group3和group3尝试使用的总量超过2，所以按照shares比例分配，group3使用1/(1+3) \* 2 = 0.5，group4使用3/(1+3) \* 2 = 1.5
|
|||
|
|
|
|||
|
|
[第6讲](https://time.geekbang.org/column/article/313255)
|
|||
|
|
|
|||
|
|
Q：写一个小程序，在容器中执行，它可以显示当前容器中所有进程总的CPU使用率。
|
|||
|
|
|
|||
|
|
A：上邪忘川的回答可以作为一个参考。
|
|||
|
|
|
|||
|
|
```shell
|
|||
|
|
#!/bin/bash
|
|||
|
|
cpuinfo1=$(cat /sys/fs/cgroup/cpu,cpuacct/cpuacct.stat)
|
|||
|
|
utime1=$(echo $cpuinfo1|awk '{print $2}')
|
|||
|
|
stime1=$(echo $cpuinfo1|awk '{print $4}')
|
|||
|
|
sleep 1
|
|||
|
|
cpuinfo2=$(cat /sys/fs/cgroup/cpu,cpuacct/cpuacct.stat)
|
|||
|
|
utime2=$(echo $cpuinfo2|awk '{print $2}')
|
|||
|
|
stime2=$(echo $cpuinfo2|awk '{print $4}')
|
|||
|
|
cpus=$((utime2+stime2-utime1-stime1))
|
|||
|
|
echo "${cpus}%"
|
|||
|
|
|
|||
|
|
```
|
|||
|
|
|
|||
|
|
[第8讲](https://time.geekbang.org/column/article/315468)
|
|||
|
|
|
|||
|
|
Q：在我们的例子[脚本](https://github.com/chengyli/training/blob/main/memory/oom/start_container.sh)基础上，你可以修改一下，在容器刚一启动，就在容器对应的Memory Cgroup中禁止OOM，看看接下来会发生什么？
|
|||
|
|
|
|||
|
|
A：通过“**memory.oom\_control**”禁止OOM后，在容器中的进程不会发生OOM，但是也无法申请出超过“memory.limit\_in\_bytes”内存。
|
|||
|
|
|
|||
|
|
```shell
|
|||
|
|
# cat start_container.sh
|
|||
|
|
#!/bin/bash
|
|||
|
|
docker stop mem_alloc;docker rm mem_alloc
|
|||
|
|
|
|||
|
|
docker run -d --name mem_alloc registry/mem_alloc:v1
|
|||
|
|
|
|||
|
|
sleep 2
|
|||
|
|
CONTAINER_ID=$(sudo docker ps --format "{{.ID}}\t{{.Names}}" | grep -i mem_alloc | awk '{print $1}')
|
|||
|
|
echo $CONTAINER_ID
|
|||
|
|
|
|||
|
|
CGROUP_CONTAINER_PATH=$(find /sys/fs/cgroup/memory/ -name "*$CONTAINER_ID*")
|
|||
|
|
echo $CGROUP_CONTAINER_PATH
|
|||
|
|
|
|||
|
|
echo 536870912 > $CGROUP_CONTAINER_PATH/memory.limit_in_bytes
|
|||
|
|
echo 1 > $CGROUP_CONTAINER_PATH/memory.oom_control
|
|||
|
|
cat $CGROUP_CONTAINER_PATH/memory.limit_in_bytes
|
|||
|
|
|
|||
|
|
```
|
|||
|
|
|
|||
|
|
[第10讲](https://time.geekbang.org/column/article/317216)
|
|||
|
|
|
|||
|
|
Q：在一个有Swap分区的节点上用Docker启动一个容器，对它的Memory Cgroup控制组设置一个内存上限N，并且将memory.swappiness设置为0。这时，如果在容器中启动一个不断读写文件的程序，同时这个程序再申请1/2N的内存，请你判断一下，Swap分区中会有数据写入吗？
|
|||
|
|
|
|||
|
|
A：Memory Cgroup参数memory.swappiness起到局部控制的作用，因为已经设置了memory.swappiness参数，全局参数swappiness参数失效，那么容器里就不能使用swap了。
|
|||
|
|
|
|||
|
|
[第11讲](https://time.geekbang.org/column/article/318173)
|
|||
|
|
|
|||
|
|
Q：在这一讲OverlayFS的[例子](https://github.com/chengyli/training/blob/main/filesystem/overlayfs/test_overlayfs.sh)的基础上，建立2个lowerdir的目录，并且在目录中建立相同文件名的文件，然后一起做一个overlay mount，看看会发生什么？
|
|||
|
|
|
|||
|
|
A：这里引用上邪忘川同学的实验结果。
|
|||
|
|
|
|||
|
|
实验过程如下，结果是lower1目录中的文件覆盖了lower2中同名的文件, 第一个挂载的目录优先级比较高
|
|||
|
|
|
|||
|
|
```shell
|
|||
|
|
[[root@localhost ~]# cat overlay.sh
|
|||
|
|
#!/bin/bash
|
|||
|
|
|
|||
|
|
umount ./merged
|
|||
|
|
rm upper lower1 lower2 merged work -r
|
|||
|
|
|
|||
|
|
mkdir upper lower1 lower2 merged work
|
|||
|
|
echo "I'm from lower1!" > lower1/in_lower.txt
|
|||
|
|
echo "I'm from lower2!" > lower2/in_lower.txt
|
|||
|
|
echo "I'm from upper!" > upper/in_upper.txt
|
|||
|
|
# `in_both` is in both directories
|
|||
|
|
echo "I'm from lower1!" > lower1/in_both.txt
|
|||
|
|
echo "I'm from lower2!" > lower2/in_both.txt
|
|||
|
|
echo "I'm from upper!" > upper/in_both.txt
|
|||
|
|
|
|||
|
|
sudo mount -t overlay overlay \
|
|||
|
|
-o lowerdir=./lower1:./lower2,upperdir=./upper,workdir=./work \
|
|||
|
|
./merged
|
|||
|
|
[root@localhost ~]# sh overlay.sh
|
|||
|
|
[root@localhost ~]# cat merged/in_lower.txt
|
|||
|
|
I'm from lower1!
|
|||
|
|
|
|||
|
|
```
|
|||
|
|
|
|||
|
|
[第12讲](https://time.geekbang.org/column/article/318978)
|
|||
|
|
|
|||
|
|
Q：在正文知识详解的部分，我们使用"xfs\_quota"给目录打了project ID并且限制了文件写入的数据量。那么在做完限制之后，我们是否能用xfs\_quota命令，查询到被限制目录的project ID和限制的数据量呢？
|
|||
|
|
|
|||
|
|
A：xfs\_quota不能直接得到一个目录的quota大小的限制，只可以看到project ID上的quota限制，不过我们可以用[这段程序](https://github.com/chengyli/training/blob/main/filesystem/quota/get_projectid.c)来获得目录对应的project ID。
|
|||
|
|
|
|||
|
|
```shell
|
|||
|
|
# xfs_quota -x -c 'report -h /'
|
|||
|
|
...
|
|||
|
|
Project ID Used Soft Hard Warn/Grace
|
|||
|
|
---------- ---------------------------------
|
|||
|
|
#0 105.6G 0 0 00 [------]
|
|||
|
|
#101 0 0 10M 00 [------]
|
|||
|
|
|
|||
|
|
# ./get_proj /tmp/xfs_prjquota
|
|||
|
|
Dir: /tmp/xfs_prjquota projectid is 101
|
|||
|
|
|
|||
|
|
```
|
|||
|
|
|
|||
|
|
[第13讲](https://time.geekbang.org/column/article/320123)
|
|||
|
|
|
|||
|
|
Q：这是一道操作题，通过这个操作你可以再理解一下 blkio Cgroup与 Buffered I/O的关系。
|
|||
|
|
|
|||
|
|
在Cgroup V1的环境里，我们在blkio Cgroup V1的例子基础上，把fio中“-direct=1”参数去除之后，再运行fio，同时运行iostat查看实际写入磁盘的速率，确认Cgroup V1 blkio无法对Buffered I/O限速。
|
|||
|
|
|
|||
|
|
A: 这是通过iostat看到磁盘的写入速率，是可以突破cgroup V1 blkio中的限制值的。
|
|||
|
|
|
|||
|
|
[第17讲](https://time.geekbang.org/column/article/324122)
|
|||
|
|
|
|||
|
|
Q：在这节课的最后，我提到“由于ipvlan/macvlan网络接口直接挂载在物理网络接口上，对于需要使用iptables规则的容器，比如Kubernetes里使用service的容器，就不能工作了”，请你思考一下这个判断背后的具体原因。
|
|||
|
|
|
|||
|
|
A：ipvlan/macvlan工作在网络2层，而iptables工作在网络3层。所以用ipvlan/macvlan为容器提供网络接口，那么基于iptables的service服务就不工作了。
|
|||
|
|
|
|||
|
|
[第18讲](https://time.geekbang.org/column/article/324357)
|
|||
|
|
|
|||
|
|
Q：在这一讲中，我们提到了Linux内核中的tcp\_force\_fast\_retransmit()函数，那么你可以想想看，这个函数中的tp->recording和内核参数 /proc/sys/net/ipv4/tcp\_reordering是什么关系？它们对数据包的重传会带来什么影响？
|
|||
|
|
|
|||
|
|
```shell
|
|||
|
|
static bool tcp_force_fast_retransmit(struct sock *sk)
|
|||
|
|
{
|
|||
|
|
struct tcp_sock *tp = tcp_sk(sk);
|
|||
|
|
|
|||
|
|
return after(tcp_highest_sack_seq(tp),
|
|||
|
|
tp->snd_una + tp->reordering * tp->mss_cache);
|
|||
|
|
}
|
|||
|
|
|
|||
|
|
```
|
|||
|
|
|
|||
|
|
A: 在TCP链接建立的时候，tp->reordering默认值是从/proc/sys/net/ipv4/tcp\_reordering（默认值为3）获取的。之后根据网络的乱序情况，进行动态调整，最大可以增长到/proc/sys/net/ipv4/tcp\_max\_reordering (默认值为300)的大小。
|
|||
|
|
|
|||
|
|
[第20讲](https://time.geekbang.org/column/article/327107)
|
|||
|
|
|
|||
|
|
Q：我在这一讲里提到了rootless container，不过对于rootless container的支持，还存在着不少的难点，比如容器网络的配置、Cgroup的配置，你可以去查阅一些资料，看看podman是怎么解决这些问题的。
|
|||
|
|
|
|||
|
|
A：可以阅读一下[这篇文档](https://github.com/containers/podman/blob/master/rootless.md)。
|
|||
|
|
|
|||
|
|
## 专题加餐
|
|||
|
|
|
|||
|
|
[专题03](https://time.geekbang.org/column/article/340142)
|
|||
|
|
|
|||
|
|
Q：我们讲ftrace实现机制时，说过内核中的“inline函数”不能被ftrace到，你知道这是为什么吗？那么内核中的“static函数”可以被ftrace追踪到吗？
|
|||
|
|
|
|||
|
|
A：inline函数在编译的时候被展开了，所以不能被ftrace到。而static函数需要看情况，如果加了编译优化参数“-finline-functions-called-once”，对于只被调用到一次的static函数也会当成inline函数处理，那么也不能被ftrace追踪到了。
|
|||
|
|
|
|||
|
|
[专题04](https://time.geekbang.org/column/article/340934)
|
|||
|
|
|
|||
|
|
Q：想想看，当我们用kprobe为一个内核函数注册了probe之后，怎样能看到对应内核函数的第一条指令被替换了呢？
|
|||
|
|
|
|||
|
|
A：**首先可以参考莫名同学的答案：**
|
|||
|
|
|
|||
|
|
> 关于思考题，想到一个比较笨拙的方法：gdb+qemu调试内核。先进入虚拟机在某个内核函数上注册一个kprobe，然后gdb远程调试内核，查看该内核函数的汇编指令（disass）是否被替换。应该有更简单的方法，这方面了解不深。
|
|||
|
|
|
|||
|
|
另外，我们用gdb远程调试内核看也可以。还可以通过 /proc/kallsyms找到函数的地址，然后写个kernel module把从这个地址开始后面的几个字节dump出来，比较一下probe函数注册前后的值。
|
|||
|
|
|