linux机制

❶ Handler消息机制（一）：linux的epoll机制

在linux 没有实现epoll事件驱动机制之前，我们一般选择用select或者poll等IO多路复用的方法来实现并发服务程序。在linux新的内核中，有了一种替换它的机制，就是epoll。

相比select模型， poll使用链表保存文件描述符，因此没有了监视文件数量的限制 ，但其他三个缺点依然存在。

假设我们的服务器需要支持100万的并发连接，则在__FD_SETSIZE 为1024的情况下，则我们至少需要开辟1k个进程才能实现100万的并发连接。除了进程间上下文切换的时间消耗外，从内核/用户空间大量的无脑内存拷贝、数组轮询等，是系统难以承受的。因此，基于select模型的服务器程序，要达到10万级别的并发访问，是一个很难完成的任务。

由于epoll的实现机制与select/poll机制完全不同，上面所说的 select的缺点在epoll上不复存在。

设想一下如下场景：有100万个客户端同时与一个服务器进程保持着TCP连接。而每一时刻，通常只有几百上千个TCP连接是活跃的(事实上大部分场景都是这种情况)。如何实现这样的高并发？

在select/poll时代，服务器进程每次都把这100万个连接告诉操作系统(从用户态复制句柄数据结构到内核态)，让操作系统内核去查询这些套接字上是否有事件发生，轮询完后，再将句柄数据复制到用户态，让服务器应用程序轮询处理已发生的网络事件，这一过程资源消耗较大，因此，select/poll一般只能处理几千的并发连接。

epoll的设计和实现与select完全不同。epoll通过在Linux内核中申请一个简易的文件系统(文件系统一般用什么数据结构实现？B+树)。把原先的select/poll调用分成了3个部分：

1）调用epoll_create()建立一个epoll对象(在epoll文件系统中为这个句柄对象分配资源)

2）调用epoll_ctl向epoll对象中添加这100万个连接的套接字

3）调用epoll_wait收集发生的事件的连接

如此一来，要实现上面说是的场景，只需要在进程启动时建立一个epoll对象，然后在需要的时候向这个epoll对象中添加或者删除连接。同时，epoll_wait的效率也非常高，因为调用epoll_wait时，并没有一股脑的向操作系统复制这100万个连接的句柄数据，内核也不需要去遍历全部的连接。

当某一进程调用epoll_create方法时，Linux内核会创建一个eventpoll结构体，这个结构体中有两个成员与epoll的使用方式密切相关。eventpoll结构体如下所示：

每一个epoll对象都有一个独立的eventpoll结构体，用于存放通过epoll_ctl方法向epoll对象中添加进来的事件。这些事件都会挂载在红黑树中，如此，重复添加的事件就可以通过红黑树而高效的识别出来(红黑树的插入时间效率是lgn，其中n为树的高度)。

而所有 添加到epoll中的事件都会与设备(网卡)驱动程序建立回调关系，也就是说，当相应的事件发生时会调用这个回调方法 。这个回调方法在内核中叫ep_poll_callback,它会将发生的事件添加到rdlist双链表中。

在epoll中，对于每一个事件，都会建立一个epitem结构体，如下所示：

当调用epoll_wait检查是否有事件发生时，只需要检查eventpoll对象中的rdlist双链表中是否有epitem元素即可。如果rdlist不为空，则把发生的事件复制到用户态，同时将事件数量返回给用户。

epoll结构示意图

通过红黑树和双链表数据结构，并结合回调机制，造就了epoll的高效。

events可以是以下几个宏的集合：
EPOLLIN：触发该事件，表示对应的文件描述符上有可读数据。(包括对端SOCKET正常关闭)；
EPOLLOUT：触发该事件，表示对应的文件描述符上可以写数据；
EPOLLPRI：表示对应的文件描述符有紧急的数据可读（这里应该表示有带外数据到来）；
EPOLLERR：表示对应的文件描述符发生错误；
EPOLLHUP： 表示对应的文件描述符被挂断；
EPOLLET：将EPOLL设为边缘触发(EdgeTriggered)模式，这是相对于水平触发(Level Triggered)来说的。
EPOLLONESHOT： 只监听一次事件，当监听完这次事件之后，如果还需要继续监听这个socket的话，需要再次把这个socket加入到EPOLL队列里。
示例：

