Sysctl命令用来配置与显示在/proc/sys目录中的内核参数．如果想使参数长期保存，可以通过编辑/etc/sysctl.conf文件来实现。
命令格式：
sysctl [-n] [-e]
-w #临时改变某个指定参数的值，如
sysctl -w net.ipv4.ip_forward=1
-a #显示所有的系统参数
-p #从指定的文件加载系统参数,默认从/etc/sysctl.conf 文件中加载
# echo 1 > /proc/sys/net/ipv4/ip_forward
# sysctl -w net.ipv4.ip_forward=1
以上两种方法都可能立即开启路由功能，临时修改，重启失效
一丶CPU和中断调优
知识简介
：
SMP（symmetrical mulit-processing）：对称多处理器，在对称多处理器系统中，所有处理器的地位都是相同的，所有的资源，特别是存储器、中断及I/O空间，都具有相同的可访问性，消除了结构上的障碍
NUMA（Non Uniform Memory Access Architecture）：非一致性内存访问，是一种用于多处理器的
电脑记忆体设计，内存访问时间取决于处理器的内存位置。 在NUMA下，处理器访问它自己的本地存储器的速度比非本地存储器（存储器的地方到另一个处理器之间共享的处理器或存储器）快一些
CPU亲缘性
：分为软亲缘性和硬亲缘性
，Linux 内核进程调度器天生就具有CPU 软亲缘性（soft affinity），这意味着进程通常不会在处理器之间频繁迁移。但不代表不会进行小范围的迁移。CPU 硬亲缘性是指通过Linux提供的相关CPU亲缘性设置接口，显示的指定某个进程固定的某个处理器上运行。可以通过taskset或者glibc库中的sched_getaffinity接口设置。
IO设备和进程之间的数据传送方式主要有4种，（程序直接控制方式、中断控制方式、DMA方式和通道方式）。对于Linux系统而言第2,3种IO控制方式是主流采用的，通道控制方式虽然更高效，但是由于需要添加专门的通道协处理器，故而成本较高，常用于专用场景
- 程序控制方式：又被称为“忙等”模式，即当要在内存和IO设备之间进行信息传输时，由CPU向相应的设备发出命令，由设备控制器控制IO设备进行实际操作。在IO设备工作时，CPU执行一段循环测试程序，不断测试IO设备的完成状况，根据完成状况决定下一步操作。在此期间，CPU只能等待IO设备完成所有的数据传输，CPU和设备只能串行工作，并不能进行其他操作。
- 中断控制方式：CPU向相应的IO设备发出读写命令后，不必等待而转向执行其他进程，由设备控制器控制IO设备完成所有的实际操作，然后当前进程放弃对CPU的占用，进入休眠等待状态。IO设备完成单次数据传输并会主动出发一次中断信号（单次传输数据量是设备控制器的数据缓冲寄存器的容量，如磁盘单次读取容量便是一个扇区，如果一次要读入一个磁盘块的大小数据，则需要中断2次…），通知CPU本次IO完成，然后CPU会将控制权转向中断处理程序，让其对此情况作出相应反应
- DMA（direct memory access)工作方式：当某一进程提出一次单次大批量数据请求，则首先CPU规划好这批数据在进程的虚拟空间的位置，并事先完成虚拟内存到实际内存的映射关系（虚拟内存那端肯定是连续的堆空间，而实际内存这段操作系统一般也会尽可能在DMA区中划分出连续的实际内存空间以匹配），然后CPU将规划好的内存起始地址和size发送给DMA控制器中的内存地址寄存器和size计数器，然后由DMA控制器驱动硬盘驱动程序完成本次全部的IO请求，直到输入完成后，DMA控制器才发出中断信号告知CPU激活中断程序完成中断处理。
- 通道控制方式便是引入一个功能较为简单的协处理机，它可以接受CPU发来的IO命令，通道作为处理机也有自己的一套指令集，可以独立执行通道程序，对IO设备进行控制。通道的引入CPU可以专心计算，而把IO任务完全交给通道完成，二者各负其责。二者分工使得计算和IO操作可以并行，即CPU和设备并行工作，从而提高资源的利用率
IRQ（Interrupt Request）：中断请求，IRQ的作用就是在我们所用的电脑中，执行硬件中断请求的动作，比如我们需要读取硬盘中的一段数据时，当数据读取完毕，硬盘就通过IRQ来通知系统，相应的数据已经写到指定的内存中了
ISR：中断服务路由
中断向量：是指早期的
微机系统中将由硬件产生的中断标识码，当中断发生后，CPU就根据中断向量表来决定应该跳转到哪里
大异常：内存中未找到数据，需要到磁盘查找
小异常：内存中未找到数据，但在共享内存中存在，可以直接在共享内存中查找
Buffer（缓冲区）是系统两端处理速度平衡（从长时间尺度上看）时使用的。它的引入是为了减小短期内突发I/O的影响，起到流量整形的作用。比如生产者——消费者问题，他们产生和消耗资源的速度大体接近，加一个buffer可以抵消掉资源刚产生/消耗时的突然变化。
Cache（缓存）则是系统两端处理速度不匹配时的一种折衷策略。因为CPU和memory之间的速度差异越来越大，所以人们充分利用数据的局部性（locality）特征，通过使用存储系统分级（memory hierarchy）的策略来减小这种差异带来的影响。
调优
isolcpus=2,3 #调整参数，系统启动后将不使用CPU2和3，参数在/etc/grup.conf文件中root=LABEL=/后面添加isolcpus=cpu号列表，cpu号从0开始，多个cpu号之间用“,”分隔
taskset -pc cpu 列表 pid#将进程绑定到cpu，例taskset -pc 1,2 pid
ps axo pid,psr #查看进程运行在第几颗CPU
cat /proc/interraps #查看中断对应的CPU
echo “cpu” >/proc/irq/中断号/smp_affinity #绑定中断到某CPU
二丶进程
知识简介
：
进程分为实时进程和普通进程，实时进程具有一定程度上的紧迫性，要求对外部事件做出非常快的响应；而普通进程则没有这种限制。所以通常，实时进程要比普通进程优先运行
实时进程的优先级为1-99，越大优先级越高，调度策略如下
1，SCHED_FIFO 实时调度策略，先到先服务，一直运行直到有更高优先级任务到达或自己放弃
2，SCHED_RR 实时调度策略，时间片轮转，进程的时间片用完，系统将重新分配时间片，并置于就绪队列尾
普通进程的优先级为100-139，越小优先级越高，调度策略如下
1，SCHED_OTHER 分时调度策略，当实时进程准备就绪后，如果当前cpu正在运行非实时进程，则实时进程立即抢占非实时进程
调优
nice -n num CMD #调整nice值，-n范围-20到19，越小越容易执行，内核
会自动调整
renice priority [[-p] pid ...] [[-g] pgrp ...] [[-u] user ...]
- -p pid pid 的，例如：renice +15 785
- -g pgrp 组的
- -u user 用户的
chrt -p -r（rr策略）优先级 pid #调整进程调度策略，例chrt -p -f 10 1234 修改调度策略为SCHED_FIFO,并且优先级为10
三丶内存
linux 系统中内存地址分为虚拟地址和物理地址，虚拟地址必须通过mmu映射成物理地址。为了完成虚拟地址到物理地址的映射，linux内核中必须为每一个用户态进程维护一个页目录和相应的页表项。一般系统中页表中一页大小为4K，利用getconf PAGESIZE可以获取系统中页大小。
Zone的buddy （linux伙伴系统）：为了将系统中的内存页做相应的管理，linux内核将系统中内存为分为不同的node，zone. 系统将不同cpu访问速率的内存归纳为不同的node.zone表示同一个node不同内存区域，一般分问DMA， NORMAL， HIGHMEM.为了连续分配内存页创建
Slab Allocator：主要管理小内存分配
bdflush：刷写，流程：bio（block io buffer） 调用bdflush，io scheduler 排序，device driver驱动写入到disk
kswapd内核线程：用来处理页面的交换，它可以在内存不足时，将一些进程的页面交换到swap空间之中。
PAE：物理地址扩展，用于32位扩展寻址，即在地址总线外加四根线
回写就是先写到内存在写到磁盘，
通写就是写到磁盘之后返回完成
oom_killer：它会在系统内存耗尽的情况下，启用自己算法有选择性的kill 掉一些进程
在x86_32位Linux系统内存中，0-3G为用户空间，3G~4G为内核空间，内核空间分为3部分，ZONE_DMA，ZONE_NORMAL，ZONE_HIGHMEME。
- ZONE_DMA，0-16M，直接内存访问。该区域的物理页面专门供I/O设备的DMA使用。之所以需要单独管理DMA的物理页面，是因为DMA使用物理地址访问内存，不经过MMU，并且需要连续的缓冲区，所以为了能够提供物理上连续的缓冲区，必须从物理地址空间专门划分一段区域用于DMA。这部分的数据可以直接访问，目的在于加快磁盘和内存之间交换数据，数据不需要经过总线流向CPU的PC寄存器，再流向物理内存，直接通过总线就可到达物理内存。
- ZONR_NORMAL，16M-896M，内核最重要的部分，该区域的物理页面是内核能够直接使用的。
- ZONE_HIGHMEM，896M-结束，共128M，高端内存。主要用于32位Linux系统中，映射高于1G的物理内存。64位不需要高端内存。
调优
/proc/sys/vm/overcommit_memory
- 0：默认设置，内核执行启发式的过量使用处理
- 1：内核执行总是过量使用处理，使用这个值会增大内存超载的可能性
- 2：设置内存使用量等于swap的大小+RAM*overcommit_ratio的值。如果希望减小内存的过度使用，这个值是最安全的
/proc/sys/vm/overcommit_ratio #默认值是50，用于虚拟内存的物理内存的百分比
/proc/sys/vm/max_map_count #运行单个进程使用的最大内存，防止oom
/proc/sys/vm/nr_hugepages #允许使用的大页面（4M）数
/proc/sys/vm/page-cluster #一次清到swap上的页面数量，作为幂指数的值，默认为3，意味着可转移2^3=8个页面到swap
/proc/sys/vm/drop_caches #0，1表示清空页缓存，2表示清空inode和目录树缓存，3清空所有的缓存，记得先sync
/proc/sys/vm/dirty_ratio #单个进程脏页达到的百分比之后启动刷写线程
/proc/sys/vm/dirty_background_ratio #整个系统脏页达到百分比之后启动刷写线程
/proc/sys/vm/dirty_expire_centisecs #脏数据最多存在多长时间后启动刷写线程
/proc/sys/vm/dirty_writeback_centisecs #每隔多长时间启动刷写线程
/proc/sys/vm/swappiness #是否使用swap分区，及使用的比例。值越大，内核会越倾向于使用swap。如果设置为0，内核只有在空闲的和基于文件的内存页数量小于内存域的高水位线（应该指的是watermark[high]）时才开始swap
/proc/sys/vm/panic_on_oom
- 0，内核会杀死内存占用过多的进程。通常杀死内存占用最多的进程，系统就会恢复。
- 1，在发生OOM时，内核会panic。然而，如果一个进程通过内存策略或进程绑定限制了可以使用的节点，并且这些节点的内存已经耗尽，oom-killer可能会杀死一个进程来释放内存。在这种情况下，内核不会panic，因为其他节点的内存可能还有空闲，这意味着整个系统的内存状况还没有处于崩溃状态。
- 2，在发生OOM时总是会强制panic，即使在上面讨论的情况下也一样。即使在memory cgroup限制下发生的OOM，整个系统也会panic。
进程的oom值可在/proc/pid/oom_adj 进行调整，-17不杀，越大越容易被杀，
四丶io调度
io调度的四种调度策略
1) NOOP（No Operation）。
该算法实现了最最简单的FIFO队列，所有IO请求大致按照先来后到的顺序进行操作。之所以说“大致”，原因是NOOP在FIFO的基础上还做了相邻IO请求的合并，并不是完完全全按照先进先出的规则满足IO请求。NOOP假定I/O请求由驱动程序或者设备做了优化或者重排了顺序(就像一个智能控制器完成的工作那样)。在有些SAN环境下，这个选择可能是最好选择。Noop 对于 IO 不那么操心，对所有的 IO请求都用 FIFO 队列形式处理，默认认为 IO 不会存在性能问题。这也使得 CPU 也不用那么操心。当然，对于复杂一点的应用类型，使用这个调度器，用户自己就会非常操心。
2) Deadline scheduler
DEADLINE在CFQ的基础上，解决了IO请求饿死的极端情况。除了CFQ本身具有的IO排序队列之外，DEADLINE额外分别为读IO和写IO提供了FIFO队列。读FIFO队列的最大等待时间为500ms，写FIFO队列的最大等待时间为5s。FIFO队列内的IO请求优先级要比CFQ队列中的高，，而读FIFO队列的优先级又比写FIFO队列的优先级高。优先级可以表示如下： FIFO(Read) > FIFO(Write) > CFQ
deadline 算法保证对于既定的 IO 请求以最小的延迟时间，从这一点理解，对于 DSS 应用应该会是很适合的。
3) Anticipatory scheduler （不常用）
CFQ和DEADLINE考虑的焦点在于满足零散IO请求上。对于连续的IO请求，比如顺序读，并没有做优化。为了满足随机IO和顺序IO混合的场景，Linux还支持ANTICIPATORY调度算法。ANTICIPATORY的在DEADLINE的基础上，为每个读IO都设置了6ms 的等待时间窗口。如果在这6ms内OS收到了相邻位置的读IO请求，就可以立即满足。Anticipatory scheduler（as) 曾经一度是 Linux 2.6 Kernel 的 IO scheduler 。Anticipatory 的中文含义是”预料的, 预想的”, 这个词的确揭示了这个算法的特点，简单的说，有个 IO 发生的时候，如果又有进程请求 IO 操作，则将产生一个默认的 6 毫秒猜测时间，猜测下一个 进程请求 IO 是要干什么的。这对于随即读取会造成比较大的延时，对数据库应用很糟糕，而对于 Web Server 等则会表现的不错。这个算法也可以简单理解为面向低速磁盘的，因为那个”猜测”实际上的目的是为了减少磁头移动时间。
4）CFQ（Completely Fair Queuing 完全公平队列）
该算法的特点是按照IO请求的地址进行排序，而不是按照先来后到的顺序来进行响应。
在传统的SAS盘上，磁盘寻道花去了绝大多数的IO响应时间。CFQ的出发点是对IO地址进行排序，以尽量少的磁盘旋转次数来满足尽可能多的IO请求。在CFQ算法下，SAS盘的吞吐量大大提高了。但是相比于NOOP的缺点是，先来的IO请求并不一定能被满足，可能会出现饿死的情况。 cfq 在 2.6.18 取代了 Anticipatory scheduler 成为 Linux Kernel 默认的 IO scheduler 。cfq 对每个进程维护一个 IO 队列，各个进程发来的 IO 请求会被 cfq 以轮循方式处理。也就是对每一个 IO 请求都是公平的。这使得 cfq 很适合离散读的应用(eg: OLTP DB)。我所知道的企业级 Linux 发行版中，SuSE Linux 好像是最先默认用 cfq 的. cfq的调度优先类分为三种
- ilde：空闲磁盘调度，该调度策略是在当前系统没有其他进程需要进行磁盘IO时，才能进行磁盘；因此该策略对当前系统的影响基本为0；当然，该调度策略不能带有任何优先级参数；目前，普通用户是可以使用该调度策略（自从内核2.6.25开始）。
- Best effort：是缺省的磁盘IO调度策略；(1)该调度策略可以指定优先级参数(范围是0~7，数值越小，优先级越高)；(2)针对处于同一优先级的程序将采round-robin方式；(3)对于best effort调度策略，8个优先级等级可以说明在给定的一个调度窗口中时间片的大小。(4)目前，普调用户(非root用户)是可以使用该调度策略。(5)在内核2.6.26之前，没有设置IO优先级的进程会使用“none”作为调度策略，但是这种策略使得进程看起来像是采用了best effort调度策略，因为其优先级是通过关于cpu nice有关的公式计算得到的：io_priority = (cpu_nice + 20) /5。(6)在内核2.6.26之后，如果当前系统使用的是CFQ调度器，那么如果进程没有设置IO优先级级别，将采用与内核2.6.26之前版本同样的方式，推到出io优先级级别。
- Real time：实时调度策略，如果设置了该磁盘IO调度策略，则立即访问磁盘，不管系统中其他进程是否有IO。因此使用实时调度策略，需要注意的是，该访问策略可能会使得其他进程处于等待状态
调优
cat /sys/block/sda/queue/scheduler
echo “cfq” > /sys/block/sda/queue/scheduler
ionice [[-c class] [-n classdata] [-t]] -p PID [PID]…
ionice [-c class] [-n classdata] [-t] COMMAND [ARG]…
-c class ：class表示调度策略，其中0 none, 1 real time, 2 best-effort, 3idle。
-n classdata：classdata表示IO优先级级别，对于best effort和real time，classdata可以设置为0~7。
-p pid：指定要查看或设置的进程号或者线程号，如果没有指定pid参数，ionice will run the listed program with the given parameters。
-t ：忽视设置优先级时产生的错误。
COMMAND：表示命令名
总结:
1 CFQ和DEADLINE考虑的焦点在于满足零散IO请求上。对于连续的IO请求，比如顺序读，并没有做优化。为了满足随机IO和顺序IO混合的场景，Linux还支持ANTICIPATORY调度算法。ANTICIPATORY的在DEADLINE的基础上，为每个读IO都设置了6ms的等待时间窗口。如果在这6ms内OS收到了相邻位置的读IO请求，就可以立即满足。 IO调度器算法的选择，既取决于硬件特征，也取决于应用场景。 在传统的SAS盘上，CFQ、DEADLINE、ANTICIPATORY都是不错的选择；对于专属的数据库服务器DEADLINE的吞吐量和响应时间都表现良好。然而在新兴的固态硬盘比如SSD、Fusion IO上，最简单的NOOP反而可能是最好的算法，因为其他三个算法的优化是基于缩短寻道时间的，而固态硬盘没有所谓的寻道时间且IO响应时间非常短。
2 对于数据库应用, Anticipatory Scheduler 的表现是最差的。Deadline 在 DSS 环境表现比 cfq 更好一点，而 cfq 综合来看表现更好一些。这也难怪 RHEL 4 默认的 IO 调度器设置为 cfq. 而 RHEL 4 比 RHEL 3，整体 IO 改进还是不小的。
五丶网络调优
|
参数（路径+文件）
|
描述
|
默认值
|
优化值
|
|
/proc/sys/net/core/rmem_default
|
默认的TCP数据接收窗口大小（字节）。
|
229376
|
256960
|
|
/proc/sys/net/core/rmem_max
|
最大的TCP数据接收窗口（字节）。
|
131071
|
513920
|
|
/proc/sys/net/core/wmem_default
|
默认的TCP数据发送窗口大小（字节）。
|
229376
|
256960
|
|
/proc/sys/net/core/wmem_max
|
最大的TCP数据发送窗口（字节）。
|
131071
|
513920
|
|
/proc/sys/net/core/netdev_max_backlog
|
在每个网络接口接收数据包的速率比内核处理这些包的速率快时，允许送到队列的数据包的最大数目。
|
1000
|
2000
|
|
/proc/sys/net/core/somaxconn
|
定义了系统中每一个端口最大的监听队列的长度，这是个全局的参数。
|
128
|
2048
|
|
/proc/sys/net/core/optmem_max
|
表示每个套接字所允许的最大缓冲区的大小。
|
20480
|
81920
|
|
/proc/sys/net/ipv4/tcp_mem
|
确定TCP栈应该如何反映内存使用，每个值的单位都是内存页（通常是4KB）。第一个值是内存使用的下限；第二个值是内存压力模式开始对缓冲区使用应用压力的上限；第三个值是内存使用的上限。在这个层次上可以将报文丢弃，从而减少对内存的使用。对于较大的BDP可以增大这些值（注意，其单位是内存页而不是字节）。
|
94011 125351 188022
|
131072 262144 524288
|
|
/proc/sys/net/ipv4/tcp_rmem
|
为自动调优定义socket使用的内存。第一个值是为socket接收缓冲区分配的最少字节数；第二个值是默认值（该值会被rmem_default覆盖），缓冲区在系统负载不重的情况下可以增长到这个值；第三个值是接收缓冲区空间的最大字节数（该值会被rmem_max覆盖）。
|
4096 87380 4011232
|
8760 256960 4088000
|
|
/proc/sys/net/ipv4/tcp_wmem
|
为自动调优定义socket使用的内存。第一个值是为socket发送缓冲区分配的最少字节数；第二个值是默认值（该值会被wmem_default覆盖），缓冲区在系统负载不重的情况下可以增长到这个值；第三个值是发送缓冲区空间的最大字节数（该值会被wmem_max覆盖）。
|
4096 16384 4011232
|
8760 256960 4088000
|
|
/proc/sys/net/ipv4/tcp_keepalive_time
|
TCP发送keepalive探测消息的间隔时间（秒），用于确认TCP连接是否有效。
|
7200
|
1800
|
|
/proc/sys/net/ipv4/tcp_keepalive_intvl
|
探测消息未获得响应时，重发该消息的间隔时间（秒）。
|
75
|
30
|
|
/proc/sys/net/ipv4/tcp_keepalive_probes
|
在认定TCP连接失效之前，最多发送多少个keepalive探测消息。
|
9
|
3
|
|
/proc/sys/net/ipv4/tcp_sack
|
启用有选择的应答（1表示启用），通过有选择地应答乱序接收到的报文来提高性能，让发送者只发送丢失的报文段，（对于广域网通信来说）这个选项应该启用，但是会增加对CPU的占用。
|
1
|
1
|
|
/proc/sys/net/ipv4/tcp_fack
|
启用转发应答，可以进行有选择应答（SACK）从而减少拥塞情况的发生，这个选项也应该启用。
|
1
|
1
|
|
/proc/sys/net/ipv4/tcp_timestamps
|
TCP时间戳（会在TCP包头增加12个字节），以一种比重发超时更精确的方法（参考RFC 1323）来启用对RTT 的计算，为实现更好的性能应该启用这个选项。
|
1
|
1
|
|
/proc/sys/net/ipv4/tcp_window_scaling
|
启用RFC 1323定义的window scaling，要支持超过64KB的TCP窗口，必须启用该值（1表示启用），TCP窗口最大至1GB，TCP连接双方都启用时才生效。
|
1
|
1
|
|
/proc/sys/net/ipv4/tcp_syncookies
|
表示是否打开TCP同步标签（syncookie），内核必须打开了CONFIG_SYN_COOKIES项进行编译，同步标签可以防止一个套接字在有过多试图连接到达时引起过载。
|
1
|
1
|
|
/proc/sys/net/ipv4/tcp_tw_reuse
|
表示是否允许将处于TIME-WAIT状态的socket（TIME-WAIT的端口）用于新的TCP连接 。
|
0
|
1
|
|
/proc/sys/net/ipv4/tcp_tw_recycle
|
能够更快地回收TIME-WAIT套接字。
|
0
|
1
|
|
/proc/sys/net/ipv4/tcp_fin_timeout
|
对于本端断开的socket连接，TCP保持在FIN-WAIT-2状态的时间（秒）。对方可能会断开连接或一直不结束连接或不可预料的进程死亡。
|
60
|
30
|
|
/proc/sys/net/ipv4/ip_local_port_range
|
表示TCP/UDP协议允许使用的本地端口号
|
32768 61000
|
1024 65000
|
|
/proc/sys/net/ipv4/tcp_max_syn_backlog
|
对于还未获得对方确认的连接请求，可保存在队列中的最大数目。如果服务器经常出现过载，可以尝试增加这个数字。
|
2048
|
2048
|
|
/proc/sys/net/ipv4/tcp_max_tw_bucket
|
处于timewait的连接数
|
|
|
|
/proc/sys/net/ipv4/tcp_synack_retries
|
第二次握手的重发数
|
|
忙时设为1或0
|
|
/proc/sys/net/ipv4/tcp_syn_retires
|
服务器连接客户端时，第一次握手重发数
|
|
|
|
/proc/sys/net/ipv4/tcp_max_orphans
|
tcp套接字，请求到达还未来的及监理句柄允许的最大值，可防DOS攻击
|
|
|
|
/proc/sys/net/ipv4/tcp_fin_timeout
|
四次断开第二阶段的超时时间FIN_WAIT_2
|
|
|
|
/proc/sys/net/ipv4/tcp_low_latency
|
允许TCP/IP栈适应在高吞吐量情况下低延时的情况，这个选项应该禁用。
|
0
|
|
|
/proc/sys/net/ipv4/tcp_westwood
|
启用发送者端的拥塞控制算法，它可以维护对吞吐量的评估，并试图对带宽的整体利用情况进行优化，对于WAN 通信来说应该启用这个选项。
|
0
|
|
|
/proc/sys/net/ipv4/tcp_bic
|
为快速长距离网络启用Binary Increase Congestion，这样可以更好地利用以GB速度进行操作的链接，对于WAN通信应该启用这个选项。
|
1
|
|
六丶进程间通信
/proc/sys/kernel/msgmax #单个消息最大值，字节
/proc/sys/kernel/msgmnb #队列最大值，字节，单个队列可多个消息
/proc/sys/kernel/msgmni #最大队列数
/proc/sys/kernel/shmall #共享内存总量
/proc/sys/kernel/shmmax #共享内存片上限单个大小
/proc/sys/kernel/shmmni #共享内存片数量
七丶其他
/proc/sys/kernel/threads-max #内核一次可以创建的线程数
/proc/sys/fs/file-max #内核打开的文件最大数
查看服务器运行状态的常用命令：sar、tsar、dstat、top、htop、ifotp、lsof、glances、vmstat、ss、iostat、vmstat、dstat、netstat、等好多
