linux内核参数注释与优化
参考文章：
linux内核TCP相关参数解释
http://os.chinaunix.net/a2008/0918/985/000000985483.shtml
linux内核参数优化
http://blog.chinaunix.net/uid-29081804-id-3830203.html
linux内核调整和内核参数详解
http://blog.csdn.net/cnbird2008/article/details/4419354
linux内核参数注释
以下表格中红色字体为常用优化参数
根据参数文件所处目录不同而进行分表整理
下列文件所在目录：/proc/sys/net/ipv4/
所处目录/proc/sys/net/ipv4/netfilter/
文件需要打开防火墙才会存在
| 名称 | 默认值 | 建议值 | 描述 |
| ip_conntrack_max | 65536 | 65536 | 系统支持的最大ipv4连接数，默认65536（事实上这也是理论最大值），同时这个值和你的内存大小有关，如果内存128M，这个值最大8192，1G以上内存这个值都是默认65536,这个值受/proc/sys/net/ipv4/ip_conntrack_max限制 |
| ip_conntrack_tcp_timeout_established | 432000 | 180 | 已建立的tcp连接的超时时间，默认432000，也就是5天。影响：这个值过大将导致一些可能已经不用的连接常驻于内存中，占用大量链接资源，从而可能导致NAT ip_conntrack: table full的问题。建议：对于NAT负载相对本机的 NAT表大小很紧张的时候，可能需要考虑缩小这个值，以尽早清除连接，保证有可用的连接资源；如果不紧张，不必修改 |
| ip_conntrack_tcp_timeout_time_wait | 120 | 120 | time_wait状态超时时间，超过该时间就清除该连接 |
| ip_conntrack_tcp_timeout_close_wait | 60 | 60 | close_wait状态超时时间，超过该时间就清除该连接 |
| ip_conntrack_tcp_timeout_fin_wait | 120 | 120 | fin_wait状态超时时间，超过该时间就清除该连接 |
文件所处目录/proc/sys/net/core/
| 名称 | 默认值 | 建议值 | 描述 |
| netdev_max_backlog | 1024 | 16384 | 每个网络接口接收数据包的速率比内核处理这些包的速率快时，允许送到队列的数据包的最大数目，对重负载服务器而言，该值需要调高一点。 |
| somaxconn | 128 | 16384 | 用来限制监听(LISTEN)队列最大数据包的数量，超过这个数量就会导致链接超时或者触发重传机制。
web应用中listen函数的backlog默认会给我们内核参数的net.core.somaxconn限制到128，而nginx定义的NGX_LISTEN_BACKLOG默认为511，所以有必要调整这个值。对繁忙的服务器,增加该值有助于网络性能 |
| wmem_default | 129024 | 129024 | 默认的发送窗口大小（以字节为单位） |
| rmem_default | 129024 | 129024 | 默认的接收窗口大小（以字节为单位） |
| rmem_max | 129024 | 873200 | 最大的TCP数据接收缓冲 |
| wmem_max | 129024 | 873200 | 最大的TCP数据发送缓冲 |
两种修改内核参数方法
1、使用echo value方式直接追加到文件里如echo "1" >/proc/sys/net/ipv4/tcp_syn_retries，但这种方法设备重启后又会恢复为默认值
2、把参数添加到/etc/sysctl.conf中，然后执行sysctl -p使参数生效，永久生效
内核生产环境优化参数
这儿所列参数是老男孩老师生产中常用的参数：
net.ipv4.tcp_syn_retries = 1
net.ipv4.tcp_synack_retries = 1
net.ipv4.tcp_keepalive_time = 600
net.ipv4.tcp_keepalive_probes = 3
net.ipv4.tcp_keepalive_intvl =15
net.ipv4.tcp_retries2 = 5
net.ipv4.tcp_fin_timeout = 2
net.ipv4.tcp_max_tw_buckets = 36000
net.ipv4.tcp_tw_recycle = 1
net.ipv4.tcp_tw_reuse = 1
net.ipv4.tcp_max_orphans = 32768
net.ipv4.tcp_syncookies = 1
net.ipv4.tcp_max_syn_backlog = 16384
net.ipv4.tcp_wmem = 8192 131072 16777216
net.ipv4.tcp_rmem = 32768 131072 16777216
net.ipv4.tcp_mem = 786432 1048576 1572864
net.ipv4.ip_local_port_range = 1024 65000
net.ipv4.ip_conntrack_max = 65536
net.ipv4.netfilter.ip_conntrack_max=65536
net.ipv4.netfilter.ip_conntrack_tcp_timeout_established=180
net.core.somaxconn = 16384
net.core.netdev_max_backlog = 16384
对比网上其他人的生产环境优化参数，需要优化的参数基本差不多，只是值有相应的变化。具体优化值要参考应用场景，这儿所列只是常用优化参数，是否适合，可在上面查看该参数描述，理解后，再根据自己生产环境而设。
其它相关linux内核参数调整文章：
Linux内核参数优化
http://flandycheng.blog.51cto.com/855176/476769
优化linux的内核参数来提高服务器并发处理能力
nginx做web服务器linux内核参数优化
http://blog.csdn.net/force_eagle/article/details/6725243
linux 下Time_wait过多问题解决
TIMEWAIT是友好的
TIMEWAIT状态本身和应用层的客户端或者服务器是没有关系的。仅仅是主动关闭的一方，在使用FIN|ACK|FIN|ACK四分组正常关闭TCP连接的时候会出现这个TIMEWAIT。服务器在处理客户端请求的时候，如果你的程序设计为服务器主动关闭，那么你才有可能需要关注这个TIMEWAIT状态过多的问题。如果你的服务器设计为被动关闭，那么你首先要关注的是CLOSE_WAIT。
TCP要保证在所有可能的情况下使得所有的数据都能够被正确送达。当你关闭一个socket时，主动关闭一端的socket将进入TIME_WAIT状态，而被动关闭一方则转入CLOSED状态，这的确能够保证所有的数据都被传输。当一个socket关闭的时候，是通过两端四次握手完成的，当一端调用close()时，就说明本端没有数据要发送了。这好似看来在握手完成以后，socket就都可以处于初始的CLOSED状态了，其实不然。原因是这样安排状态有两个问题， 首先，我们没有任何机制保证最后的一个ACK能够正常传输，第二，网络上仍然有可能有残余的数据包(wandering duplicates)，我们也必须能够正常处理。
TIMEWAIT就是为了解决这两个问题而生的。
1.假设最后一个ACK丢失了，被动关闭一方会重发它的FIN。主动关闭一方必须维持一个有效状态信息（TIMEWAIT状态下维持），以便能够重发ACK。如果主动关闭的socket不维持这种状态而进入CLOSED状态，那么主动关闭的socket在处于CLOSED状态时，接收到FIN后将会响应一个RST。被动关闭一方接收到RST后会认为出错了。如果TCP协议想要正常完成必要的操作而终止双方的数据流传输，就必须完全正确的传输四次握手的四个节，不能有任何的丢失。这就是为什么socket在关闭后，仍然处于TIME_WAIT状态的第一个原因，因为他要等待以便重发ACK。
2.假设目前连接的通信双方都已经调用了close()，双方同时进入CLOSED的终结状态，而没有走TIME_WAIT状态。会出现如下问题，现在有一个新的连接被建立起来，使用的IP地址与端口与先前的完全相同，后建立的连接是原先连接的一个完全复用。还假定原先的连接中有数据报残存于网络之中，这样新的连接收到的数据报中有可能是先前连接的数据报。为了防止这一点，TCP不允许新连接复用TIME_WAIT状态下的socket。处于TIME_WAIT状态的socket在等待两倍的MSL时间以后（之所以是两倍的MSL，是由于MSL是一个数据报在网络中单向发出到认定丢失的时间，一个数据报有可能在发送途中或是其响应过程中成为残余数据报，确认一个数据报及其响应的丢弃的需要两倍的MSL），将会转变为CLOSED状态。这就意味着，一个成功建立的连接，必然使得先前网络中残余的数据报都丢失了。
大量TIMEWAIT在某些场景中导致的业务问题
主动正常关闭TCP连接，都会出现TIMEWAIT。为什么我们要关注这个高并发短连接呢？有两个方面需要注意：
1. 高并发可以让服务器在短时间范围内同时占用大量端口，而端口有个0~65535的范围，并不是很多，刨除系统和其他服务要用的，剩下的就更少了。
2. 在这个场景中，短连接表示“业务处理+传输数据的时间 远远小于 TIMEWAIT超时的时间”的连接。这里有个相对长短的概念，比如，取一个web页面，1秒钟的http短连接处理完业务，在关闭连接之后，这个业务用过的端口会停留在TIMEWAIT状态几分钟，而这几分钟，其他HTTP请求来临的时候是无法占用此端口的。单用这个业务计算服务器的利用率会发现，服务器干正经事的时间和端口（资源）被挂着无法被使用的时间的比例是 1：几百，服务器资源严重浪费。（说个题外话，从这个意义出发来考虑服务器性能调优的话，长连接业务的服务就不需要考虑TIMEWAIT状态。同时，假如你对服务器业务场景非常熟悉，你会发现，在实际业务场景中，一般长连接对应的业务的并发量并不会很高）
综合这两个方面，持续的到达一定量的高并发短连接，会使服务器因端口资源不足而拒绝为一部分客户服务。同时，这些端口都是服务器临时分配，无法用SO_REUSEADDR选项解决这个问题
我如何看待这个问题
为什么说上述两种解决方式我觉得可行，但是不符合原则？
我首先认为，我要依靠TIMEWAIT状态来保证我的服务器程序健壮，网络上发生的乱七八糟的问题太多了，我先要服务功能正常。
那是不是就不要性能了呢？并不是。如果服务器上跑的短连接业务量到了我真的必须处理这个TIMEWAIT状态过多的问题的时候，我的原则是尽量处理，而不是跟TIMEWAIT干上，非先除之而后快：）如果尽量处理了，还是解决不了问题，仍然拒绝服务部分请求，那我会采取分机器的方法，让多台机器来抗这些高并发的短请求。持续十万并发的短连接请求，两台机器，每台5万个，应该够用了吧。一般的业务量以及国内大部分网站其实并不需要关注这个问题，一句话，达不到需要关注这个问题的访问量。
真正地必须使用上述我认为不合理的方式来解决这个问题的场景有没有呢？答案是有。
像淘宝、百度、新浪、京东商城这样的站点，由于有很多静态小图片业务，如果过度分服会导致需要上线大量机器，多买机器多花钱，得多配机房，多配备运维工程师来守护这些机器，成本增长非常严重。。。这个时候就要尽一切可能去优化。题外话，服务器上的技术问题没有绝对，一切都是为业务需求服务的。
如何尽量处理TIMEWAIT过多
sysctl改两个内核参数就行了，如下：
net.ipv4.tcp_tw_reuse = 1
net.ipv4.tcp_tw_recycle = 1
简单来说，就是打开系统的TIMEWAIT重用和快速回收，至于怎么重用和快速回收，这个问题我没有深究，实际场景中这么做确实有效果。用netstat或者ss观察就能得出结论。
还有些朋友同时也会打开syncookies这个功能，如下：
net.ipv4.tcp_syncookies = 1
打开这个syncookies的目的实际上是：“在服务器资源（并非单指端口资源，拒绝服务有很多种资源不足的情况）不足的情况下，尽量不要拒绝TCP的syn（连接）请求，尽量把syn请求缓存起来，留着过会儿有能力的时候处理这些TCP的连接请求”。
如果并发量真的非常非常高，打开这个其实用处不大。
swap调优
目标:解决大量Log写入占用大量的File Cache,内容利用不充分导致swap
基本原则：尽量使用内存，减少swap，同时，尽早flush到外存，早点释放内存给写cache使用。---特别在持续的写入操作中，此优化非常有效。
调优措施：
vm.swappiness = 10
vm.dirty_ratio = 10
vm.dirty_background_ratio = 5
vm.dirty_expire_centisecs = 500
vm.vfs_cache_pressure = 500
vm.swappiness优化：
swappiness的值的大小对如何使用swap分区是有着很大的联系的。swappiness=0的时候表示最大限度使用物理内存，然后才是 swap空间，swappiness＝100的时候表示积极的使用swap分区，并且把内存上的数据及时的搬运到swap空间里面。linux的基本默认设置为60，具体如下：
cat /proc/sys/vm/swappiness
60
也就是说，你的内存在使用到100-60=40%的时候，就开始出现有交换分区的使用。大家知道，内存的速度会比磁盘快很多，这样子会加大系统io，同时造的成大量页的换进换出，严重影响系统的性能，所以我们在操作系统层面，要尽可能使用内存，对该参数进行调整。
临时调整的方法如下，我们调成10：
[root@node1 ~]# sysctl vm.swappiness=10
vm.swappiness = 10
[root@node1 ~]# cat /proc/sys/vm/swappiness
10
这只是临时调整的方法，重启后会回到默认设置的。要想永久调整的话，需要将在/etc/sysctl.conf修改，加上：
cat /etc/sysctl.conf
vm.swappiness=10
vm.dirty_ratio:
同步刷脏页，会阻塞应用程序
这个参数控制文件系统的同步写写缓冲区的大小，单位是百分比，表示当写缓冲使用到系统内存多少的时候（即指定了当文件系统缓存脏页数量达到系统内存百分之多少时（如10%），），开始向磁盘写出数据，即系统不得不开始处理缓存脏页（因为此时脏页数量已经比较多，为了避免数据丢失需要将一定脏页刷入外存），在此过程中很多应用进程可能会因为系统转而处理文件IO而阻塞。
增大之会使用更多系统内存用于磁盘写缓冲，也可以极大提高系统的写性能。但是，当你需要持续、恒定的写入场合时，应该降低其数值，一般启动上缺省是 10。
vm.dirty_background_ratio
异步刷脏页，不会阻塞应用程序
这个参数控制文件系统的后台进程，在何时刷新磁盘。单位是百分比，表示系统内存的百分比，意思是当写缓冲使用到系统内存多少的时候，就会触发pdflush/flush/kdmflush等后台回写进程运行，将一定缓存的脏页异步地刷入外存。增大之会使用更多系统内存用于磁盘写缓冲，也可以极大提高系统的写性能。但是，当你需要持续、恒定的写入场合时，应该降低其数值，一般启动上缺省是 5。
注意：如果dirty_ratio设置比dirty_background_ratio大，可能认为dirty_ratio的触发条件不可能达到，因为每次肯定会先达到vm.dirty_background_ratio的条件，然而，确实是先达到vm.dirty_background_ratio的条件然后触发flush进程进行异步的回写操作，但是这一过程中应用进程仍然可以进行写操作，如果多个应用进程写入的量大于flush进程刷出的量那自然会达到vm.dirty_ratio这个参数所设定的坎，此时操作系统会转入同步地处理脏页的过程，阻塞应用进程。
vm.dirty_expire_centisecs
这个参数声明Linux内核写缓冲区里面的数据多“旧”了之后，pdflush进程就开始考虑写到磁盘中去。单位是 1/100秒。缺省是 3000，也就是 30 秒的数据就算旧了，将会刷新磁盘。对于特别重载的写操作来说，这个值适当缩小也是好的，但也不能缩小太多，因为缩小太多也会导致IO提高太快。建议设置为 1500，也就是15秒算旧。当然，如果你的系统内存比较大，并且写入模式是间歇式的，并且每次写入的数据不大（比如几十M），那么这个值还是大些的好。
vm.dirty_writeback_centisecs
这个参数控制内核的脏数据刷新进程pdflush的运行间隔。单位是 1/100 秒。缺省数值是500，也就是 5 秒。如果你的系统是持续地写入动作，那么实际上还是降低这个数值比较好，这样可以把尖峰的写操作削平成多次写操作。设置方法如下：
echo "200" > /proc/sys/vm/dirty_writeback_centisecs
如果你的系统是短期地尖峰式的写操作，并且写入数据不大（几十M/次）且内存有比较多富裕，那么应该增大此数值：
vm.vfs_cache_pressure
增大这个参数设置了虚拟内存回收directory和inode缓冲的倾向，这个值越大。越易回收
该文件表示内核回收用于directory和inode cache内存的倾向；缺省值100表示内核将根据pagecache和swapcache，把directory和inode cache保持在一个合理的百分比；降低该值低于100，将导致内核倾向于保留directory和inode cache；增加该值超过100，将导致内核倾向于回收directory和inode cache。
发表评论