ET(EdgeTriggered) :高速工作模式，只支持no_block(非阻塞模式)。在此模式下，当描述符从未就绪变为就绪时，内核通过epoll告知。然后它会假设用户知道文件描述符已经就绪，并且不会再为那个文件描述符发送更多的就绪通知，直到某些操作导致那个文件描述符不再为就绪状态了。(触发模式只在数据就绪时通知一次，若数据没有读完，下一次不会通知，直到有新的就绪数据)

LT(LevelTriggered) :缺省工作方式，支持blocksocket和no_blocksocket。在LT模式下内核会告知一个文件描述符是否就绪了，然后可以对这个就绪的fd进行IO操作。如果不作任何操作，内核还是会继续通知！若数据没有读完，内核也会继续通知，直至设备数据为空为止！

1.我们已经把一个用来从管道中读取数据的文件句柄(RFD)添加到epoll描述符
2. 这个时候从管道的另一端被写入了2KB的数据
3. 调用epoll_wait(2)，并且它会返回RFD，说明它已经准备好读取操作
4. 然后我们读取了1KB的数据
5. 调用epoll_wait(2)……

ET工作模式：
如果我们在第1步将RFD添加到epoll描述符的时候使用了EPOLLET标志，在第2步执行了一个写操作，第三步epoll_wait会返回同时通知的事件会销毁。因为第4步的读取操作没有读空文件输入缓冲区内的数据，因此我们在第5步调用epoll_wait(2)完成后，是否挂起是不确定的。epoll工作在ET模式的时候，必须使用非阻塞套接口，以避免由于一个文件句柄的阻塞读/阻塞写操作把处理多个文件描述符的任务饿死。

只有当read(2)或者write(2)返回EAGAIN时(认为读完)才需要挂起，等待。但这并不是说每次read()时都需要循环读，直到读到产生一个EAGAIN才认为此次事件处理完成，当read()返回的读到的数据长度小于请求的数据长度时(即小于sizeof(buf))，就可以确定此时缓冲中已没有数据了，也就可以认为此事读事件已处理完成。

LT工作模式：
LT方式调用epoll接口的时候，它就相当于一个速度比较快的poll(2)，并且无论后面的数据是否被使用，因此他们具有同样的职能。

当调用 epoll_wait检查是否有发生事件的连接时，只是检查 eventpoll对象中的 rdllist双向链表是否有 epitem元素而已，如果 rdllist链表不为空，则把这里的事件复制到用户态内存中，同时将事件数量返回给用户。因此，epoll_wait的效率非常高。epoll_ctl在向 epoll对象中添加、修改、删除事件时，从 rbr红黑树中查找事件也非常快，也就是说，epoll是非常高效的，它可以轻易地处理百万级别的并发连接。

1.减少用户态和内核态之间的文件句柄拷贝；

2.减少对可读可写文件句柄的遍历。

https://cloud.tencent.com/developer/information/linux%20epoll%E6%9C%BA%E5%88%B6
https://blog.csdn.net/u010657219/article/details/44061629
https://jiahao..com/s?id=1609322251459722004&wfr=spider&for=pc

❷ linux cgroup机制

Cgroup是control group的缩写，是Linux内核提供的一种用于限制，记录，隔离进程组所使用物理资源（cpu，memory，io等）的机制。

cgroup提供了一系列的功能用于对Linux系统资源进行管理和限制，主要功能包括如下

1：限制进程组可以使用的资源数量，例如进程组对内存的使用上限。

2：进程组的执行优先级限制。

3：记录进程组所使用的资源数量，例如进程组所使用的cpu时间。

4：进程组隔离的能力。

在cgroup中有一些基本定义或概念

1：Task，理解为系统中需要被控制的进程。

2：Subsystem，可以被控制的资源系统，例如cpu，IO，内存等。

3：Cgroup，按照某种控制标准而划分而成的控制族。

4：hierarchy，Cgroup可以组织成树状结构，子节点继承父节点的控制标准。

在系统中创建新的hierarchy时，系统中的所有任务都属于该层级的默认cgroup（root group）的成员。

一个子系统只能附加到一个层级上。

一个层级可以附加多个子系统。

