Linux终端设置缓存大小,Linux调优方案，sysctl.conf的设置

最新推荐文章于 2024-07-31 13:59:16 发布

贾小乖乖乖

最新推荐文章于 2024-07-31 13:59:16 发布

阅读量2.9k

点赞数

文章标签： Linux终端设置缓存大小

本文详述了Linux服务器性能优化的关键参数，包括socket缓冲区大小、网络连接队列、TIME_WAIT套接字管理等。通过对`/proc/sys`下的相关配置进行调整，例如增大socket缓冲区、调整netdev_max_backlog和somaxconn等，可提升服务器处理高并发请求的能力，减少连接超时问题。同时，讲解了如何通过设置tcp_syncookies和tcp_tw_reuse等参数来防御SYN Flood攻击和优化TIME_WAIT状态的处理。建议根据服务器实际负载情况调整参数，以实现最佳性能。

摘要由CSDN通过智能技术生成

$ /proc/sys/net/core/wmem_max

最大socket写buffer,可参考的优化值:873200

$ /proc/sys/net/core/rmem_max

最大socket读buffer,可参考的优化值:873200

$ /proc/sys/net/ipv4/tcp_wmem

TCP写buffer,可参考的优化值:32768 436600 873200

$ /proc/sys/net/ipv4/tcp_rmem

TCP读buffer,可参考的优化值:32768 436600 873200

$ /proc/sys/net/ipv4/tcp_mem同样有3个值,意思是:

net.ipv4.tcp_mem[0]:低于此值,TCP没有内存压力.

net.ipv4.tcp_mem[1]:在此值下,进入内存压力阶段.

net.ipv4.tcp_mem[2]:高于此值,TCP拒绝分配socket.

上述内存单位是页,而不是字节.可参考的优化值是:786432 1048576 1572864

$ /proc/sys/net/core/netdev_max_backlog进入包的最大设备队列.默认是1000,对重负载服务器而言,该值太低,可调整到16384.

$ /proc/sys/net/core/somaxconnlisten()的默认参数,挂起请求的最大数量.默认是128.对繁忙的服务器,增加该值有助于网络性能.可调整到8192.

$ /proc/sys/net/core/optmem_maxsocket buffer的最大初始化值,默认10K(10240).也可调整到20k(20480).但建议保留不变

$ /proc/sys/net/ipv4/tcp_max_syn_backlog进入SYN包的最大请求队列.默认1024.对重负载服务器,增加该值显然有好处.可调整到16384.

$ /proc/sys/net/ipv4/tcp_retries2

TCP失败重传次数,默认值15,意味着重传15次才彻底放弃.可减少到5,以尽早释放内核资源.

$ /proc/sys/net/ipv4/tcp_keepalive_time

$ /proc/sys/net/ipv4/tcp_keepalive_intvl

$ /proc/sys/net/ipv4/tcp_keepalive_probes这3个参数与TCP KeepAlive有关.默认值是:

tcp_keepalive_time = 7200 seconds (2 hours)

tcp_keepalive_probes = 9

tcp_keepalive_intvl = 75 seconds

意思是如果某个TCP连接在idle 2个小时后,内核才发起probe.如果probe 9次(每次75秒)不成功,内核才彻底放弃,认为该连接已失效.对服务器而言,显然上述值太大. 可调整到:

/proc/sys/net/ipv4/tcp_keepalive_time 1800

/proc/sys/net/ipv4/tcp_keepalive_probes 3

/proc/sys/net/ipv4/tcp_keepalive_intvl 30

$ proc/sys/net/ipv4/ip_local_port_range指定端口范围的一个配置,默认是32768 61000.可调整为1024 65535.

----------

net.ipv4.tcp_syncookies = 1

表示开启SYN Cookies。当出现SYN等待队列溢出时，启用cookies来处理，可防范少量SYN***，默认为0，表示关闭。

net.ipv4.tcp_tw_reuse = 1

表示开启重用。允许将TIME-WAIT sockets重新用于新的TCP连接，默认为0，表示关闭。

net.ipv4.tcp_tw_recycle = 1

表示开启TCP连接中TIME-WAIT sockets的快速回收，默认为0，表示关闭。

net.ipv4.tcp_fin_timeout = 30表示如果套接字由本端要求关闭，这个参数决定了它保持在FIN-WAIT-2状态的时间。

net.ipv4.tcp_keepalive_time = 1200表示当keepalive起用的时候，TCP发送keepalive消息的频度。缺省是2小时，改为20分钟。

net.ipv4.ip_local_port_range = 1024 65535表示用于向外连接的端口范围。缺省情况下过窄：32768到61000，改为1024到65535。

net.ipv4.tcp_max_syn_backlog = 16384

表示SYN队列的长度，默认为1024，加大队列长度为8192，可以容纳更多等待连接的网络连接数。

net.ipv4.tcp_max_tw_buckets = 180000表示系统同时保持TIME_WAIT套接字的最大数量，如果超过这个数字，TIME_WAIT套接字将立刻被清除并打印警告信息。默认为180000,可适当增大该值，但不建议减小。对于Apache、Nginx等服务器，以上几行参数的设置可以很好地减少TIME_WAIT套接字数量，但是对于Squid，效果却不大。此项参数可以控制TIME_WAIT套接字的最大数量，避免Squid服务器被大量的TIME_WAIT套接字拖死。

**************************************************************************************************************

转载自：http://bbs.chinaunix.net/thread-2318039-1-1.html

问题表现就是epoll这个服务端对10000的并发请求处理特别慢，甚至还出现很多客户连接超时的情况！但是顺序的一个个请求却没有问题。

测试如下：

首先是1个进程，顺序10000个请求。服务端没问题，很快速完成。

然后是10000个进程，每个进程1个请求，开始都还正常，可是过一会服务端accept就阻塞了，大概有1-2s，之后又返回，有时候还会出现客户端连接超时的问题，但是这样测30章那个线程池(300个线程)的服务端代码，不管怎么测都不会有问题。

按理说accept应该能一直返回才对呀，为什么中途会阻塞呢？是内核参数问题？

之前也试过把listenfd也添加到epoll里，listenfd不是ET模式。也有这样的问题。

分析了很多可能：

? epoll本身处理效率的问题(这个自己都不信)

? 服务端完成客户的处理请求太耗时，导致没有时间让accept返回其他客户连接(这是个最简单的处理，应该也不会)

? 单台机器测试，所以产生了太多的TIME_WAIT导致客户无法连接导致超时(之前以为是这个原因)