记录内核参数的含义和调整的效果, 主要是记录这些参数的含义或者使用它们的方法， 什么场景下需要调整这个。
Linux_Sysctl 参数记录

开始

net.ipv4.tcp_max_tw_buckets

对于tcp连接，服务端和客户端通信完后状态变为timewait，假如某台服务器非常忙，连接数特别多的话，那么这个timewait数量就会越来越大。毕竟它也是会占用一定的资源，所以应该有一个最大值，当超过这个值，系统就会删除最早的连接，这样始终保持在一个数量级。
这个数值就是由net.ipv4.tcp_max_tw_buckets这个参数来决定的。CentOS7系统，你可以使用sysctl -a |grep tw_buckets来查看它的值，默认为32768，你可以适当把它调低，比如调整到8000，毕竟这个状态的连接太多也是会消耗资源的。
但你不要把它调到几十、几百这样，因为这种状态的tcp连接也是有用的，如果同样的客户端再次和服务端通信，就不用再次建立新的连接了，用这个旧的通道，省时省力。

net.ipv4.tcp_tw_recycle

在最新版本的内核中， 这个已经被移除， 这个参数在具有nat网络结构和行为的时候会导致出现异常。

net.ipv4.tcp_tw_reuse

该参数设置为1，将timewait状态的连接重新用于新的TCP连接，这个参数本身其实开开启就可以了， 他可以快速的回收处于timewait的socket， 生效在客户端。

net.ipv4.tcp_syncookies

tcp三次握手中，客户端向服务端发起syn请求，服务端收到后，也会向客户端发起syn请求同时连带ack确认，假如客户端发送请求后直接断开和服务端的连接，不接收服务端发起的这个请求，服务端会重试多次。
这个重试的过程会持续一段时间，当这种状态的连接数量非常大时，服务器会消耗很大的资源，从而造成瘫痪，正常的连接进不来，这种恶意的半连接行为其实叫做syn flood攻击。
设置为1，是开启SYN Cookies，开启后可以避免发生上述的syn flood攻击。开启该参数后，服务端接收客户端的ack后，再向客户端发送ack+syn之前会要求client在短时间内回应一个序号，如果客户端不能提供序号或者提供的序号不对则认为该客户端不合法，于是不会发ack+syn给客户端，更涉及不到重试。

net.ipv4.tcp_max_syn_backlog

该参数定义系统能接受的最大半连接状态的tcp连接数。客户端向服务端发送了syn包，服务端收到后，会记录一下，该参数决定最多能记录几个这样的连接。我的CentOS7系统，默认是256，当有syn flood攻击时，这个数值太小则很容易导致服务器瘫痪，实际上此时服务器并没有消耗太多资源（cpu、内存等），所以可以适当调大它，比如调整到30000。

net.ipv4.tcp_syn_retries

该参数适用于客户端，它定义发起syn的最大重试次数，默认为5，建议改为2。

net.ipv4.tcp_synack_retries

该参数适用于服务端，它定义发起syn+ack的最大重试次数，默认为5，建议改为2，可以适当预防syn flood攻击。

net.ipv4.ip_local_port_range

该参数定义端口范围，系统默认保留端口为1024及以下，以上部分为自定义端口。这个参数适用于客户端，当客户端和服务端建立连接时，比如说访问服务端的80端口，客户端随机开启了一个端口和服务端发起连接，这个参数定义随机端口的范围。默认为32768    61000，建议调整为1025 61000。

net.ipv4.tcp_fin_timeout

tcp连接的状态中，客户端上有一个是FIN-WAIT-2状态，它是状态变迁为timewait前一个状态。该参数定义不属于任何进程的该连接状态的超时时间，默认值为60，建议调整为6。

net.ipv4.tcp_keepalive_time

tcp连接状态里，有一个是keepalived状态，只有在这个状态下，客户端和服务端才能通信。正常情况下，当通信完毕，客户端或服务端会告诉对方要关闭连接，此时状态就会变为timewait，如果客户端没有告诉服务端，并且服务端也没有告诉客户端关闭的话（例如，客户端那边断网了），此时需要该参数来判定。
比如客户端已经断网了，但服务端上本次连接的状态依然是keepalived，服务端为了确认客户端是否断网，就需要每隔一段时间去发一个探测包去确认一下看看对方是否在线。这个时间就由该参数决定。它的默认值为7200（单位为秒），建议设置为30。

net.ipv4.tcp_keepalive_intvl

该参数和上面的参数是一起的，服务端在规定时间内发起了探测，查看客户端是否在线，如果客户端并没有确认，此时服务端还不能认定为对方不在线，而是要尝试多次。该参数定义重新发送探测的时间，即第一次发现对方有问题后，过多久再次发起探测。
默认值为75秒（单位为秒），可以改为3。

net.ipv4.tcp_keepalive_probes

第10和第11个参数规定了何时发起探测和探测失败后再过多久再发起探测，但并没有定义一共探测几次才算结束。该参数定义发起探测的包的数量。默认为9，建议设置2。

net.ipv4.tcp_slow_start_after_idl

这个推荐直接设置为0 ， 在tcp连接多而且数据交互频繁的时候， 这个参数没有特别大的影响， 但是对于间隔一段时间这类的网络请求， 确实是会有影响的， 会导致走 慢启动 拉长延迟

sysctl -w  net.ipv4.tcp_slow_start_after_idle = 0 
echo "net.ipv4.tcp_slow_start_after_idle = 0" >> /etc/sysctl.conf

vm.vfs_cache_pressure

这是关于 vfs 层面内核回收 inode 和 dentry 倾向的设置.

  • 大于 100 以为积极回收.
  • 小于 100 以为尽可能减少回收,那么会占用更多内存.
  • 等于 0 意味着不会回收 dentry 和 inode, 即使在内存压力的场景下.

基于 GlusterFS 的文档说明: https://docs.gluster.org/en/latest/Administrator-Guide/Linux-Kernel-Tuning/#vmvfs_cache_pressure

通常情况下不应该更改默认值.

vm.vfs_cache_pressure = 100

更多

tcp协议的网络流量控制 [[../Network/Network_tc控制流量-update|Network_tc控制流量-update]]
Amazon Linux 2 完整的sysctl参数 [[Linux_Sysctl 参数记录]]
Linux操作系统触发NMI中断调试和Kdump [[Linux_DebugLinuxCrashOnEC2]]