一个任务可以是cgroup的成员，但这些cgroup必须在不同的hierarchy中。

任务创建的子任务（进程），子进程自动成为父进程cgroup的成员。

关系图如下：

blkio -- 这个子系统为块设备设定输入/输出限制，比如物理设备（磁盘，固态硬盘，USB 等等）。

cpu -- 这个子系统使用调度程序提供对 CPU 的 cgroup 任务访问。

cpuacct -- 这个子系统自动生成 cgroup 中任务所使用的 CPU 报告。

cpuset -- 这个子系统为 cgroup 中的任务分配独立 CPU（在多核系统）和内存节点。

devices -- 这个子系统可允许或者拒绝 cgroup 中的任务访问设备。

freezer -- 这个子系统挂起或者恢复 cgroup 中的任务。

memory -- 这个子系统设定 cgroup 中任务使用的内存限制，并自动生成由那些任务使用的内存资源报告。

net_cls -- 这个子系统使用等级识别符（classid）标记网络数据包，可允许 Linux 流量控制程序（tc）识别从具体 cgroup 中生成的数据包。

ns -- 名称空间子系统。

Linux系统中最多可以建12棵cgroup层级树（每棵树关联一个子系统），也可以最少建一颗cgroup层级树（关联所有12个控制子系统）

可以通过mount命令完成

1.挂载一颗和所有subsystem关联的cgroup树到/sys/fs/cgroup

mount -t cgroup

xxx /sys/fs/cgroup

2.挂载一颗和cpuset

subsystem关联的cgroup树到/sys/fs/cgroup/cpuset

mkdir

/sys/fs/cgroup/cpuset

mount -t cgroup -o

cpuset xxx /sys/fs/cgroup/cpuset

3.挂载一颗与cpu和cpuacct

subsystem关联的cgroup树到/sys/fs/cgroup/cpu,cpuacct

mkdir

/sys/fs/cgroup/cpu,cpuacct

mount -t cgroup -o

cpu,cpuacct xxx /sys/fs/cgroup/cpu,cpuacct

4.挂载一棵cgroup树，但不关联任何subsystem

mkdir

/sys/fs/cgroup/systemd

mount -t cgroup -o

none,name=systemd xxx /sys/fs/cgroup/system

通过mount可以查看到cgroup的默认挂载点

每个目录下，其中的文件描述了如何对资源进行限制。

在每个进程的/proc/$pid/cgroup文件中，描述了进程于cgroup的关系：

第一列描述cgroup的树ID（该ID可以在/proc/cgroups中一一对应）；第二列描述绑定的所有子系统；第三列描述进程在cgroup中的路径。

当我们对某个任务需要进行限制时，不推荐直接在cgroup的各个子系统的root下修改配置，而是在对应的层级下建立单独的控制节点。

例如如下，在cpu目录下建立我们自己的子目录：

进入我们创建的子目录后，会看到系统已经创建好了资源控制文件，此时只需要修改这些配置文件满足要求既可以。

要控制我们的进程，只需要将进程ID添加到tasks配置文件中即可以。

❸ linux系统实现安全机制的基本手段有哪些

实现安全机制主要有以下几种：

1. 系统层面：管访问类别的防火墙、管目标文件安全上下文的SeLinux。

2. 管理层面：密码要复杂、三个月一次更新。

3. 应用层面：用不到的别装，时刻更新稳定版本，不要bata版本或类似版本。

4. 个人层面：多看点安全方面的知识，安全手段先在沙盒中做好，然后再部署到真机上去。
   

❹ Linux的IPC机制（三）：Binder

正如上一章所说, 跨进程通信是需要内核空间做支持的. 传统的 IPC 机制如 管道, Socket, 都是内核的一部分, 因此通过内核支持来实现进程间通信自然是没问题的.

但是 Binder 并不是 Linux 系统内核的一部分, 那怎么办呢, 这得益于 Linux 的动态内核可加载模块 (Loadable Kernel Mole, LKM)的机制

这样 Android 系统就可以通过动态添加一个内核模块运行在内核空间, 用户进程进程之间通过这个内核模块作为桥梁来实现通信.

