init进程创建的过程:
打开电源-->执行BIOS/boot-loader--->boot-loader加载Linux内核(内核文件存放在/boot目录,文件名类似vmliunz*)-->执行的第一个用户态程序就是init进程。
1号进程就是第一个用户态的进程,有它直接或者间接创建了namespace中的其他进程。
特权信号就是Linux为kernel和超级用户去删除任意进程所保留的,不能被忽略也不能被捕获。
由于SIGKILL是一个特例，因为SIGKILL是不允许注册用户handler的，那么它只有SIG_DFL handler，init进程是永远不能被SIGKILL所杀,但是可以被SIGTERM杀死。
进程处理信号的选择：
1.Linux内核里其实都是用task_struct这个接口来表示的。Linux里基本的调度单位是任务。任务的状态有两个TASK_RUNNING(运行态)和睡眠态(TASK_INTERRUPTIBLE,TASK_UNINTERRUPTIBLE).
运行态是无论进程是正在运行中，还是进程在run queue队列里随时可以运行,都处于这个状态。
睡眠是指进程需要等待某个资源而进入的状态，要等待的资源可以是一个信号量,或者是磁盘IO,这个状态的进程会被放入到wait queue队列里。
TASK_INTERRUPTIBLE是可以被打断的,显示为S stat,TASK_UNINTERRUPTIBLE 是不能被打断的,显示的进程为D stat。
在调用do_exit()的时候，有两个状态,EXIT_DEAD,就是进程在真正结束退出的那一瞬间的状态EXIT_ZOMBIE状态,是在EXIT_DEAD之前的一个状态。
可以通过/proc/sys/kernel/pid_max设置进程最大的数量。如果机器中CPU数目小于等于32，pid_max设置为32768(32K),如果CPU数目大于32，pid_max的数目为N*1024.
在创建容器成功之后, 创建容器的服务会在/sys/fs/cgroups/pids下建立一个字目录，就是一个控制组,控制组里最关键的一个文件是pids.max。
父进程在创建完子进程就不管了，这就是子进程变成僵尸进程的原因。
在主进程里,就是不断在调用带WHOHANG参数的waitpid(),通过这个方式清理容器中所有的僵尸进程。
Containerd在停止容器的时候，就会向容器的init进程发送一个SIGTERM信号,其他进程收到的是SIGKILL信号。
kill()这个系统调用,输入两个参数:进程号和信号,就把特定的信号发送给指定的进程了。
signal调用，决定了进程收到特定的信号如何来处理,SIG_DFL参数把对应信号恢复为缺省handler, 也可以用自定义的函数作为handler,或者用SIG_IGN参数让进程忽略信号。
如何解决停止容器的时候，容器内应用程序被强制杀死的问题:
在容器的init进程中对收到的信号做转发,发送到容器中的其他子进程,这样容器中的所有进程在停止时,都会收到SIGTERM，而不是SIGKILL信号了。
在/sys/fs/cgroup/cpu这个目录看到cpu的数据
Linux普通的调度的算法是CFS（完全公平调度器）
cpu.cfs_period_us,cfs算法的一个调度周期，是以位秒为单位。
cpu.cfs_quota_us,在一个调度周期里这个控制组被允许的运行时间。
cpu.shares，cpu cgroup对于控制组之间的cpu分配比例，缺省值为1024.
由于/proc/stat文件是整个节点全局的状态文件,不属于任何一个Namespace,因此在容器中无法通过读取/proc/stat文件来获取单个容器的CPU使用率。
单个容器CPU使用率=((utime_2 - utime_1)+(stime_2 - stime_1)) 100.0/(HZ et*1)
无法通过CPU Cgroup来控制Load Average的平均负载。
Load Average是一种CPU资源需求的度量:
平均负载统计了这两种情况的进程:
Load Average = 可运行队列进程平均数 + 休眠队列中不可打断的进程平均数
OOM Killer是在Linux系统里如果内存不足时,就需要杀死一个正在有耐性的进程来释放一些内存。
Linux允许进程在申请内存的时候是overcommit，就是允许进程申请超过实际物理内存上线的内存。
malloc()申请的是内存虚拟地址,系统只是程序一个地址范围,由于没有写入数据,所以程序没有得到真正的物理内存。
oom_badness()函数,判断条件:
1.进程已经使用的物理内存页面数
2.每个进程的OOM校准值oom_scire_adj。在/proc文件系统中,每个进程都有一个/proc/<pid>/oom_score_adj的接口文件。
用系统总的可用页面数,乘以OOM校准值oom_score_adj,再加上进程已经使用的物理页面数, 计算出来的值越大,那么这个进程被OOM Killer的几率也越大。
Memory Cgroup是对一组进程的Memory做限制,挂在/sys/fs/cgroup/memory目录下。
journalctl -k查看/var/log/message，看到的信息如下:
1.容器中每一个进程使用的内存页面数量。
2.oom-kill: 可以看到那个容器发生
3.Killed process7445 那个进程被杀死。
Linux内存模型:RSS和Page Cache。
RSS:进程真正申请到物理页面的内存大小。
判断容器实际使用的内存量需要使用memory.stat里的rss值。free获取到的内存值，需要去掉available字段下的值。
Page Cache是进程在运行中读写磁盘文件后，作为Cache而继续保留在内存中，它的目的是为了提高磁盘文件的读写性能。
内存使用量计算公式(memory.kmem.usage_in_bytes表示该memcg内核内存使用量)：memory.usage_in_bytes=memory.stat[rss]+memory.stat[cache]+memory.kmem.usage_in_bytes.
Memory Cgroup OOM不是真正依据内存使用量memory.usage_in_bytes，而是依据working set,working set的计算公式: working_set = memory.usage_in_bytes - total_inactive_file。
swappiness(/proc/sys/vm/swapiness)可以决定系统将会有多频繁地使用交换分区。取值范围为0-100，缺省值为60。
memory.swapiness(Cgroup中的参数)可以控制这个Memory Cgroup控制组下面匿名内存和page cache的回收。
当memory.swapiness=0的时候,对匿名页的回收是始终禁止的,也就是始终不会使用Swap空间。
为了有效地减少磁盘上冗余的镜像数据,同时减少冗余的镜像数据在网络上的传输,选择一种针对容器的文件系统是很有必要的,这类的文件系统被称为UnionFS。
UnionFS实现的主要功能是把多个目录一起挂载在同一目录下。
OverlayFS是Liunx发行版本里缺省使用的容器文件系统。
OverlayFS也是把多个目录合并挂载,被挂载的目录分为两大类:lowerdir和upperdir。
lowerdir允许有多个目录,在被挂载后,这些目录里的文件都是不会被修改或者删除,也就是只读的upper只有一个,不过这个目录是可读写的，挂载点目录中的所有文件修改都会在upperdir中反映出来。
OverlayFS建立2个lowerdir目录，并且在目录中建立相同文件名的文件,然后一起做一个overlay mount，为将文件合并成为一个。
为了避免容器把宿主机的磁盘写满，对OverlayFS的upper目录做XFS Quota的限流。
docker run --storage-opt size=10M,就能限制容器OverlayFS文件系统可写入的最大数据量。
限制文件大小分为两步:
第一步:给目标目录打上一个Project ID
第二步:为这个Project ID在XFS文件系统中,设置一个写入数据块的限制。
setProjectID()是调用ioctl()，setProjectQuota()调用quotactl()来修改内核中XFS的数据结构,从而完成project ID的设置和quota的设置。
如何判断是对那个目录做了限制:
根据/proc/mounts中容器的OverlayFS Mount信息，可以知道限制的目录/var/lib/docker2/<docker_id>，目录下的diff目录就是限制目录。
IOPS就是每秒钟磁盘读写的次数,这个数值越大,性能越好。
吞吐量是每秒钟磁盘中数据的读取量。
吞吐量 = 数据块大小 * IOPS。
在Cgroup v1里,bulkio Cgroup的虚拟文件系统挂载点一半在/sys/fs/cgroup/blkio/。
Direct I/O模式,用户进程如果要写磁盘文件,就会通过Linux内核的文件系统层(fileSystem)-->块设备层(block layer)-->磁盘驱动-->磁盘硬件。
Buffer I/O模式,用户进程只是把文件写到内存中就返回,Linux内核自己有线程会被内存中的数据写入到磁盘中Cgroup v1 blkio的子系统独立于memory系统,无法统计到有Page Cache刷入到磁盘的数据量。Linux中绝大多数使用的是Buffered I/O模式。
Direct I/O可以通过blkio Cgroup来限制磁盘I/O。Cgroup V2从架构上允许一个控制组里只要同时有IO和Memory子系统,就可以对Buffered I/O做磁盘读写的限速。
dirty_backgroud_ratio和dirty_ratio,这两个值都是相对于节点可用内存的百分比值。
当dirty pages数量超过dirty_backgroud_ratio对应的内存量的时候,内核flush线程就会开始把dirty page写入磁盘当dirty pages数量超过dirty_ratio对应的内存量,这时候程序写文件的函数调用write()就会被阻塞住,知道这次调用的dirty pages全部写入到磁盘。
在节点是大内存容量,并且dirty_ratio为系统缺省值为20%,dirty_backgroud_ratio是系统缺省值10%的情况下,通过观察/proc/vmstat中的nr_dirty数值可以发现,dirty pages不会阻塞进程的Buffered I/O写文件 *** 作。
修改网络参数的有两种方法:一种方法是直接到/proc文件系统下的/proc/sys/net目录对参数做修改；还有就是使用sysctl来修改。
创建新的network namespace的方法:系统调用clone()或者unshare()。
Network Namespace工具包:
runC也在对/proc/sys目录做read-only mount之前,预留出了修改接口,就是用来修改容器里/proc/sys下参数的,同样也是sysctl的参数。
在容器启动之前修改网络相关的内容，是可以的，如果启动之后,修改网络相关内容的是不生效的。
docker exec、kubectl exec、ip netns exec、nsenter等命令原理相同,都是基于setns系统调用,切换至指定的一个或多个namespace。
解决容器与外界通讯的问题,一共需要两步完成。
对于macvlan,每个虚拟网络接口都有自己独立的mac地址,而ipvlan的虚拟网络接口是和物理网络接口共享一个mac地址。
veth对外发送数据的时候,peer veth接口都会raise softirq来完成一次收报 *** 作,这样就会带来数据包处理的额外开销。
容器使用ipvlan/macvlan的网络接口,网络延时可以非常接近物理网络接口的延时。
对于需要使用iptables规则的容器,Kubernetes使用service的容器,就不能工作:
docker inspect lat-test-1 | jq.[0].state.Pid
Linux capabilities就是把Linux root用户原来所有的特权做了细化,可以更加细粒度地给进程赋予不同权限。
Privileged的容器也就是允许容器中的进程可以执行所有的特权 *** 作。
容器中root用户的进程,系统也只允许了15个capabilities。
使用不同用户执行程序:
xfs quota功能
centos7 xfs 文件系统配置quota 用户磁盘配额
quota磁盘配额（xfs）
xfs_quota 磁盘配额
xfs_quota 磁盘配额限制篇
XFS文件系统中quota的使用
xfs文件系统quota
Linux学习—CentOS7磁盘配额工具quota
linux磁盘配额详解（EXT4和XFS）
Linux中传统的I/O *** 作是一种缓存I/O，I/O过程中产生的数据传输通常需要在缓冲区中进行多次拷贝。当应用程序需要访问某个数据（read() *** 作）时， *** 作系统会先判断这块数据是否在内核缓冲区中，如果在内核缓冲区中找不到这块数据，内核会先将这块数据从磁盘中读出来放到内核缓冲区中，应用程序再从缓冲区中读取。当应用程序需要将数据输出（write()）时，同样需要先将数据拷贝到输出堆栈相关的内核缓冲区，再从内核缓冲区拷贝到输出设备中。
以一次网络请求为例，如下图。对于一次数据读取，用户应用程序只需要调用read（）及write（）两个系统调用就可以完成一次数据传输，但这个过程中数据经过了四次拷贝，且数据拷贝需要由CPU来调控。在某些情况下，这些数据拷贝会极大地降低系统数据传输的性能，比如文件服务器中，一个文件从磁盘读取后不加修改地回传给调用方，那么这占用CPU时间去处理这四次数据拷贝的性价比是极低的。
一次处理网络调用的系统I/O的流程：
以上可以发现，传统的Linux系统I/O *** 作要进行4次内核空间与应用程序空间的上下文切换，以及4次数据拷贝。
直接内存访问（Direct Memory Access，DMA）是计算机科学中的一种内存访问技术，允许某些电脑内部的硬件子系统独立地读取系统内存，而不需要中央处理器（CPU）的介入。在同等程度的处理器负担下，DMA是一种快速的数据传送方式。这类子系统包括硬盘控制器、显卡、网卡和声卡。
在Linux系统中，当应用程序需要读取文件中的数据时， *** 作系统先分配一些内存，将数据从存储设备读入到这些内存中，然后再将数据传递应用进程；当需要往文件中写数据时， *** 作系统先分配内存接收用户数据，然后再将数据从内存写入磁盘。文件cache管理就是对这些由 *** 作系统分配并用开存储文件数据的内存的管理。
在Linux系统中，文件cache分为两个层面，page cache 与 Buffer cache，每个page cache包含若干个buffer cache。 *** 作系统中，磁盘文件都是由一系列的数据块（Block）组成，buffer cache也叫块缓存，是对磁盘一个数据块的缓存，目的是为了在程序多次访问同一个磁盘块时减少访问时间；而文件系统对数据的组织形式为页，page cache为页缓存，是由多个块缓存构成，其对应的缓存数据块在磁盘上不一定是连续的。也就是说buffer cache缓存文件的具体内容--物理磁盘上的磁盘块，加速对磁盘的访问，而page cache缓存文件的逻辑内容，加速对文件内容的访问。
buffer cache的大小一般为1k，page cache在32位系统上一般为4k，在64位系统上一般为8k。磁盘数据块、buffer cache、page cache及文件的关系如下图：
文件cache的目的是加快对数据文件的访问，同时会有一个预读过程。对于每个文件的第一次读请求，系统会读入所请求的页面并读入紧随其后的几个页面；对于第二次读请求，如果所读页面在cache中，则会直接返回，同时又一个异步预读的过程（将读取页面的下几页读入cache中），如果不在cache中，说明读请求不是顺序读，则会从磁盘中读取文件内容并刷新cache。因此在顺序读取情况下，读取数据的性能近乎内存读取。
DMA允许硬件子系统直接将数据从磁盘读取到内核缓冲区，那么在一次数据传输中，磁盘与内核缓冲区，输出设备与内核缓冲区之间的两次数据拷贝就不需要CPU进行调度，CPU只需要进行缓冲区管理、以及创建和处理DMA。而Page Cache/Buffer Cache的预读取机制则加快了数据的访问效率。如下图所示，还是以文件服务器请求为例，此时CPU负责的数据拷贝次数减少了两次，数据传输性能有了较大的提高。
使用DMA的系统I/O *** 作要进行4次内核空间与应用程序空间的上下文切换，2次CPU数据拷贝及2次DMA数据拷贝。
Mmap内存映射与标准I/O *** 作的区别在于当应用程序需要访问数据时，不需要进行内核缓冲区到应用程序缓冲区之间的数据拷贝。Mmap使得应用程序和 *** 作系统共享内核缓冲区，应用程序直接对内核缓冲区进行读写 *** 作，不需要进行数据拷贝。Linux系统中通过调用mmap()替代read() *** 作。
同样以文件服务器获取文件（不加修改）为例，通过mmap *** 作的一次系统I/O过程如下：
通过以上流程可以看到，数据拷贝从原来的4次变为3次，2次DMA拷贝1次内核空间数据拷贝，CPU只需要调控1次内核空间之间的数据拷贝，CPU花费在数据拷贝上的时间进一步减少（4次上下文切换没有改变）。对于大容量文件读写，采用mmap的方式其读写效率和性能都比较高。（数据页较多，需要多次拷贝）
注：mmap()是让应用程序空间与内核空间共享DMA从磁盘中读取的文件缓冲，也就是应用程序能直接读写这部分PageCache，至于上图中从页缓存到socket缓冲区的数据拷贝只是文件服务器的处理，根据应用程序的不同会有不同的处理，应用程序也可以读取数据后进行修改。重点是虚拟内存映射，内核缓存共享。
djk中nio包下的MappedByteBuffer，官方注释为 A direct byte buffer whose content is a memory-mapped region of a file，即直接字节缓冲区，其内容是文件的内存映射区域。 FileChannel是是nio *** 作文件的类，其map()方法在在实现类中调用native map0()本地方法，该方法通过mmap()实现，因此是将文件从磁盘读取到内核缓冲区，用户应用程序空间直接 *** 作内核空间共享的缓冲区，Java程序通过MappedByteBuffer的get()方法获取内存数据。
MappedByteBuffer允许Java程序直接从内存访问文件，可以将整个文件或文件的一部分映射到内存中，由 *** 作系统进行相关的请求并将内存中的修改写入到磁盘中。
FileChannel map有三种模式
MappedByteBuffer的应用，以rocketMQ为例（简单介绍）。
producer端发送消息最终会被写入到commitLog文件中，consumer端消费时先从订阅的consumeQueue中读取持久化消息的commitLogOffset、size等内容，随后再根据offset、size从commitLog中读取消息的真正实体内容。其中，commitLog是混合部署的，所有topic下的消息队列共用一个commitLog日志数据文件，consumeQueue类似于索引，同时区分开不同topic下不同MessageQueue的消息。
rocketMQ利用MappedByteBuffer及PageCache加速对持久化文件的读写 *** 作。rocketMQ通过MappedByteBuffer将日志数据文件映射到OS的虚拟内存中（PageCache）,写消息时首先写入PageCache，通过刷盘方式（异步或同步）将消息批量持久化到磁盘；consumer消费消息时，读取consumeQueue是顺序读取的，虽然有多个消费者 *** 作不同的consumeQueue，对混合部署的commitLog的访问时随机的，但整体上是从旧到新的有序读，加上PageCache的预读机制，大部分情况下消息还是从PageCache中读取，不会产生太多的缺页中断（要读取的消息不在pageCache中）而从磁盘中读取。
rocketMQ利用mmap()使程序与内核空间共享内核缓冲区，直接对PageCache中的文件进行读写 *** 作，加速对消息的读写请求，这是其高吞吐量的重要手段。
使用mmap能减少CPU数据拷贝的次数，但也存在一些问题。
从Linux2.1开始，Linux引入sendfile()简化 *** 作。取消read()/write()，mmap()/write()。
调用sendfile的流程如下：
通过sendfile()的I/O进行了2次应用程序空间与内核空间的上下文切换，以及3次数据拷贝，其中2次是DMA拷贝，1次是CPU拷贝。sendfile相比起mmap，数据信息没有进入到应用程序空间，所以能减少2次上下文切换的开销，而数据拷贝次数是一样的。
上述流程也可以看出，sendfile()适合对文件不加修改的I/O *** 作。
sendfile()只是减少应用程序空间与内核空间的上下文切换，并没有减少CPU数据拷贝的次数，还存在一次内核空间的两个缓冲区的数据拷贝。要实现CPU零数据拷贝，需要引入一些硬件上的支持。在上一小节的sendfile流程中，数据需要从内核缓冲区拷贝到内核空间socket缓冲区，数据都是在内核空间，如果socket缓冲区到网卡的这次DMA数据传输 *** 作能直接读取到内核缓冲区中的数据，那么这一次的CPU数据拷贝也就能避免。要达到这个目的，DMA需要知道存有文件位置和长度信息的缓冲区描述符，即socket缓冲区需要从内核缓冲区接收这部分信息，DMA需要支持数据收集功能。
sendfile()调用后，数据从磁盘文件拷贝到内核缓冲区中，然后将文件位置和长度信息的缓冲区描述符传递到socket缓冲区，此时数据并没有被拷贝。之后网卡子系统根据socket缓冲区中的文件信息利用DMA技术收集拷贝数据。整个过程进行了2次内核空间和应用程序空间的上下文切换，及2次DMA数据拷贝，CPU不需要参与数据拷贝工作，从而实现零拷贝。当然DMA收集拷贝功能需要硬件和驱动程序的支持。
在 *** 作系统中，硬件和软件之间的数据传输可以通过DMA来进行，DMA进行数据传输的过程几乎不需要CPU参与，但是在内核缓冲区（页缓存）与应用程序缓冲区之间的数据拷贝并没有类似于DMA之类的工具可以使用，mmap、sendfile都是为了减少数据在内核空间与应用程序空间传输时的数据拷贝和上下文切换次数，有效地改善数据在两者之间传递的效率。
linux *** 作系统的零拷贝技术并不单指某一种方式，现有的零拷贝技术种类非常多，在不同的Linux内核版本上有不同的支持。常见的，如果应用程序需要修改数据，则使用mmap()，如果只进行文件数据传输，则可选择sendfile()。
另外，关于零拷贝技术适用于什么场景？在上述的描述中，数据在传递过程中，除了mmap外，应用程序和 *** 作系统几乎是没有改变数据的，mmap的内存映射也是没有改变数据的，也就是说在静态资源的读取场景下，零拷贝更能发挥作用。正如其名，拷贝是在不改变数据的情况下，零是利用手段去减少CPU参与数据拷贝的次数，以释放CPU去进行其他系统调用与计算。
欢迎分享，转载请注明来源：内存溢出
微信扫一扫
支付宝扫一扫
评论列表（0条）