那么在 Android 系统中用户进程之间是如何通过这个内核模块 (Binder Driver)来实现通信的呢? 显然不是和上一章的传统 IPC 通信一样,进行两次 了, 不然Binder 也不有在性能方面的优势了.

Binder IPC 机制中设计到的内存映射通过 mmap() 来实现, mmap() 是操作系统中一种内存映射的方法.

内存映射能减少数据 的次数, 实现用户空间和内核空间的高效互动. 两个空间各自的修改也能直接反应在映射的内存区域, 从而被对方空间及时感知. 也正因为如此, 内存映射能够提供对进程间通信的支持.

Binder IPC 正是基于内存映射( mmap() ) 来实现的, 但是 mmap() 通常是用在有物理介质的文件系统上的.

比如进程中的用户区域是不能直接和物理设备打交道的, 如果想要把磁盘上的数据读取到进程的用户区域, 需要两次 (磁盘 -> 内核空间 -> 用户空间). 通常在这种场景下 mmap() 就能发挥作用, 通过在物理介质和用户空间之间建立映射, 减少数据的 次数, 用内存读写代替 I/O 读写, 提高文件读取效率.

而 Binder 并不存在物理介质, 因此 Binder 驱动使用 mmap() 并不是为了在物理介质和用户空间之间映射, 而是用来在内核空间创建数据接收的缓存空间.

一次完整的 Binder IPC 通信过程通常是这样:

这样就完成了一次进程间通信
如下图:

介绍完 Binder IPC 的底层通信原理, 接下来我们看看实现层面是如何设计的

一次完成的进程间通信必然至少包含两个进程, 通常我们称通信的双方分别为客户端进程(Client) 和服务端进程(Server), 由于进程隔离机制的存在, 通信双方必然需要借助 Binder 来实现.

BInder 是基于 C/S 架构. 是由一些列组件组成. 包括 Client, Server, ServiceManager, Binder 驱动.

Binder 驱动就如如同路由器一样, 是整个通信的核心. 驱动负责进程之间 Binder 通信的建立 / 传递, Binder 引用计数管理, 数据包在进程之间的传递和交互等一系列底层支持.

ServiceManager 作用是将字符形式的 Binder 名字转化成 Client 中对该 Binder 的引用, 使得 Client 能够通过 Binder 的名字获得对 Binder 实体的引用.

注册了名字的 Binder 叫实名 Binder, 就像网站一样除了 IP 地址以外还有自己的网址.
Server 创建了 Binder, 并为它起一个字符形式, 可读易记的名字, 将这个 BInder 实体连同名字一起以数据包的形式通过 Binder 驱动 发送给 ServiceManager, 通知 ServiceManager 注册一个名字为 "张三"的 Binder, 它位于某个 Server 中, 驱动为这个穿越进程边界的 BInder 创建位于内核中的实体节点以及 ServiceManager 对实体的引用, 将名字以及新建的引用打包传给 ServiceManager, ServiceManager 收到数据后从中取出名字和引用填入查找表.

ServiceManager 是一个进程, Server 又是一个另外的进程, Server 向 ServiceManager 中注册 BInder 必然涉及到进程间通信. 当实现进程间通信又要用到进程间通信, 这就好像蛋可以孵出鸡的前提确实要先找只鸡下蛋! Binder 的实现比较巧妙, 就是预先创造一只鸡来下蛋. ServiceManager 和其他进程同样采用 Binder 通信, ServiceManager 是 Server 端, 有自己的 Binder 实体, 其他进程都是 Client, 需要通过这个 Binder 的引用来实现 Binder 的注册, 查询和获取. ServiceManager 提供的 Binder 比较特殊, 它没有名字也不需要注册. 当一个进程使用 BINDERSETCONTEXT_MGR 命令将自己注册成 ServiceManager 时 Binder 驱动会自动为它创建 Binder 实体(这就是那只预先造好的那只鸡). 其实这个 Binder 实体的引用在所有 Client 中都固定为 0 , 而无需通过其他手段获得. 也就是说, 一个 Server 想要向 ServiceManager 注册自己的 Binder 就必须通过这个 0 号引用和 ServiceManager 的 Binder 通信. 这里说的 Client 是相对于 ServiceManager 而言的, 一个进程或者应用程序可能是提供服务的 Server, 但是对于 ServiceManager 来说它仍然是个 Client.

Server 向 ServiceManager 中注册了 Binder 以后, Client 就能通过名字获得 Binder 的引用. Client 也利用保留的 0 号引用向 ServiceManager 请求访问某个 Binder. 比如,Client 申请访问名字叫"张三"的 Binder 引用. ServiceManager 收到这个请求后从请求数据包中取出 Binder 名称, 在查找表里找到对应的条目, 取出对应的 Binder 引用, 作为回复发送给发起请求的 Client. 从面相对象的角度看, Server 中的 Binder 实体现在有两个引用: 一个位于 ServiceManager 中, 一个位于发起请求的 Client 中. 如果后面会有更多的 Client 请求该 Binder, 系统中就会有更多的引用指向这个 Binder, 就像 java 中一个对象有多个引用一样.

我们已经解释清楚 Client, Server 借助 Binder 驱动完成跨进程通信的实现机制了, 但是还有个问题需要弄清楚, 比如 A 进程想要 B 进程中的某个对象(object) 是如何实现的呢, 毕竟它们属于不同的进程, A 进程没办法直接使用 B 进程中的 object.

前面我们说过跨进程通信的过程都有 Binder 驱动的参与, 因此在数据流经 Binder 驱动的时候 Binder 驱动会对数据做一层转换.

我们在 Client端，向 ServiceManager 获取具体的 Server 端的 Binder 引用的时候，会首先进过 Binder 驱动，Binder 驱动它并不会把真正的 Server 的 Binder 引用返回给 Client 端，而是返回一个代理的 java 对象，该对象具有跟 Server 端的 Binder 引用相同的方法签名，这个对象为 ProxyObject，他具有跟 Server 的 Binder 实例一样的方法，只是这些方法并没有 Server 端的能力，这些方法只需要把请求参数交给 Binder 驱动即可. 对于 Client 端来说和直接调用 Server 中的方法是一样的.

了解了上面之后, 我们大致可以推算出 Binder 的通信过程

1. 注册 ServiceManager

2. 注册 Server

3. Client 获取 Server 的 Binder 引用

4. Client 与 Server 通信

❺ Linux的内存管理机制是什么样的

,程序是直接运行在物理内存上的。换句话说,就是程序在运行的过程中访问的都是物理地址。如果这个系统只运行一个程序

❻ linux下的几种时钟和定时器机制

1. RTC(Real Time Clock)

所有PC都有RTC. 它和CPU和其他芯片独立。它在电脑关机之后还可以正常运行。RTC可以在IRQ8上产生周期性中断. 频率在2Hz--8192HZ.

Linux只是把RTC用来获取时间和日期. 当然它允许进程通过对/dev/rtc设备来对它进行编程。Kernel通过0x70和0x71 I/O端口来访问RTC。

 

2. TSC(Time Stamp Counter)

80x86上的微处理器都有CLK输入针脚. 从奔腾系列开始. 微处理器支持一个计数器. 每当一个时钟信号来的时候. 计数器加1. 可以通过汇编指令rdtsc来得到计数器的值。通过calibrate_tsc可以获得CPU的频率. 它是通过计算大约5毫秒里tsc寄存器里面的增加值来确认的。或者可以通过cat /proc/cpuinfo来获取cpu频率。tsc可以提供比PIT更精确的时间度量。

 

3. PIT(Programmable internval timer)

除了RTC和TSC. IBM兼容机提供了PIT。PIT类似微波炉的闹钟机制. 当时间到的时候. 提供铃声. PIT不是产生铃声. 而是产生一种特殊中断. 叫定时器中断或者时钟中断。它用来告诉内核一个间隔过去了。这个时间间隔也叫做一个滴答数。可以通过编译内核是选择内核频率来确定。如内核频率设为1000HZ,则时间间隔或滴答为1/1000=1微秒。滴答月短. 定时精度更高. 但是用户模式的时间更短. 也就是说用户模式下程序执行会越慢。滴答的长度以纳秒形式存在tick_nsec变量里面。PIT通过8254的0x40--0x43端口来访问。它产生中断号为IRQ 0.

下面是关于pIT里面的一些宏定义：

HZ：每秒中断数。

CLOCK_TICK_RATE:值是1,193,182. 它是8254芯片内部振荡器频率。

LATCH：代表CLOCK_TICK_RATE和HZ的比率. 被用来编程PIT。

setup_pit_timer()如下：

spin_lock_irqsave(&i8253_lock, flags);

outb_p(0x34,0x43);

udelay(10);

outb_p(LATCH & 0xff, 0x40);

udelay(10);

outb (LATCH >> 8, 0x40);

spin_unlock_irqrestore(&i8253_lock, flags);

 

 

4. CPU Local Timer

最近的80x86架构的微处理器上的local apic提供了cpu local timer.他和pit区别在于它提供了one-shot和periodic中断。它可以使中断发送到特定cpu。one-shot中断常用在实时系统里面。

❼ LINUX内存机制是什么

C语言程序编写、调试、优化都在Linux，那么当Linux的操作系统中被C语言调用的某一个控件的代码文件没了，Linux系统是能运行的但是C程序生存的"*.*"文件就不能执行了，得必须返回到C语言或反汇编中检查调用调试系统文件情况。
比如在C++里有句dos语句"system("md
book")"，在当前目录建立"book"文件夹，那么就是C++调用操作系统的dos模块命令集中"md"建文件夹的命令，那么加入某个Linux
操作系统内有dos模块，那这句可以运行，那么，问题来了，有些Windows操作系统已经把dos模块优化了，当然"system("md
book")"这句在系统里找dos的"md"命令就是空命令了。该例子与内存机制无关，当然也有有关的。
总之，C语言编写、调试、优化需要在多种系统内验证，否则还是存在一些移植性的问题。

❽ Linux内存机制（swap）

我们知道，直接从物理内存读写数据要比从硬盘读写数据要快的多，因此，我们希望所有数据的读取和写入都在内存完成，而内存是有限的，这样就引出了物理内存与虚拟内存的概念。

物理内存就是系统硬件提供的内存大小，是真正的内存，相对于物理内存，在linux下还有一个虚拟内存的概念，虚拟内存就是为了满足物理内存的不足而提出的策略，它是利用磁盘空间虚拟出的一块逻辑内存，用作虚拟内存的磁盘空间被称为交换空间（Swap Space）。

作为物理内存的扩展，linux会在物理内存不足时，使用交换分区的虚拟内存，更详细的说，就是内核会将暂时不用的内存块信息写到交换空间，这样以来，物理内存得到了释放，这块内存就可以用于其它目的，当需要用到原始的内容时，这些信息会被重新从交换空间读入物理内存。

Linux的内存管理采取的是分页存取机制，为了保证物理内存能得到充分的利用，内核会在适当的时候将物理内存中不经常使用的数据块自动交换到虚拟内存中，而将经常使用的信息保留到物理内存。

要深入了解linux内存运行机制，需要知道下面提到的几个方面：

Linux系统会不时的进行页面交换操作，以保持尽可能多的空闲物理内存，即使并没有什么事情需要内存，Linux也会交换出暂时不用的内存页面。这可以避免等待交换所需的时间。

Linux 进行页面交换是有条件的，不是所有页面在不用时都交换到虚拟内存，linux内核根据”最近最经常使用“算法，仅仅将一些不经常使用的页面文件交换到虚拟 内存，有时我们会看到这么一个现象：linux物理内存还有很多，但是交换空间也使用了很多。其实，这并不奇怪，例如，一个占用很大内存的进程运行时，需 要耗费很多内存资源，此时就会有一些不常用页面文件被交换到虚拟内存中，但后来这个占用很多内存资源的进程结束并释放了很多内存时，刚才被交换出去的页面 文件并不会自动的交换进物理内存，除非有这个必要，那么此刻系统物理内存就会空闲很多，同时交换空间也在被使用，就出现了刚才所说的现象了。关于这点，不 用担心什么，只要知道是怎么一回事就可以了。

交换空间的页面在使用时会首先被交换到物理内存，如果此时没有足够的物理内存来容纳这些页 面，它们又会被马上交换出去，如此以来，虚拟内存中可能没有足够空间来存储这些交换页面，最终会导致linux出现假死机、服务异常等问题，linux虽 然可以在一段时间内自行恢复，但是恢复后的系统已经基本不可用了。

因此，合理规划和设计Linux内存的使用，是非常重要的.

在Linux 操作系统中，当应用程序需要读取文件中的数据时，操作系统先分配一些内存，将数据从磁盘读入到这些内存中，然后再将数据分发给应用程序；当需要往文件中写 数据时，操作系统先分配内存接收用户数据，然后再将数据从内存写到磁盘上。然而，如果有大量数据需要从磁盘读取到内存或者由内存写入磁盘时，系统的读写性 能就变得非常低下，因为无论是从磁盘读数据，还是写数据到磁盘，都是一个很消耗时间和资源的过程，在这种情况下，Linux引入了buffers和 cached机制。

buffers与cached都是内存操作，用来保存系统曾经打开过的文件以及文件属性信息，这样当操作系统需要读取某些文件时，会首先在buffers 与cached内存区查找，如果找到，直接读出传送给应用程序，如果没有找到需要数据，才从磁盘读取，这就是操作系统的缓存机制，通过缓存，大大提高了操 作系统的性能。但buffers与cached缓冲的内容却是不同的。

buffers是用来缓冲块设备做的，它只记录文件系统的元数据（metadata）以及 tracking in-flight pages，而cached是用来给文件做缓冲。更通俗一点说：buffers主要用来存放目录里面有什么内容，文件的属性以及权限等等。而cached直接用来记忆我们打开过的文件和程序。

为了验证我们的结论是否正确，可以通过vi打开一个非常大的文件，看看cached的变化，然后再次vi这个文件，感觉一下两次打开的速度有何异同，是不是第二次打开的速度明显快于第一次呢？接着执行下面的命令：

find / -name .conf 看看buffers的值是否变化，然后重复执行find命令，看看两次显示速度有何不同。

上面这个60代表物理内存在使用40%的时候才会使用swap（参考网络资料：当剩余物理内存低于40%（40=100-60）时，开始使用交换空间） swappiness=0的时候表示最大限度使用物理内存，然后才是 swap空间，swappiness＝100的时候表示积极的使用swap分区，并且把内存上的数据及时的搬运到swap空间里面。

值越大表示越倾向于使用swap。可以设为0，这样做并不会禁止对swap的使用，只是最大限度地降低了使用swap的可能性。

通常情况下：swap分区设置建议是内存的两倍 （内存小于等于4G时），如果内存大于4G，swap只要比内存大就行。另外尽量的将swappiness调低，这样系统的性能会更好。

B. 修改swappiness参数

永久性修改：

立即生效，重启也可以生效。

一般系统是不会自动释放内存的 关键的配置文件/proc/sys/vm/drop_caches。这个文件中记录了缓存释放的参数，默认值为0，也就是不释放缓存。他的值可以为0~3之间的任意数字，代表着不同的含义：

0 – 不释放 1 – 释放页缓存 2 – 释放dentries和inodes 3 – 释放所有缓存

前提：首先要保证内存剩余要大于等于swap使用量，否则会宕机！根据内存机制，swap分区一旦释放，所有存放在swap分区的文件都会转存到物理内存上。通常通过重新挂载swap分区完成释放swap。
a.查看当前swap分区挂载在哪？b.关停这个分区 c.查看状态：d.查看swap分区是否关停，最下面一行显示全 e.将swap挂载到/dev/sda5上 f.查看挂载是否成功

❾ linux内核机制有哪些

在学习linux内核同步机制之前，先要了解以下预备知识：（临界资源与并发源）
在linux系统中，我们把对共享的资源进行访问的代码片段称为临界区。把导致出现多个进程对同一共享资源进行访问的原因称为并发源。
Linux系统下并发的主要来源有：
中断处理：例如，当进程在访问某个临界资源的时候发生了中断，随后进入中断处理程序，如果在中断处理程序中，也访问了该临界资源。虽然不是严格意义上的并发，但是也会造成了对该资源的竞态。
内核态抢占：例如，当进程在访问某个临界资源的时候发生内核态抢占，随后进入了高优先级的进程，如果该进程也访问了同一临界资源，那么就会造成进程与进程之间的并发。
多处理器的并发：多处理器系统上的进程与进程之间是严格意义上的并发，每个处理器都可以独自调度运行一个进程，在同一时刻有多个进程在同时运行 。