CentOS 系统内核优化

原创
2014/05/25 19:11
阅读数 288

ulimit 调优

ulimit -n #查看最大允许打开文件数
ulimit -u #查看最大允许进程数

/etc/security/limits.conf 格式如下

username|@groupname type resource limit

username|@groupname: 为限定的用户名或组名,组名前面需加“@”,可以使用 * 来做所有用户限定

type:

  • soft: 指的是当前系统生效的设置值

  • hard:表明系统中所能设定的最大值

  • -:表明同时设置了soft 和 hard 的值

    soft 的限制不能比 hard 限制高

resource:

  • core:限制内核文件的大小

  • data:最大数据大小

  • fsize:最大文件大小

  • memlock:最大锁定内存地址空间(建议值:soft-最大不超过内存1/2、hard-最大不超过内存2/3

  • nofile:每个进程打开文件的最大数目(建议值:soft-3072、hard-8192)

  • rss:最大持久设置大小(建议值:soft-最大不超过内存1/2、hard-最大不超过内存2/3

  • stack:最大栈大小(建议值:soft-最大不超过内存1/2、hard-最大不超过内存2/3

  • cpu:以分钟为单位的最多 CPU 时间

  • noproc:进程的最大数目(建议值:soft-3072、hard-8192)

  • as:地址空间限制(建议值:soft-最大不超过内存1/2、hard-最大不超过内存2/3

  • maklogins:此用户允许登录的最大数目

(参考资料:http://51linux.cn/article-14-1.html

网络参数优化

TIME_WAIT

    Linux 系统下,TCP 连接断开后,会以 TIME_WAIT 状态保留一定的时间,然后才会释放端口。当并发请求过多的时候,就会产生大量的 TIME_WAIT 状态的连接,无法及时断开的话,会占用大量的端口资源和服务器资源。这个时候我们可以优化 TCP 的内核参数,来及时将 TIME_WAIT 状态的端口清理掉。

    这里介绍的方法只对拥有大量 TIME_WAIT 状态的连接导致系统资源消耗有效,如果不是这种情况下,效果可能不明显。可以使用 netstat 命令去查 TIME_WAIT 状态的连接状态,输入下面的组合命令,查看当前 TCP 连接的状态和对应的连接数量:

netstat -n | awk '/^tcp/ {++S[$NF]} END {for(a in S) print a, S[a]}'

我们只用关心TIME_WAIT的个数,在这里可以看到,有 33 多个 TIME_WAIT(此台服务器为内部测试服务器,故此数量不会很大),这样就占用了 33 端口。端口的数量上限 65535 个,占用一个少一个,会严重的影响到后继的新连接。这种情况下,我们就有必要调整下 Linux 的 TCP 内核参数,让系统更快的释放 TIME_WAIT 连接。

在文件 /etc/sysctl.conf 中加入:

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    # 对于本端断开的 socket 连接,TCP 保持在 FIN-WAIT-2 状态的时间,对方可能会断开连接或一直不结束连接或不可预料的进程死亡,默认值为 60 秒,但要记住的是,即使你的机器是一个轻载的 WEB 服务器,也有因为大量的死套接字而内存溢出的风险,FIN-WAIT-2 的危险性比 FIN-WAIT-1 要小,因为它最多只能吃掉 1.5K 内存,但是它们的生存期长些
net.ipv4.conf.default.rp_filter = 1
net.ipv4.conf.default.accept_source_route = 0

#*** 在经过这样的调整之后,除了会进一步提升服务器的负载能力之外,还能够防御小流量程度的 DOS、CC 和 SYN 攻击 ***#

net.ipv4.tcp_keepalive_time = 1200 # 表示当 KeepAlive 起用的时候,TCP 发送 KeepAlive 消息的频度。缺省是2小时,改为20分钟
net.ipv4.tcp_keepalive_probes 3
net.ipv4.tcp_keepalive_intvl 30
# 意思是如果某个 TC P连接在 idle 20 后,内核才发起 probe,如果 probe 3 次(每次 30 秒)不成功,内核才彻底放弃,认为该连接已失效 #
net.ipv4.ip_local_port_range = 10000 65000 # 表示用于向外连接的端口范围。缺省情况下为:32768到61000,改为10000到65000(注意:这里不要将最低值设的太低,否则可能会占用掉正常的端口)

#*** 对于 Apache、Nginx 等服务器,上几行的参数可以很好地减少 TIME_WAIT 套接字数量,但是对于 Squid,效果却不大。此项参数可以控制 TIME_WAIT 的最大数量,避免 Squid 服务器被大量的 TIME_WAIT 拖死 ***#

net.ipv4.tcp_max_syn_backlog = 16384 # 对于那些依然还未获得客户端确认的连接请求﹐需要保存在队列中最大数目; 对于超过 128Mb 内存的系统, 默认值是 1024;低于 128Mb 的则为 128。如果服务器经常出现过载﹐可以尝试增加这个数字。警告﹗假如您将此值设为大于 1024﹐最好修改 include/net/tcp.h 里面的 TCP_SYNQ_HSIZE,以保持 TCP_SYNQ_HSIZE*16 (SYN Flood 攻击利用 TCP 协议散布握手的缺陷,伪造虚假源 IP 地址发送大量 TCP-SYN 半打开连接到目标系统,最终导致目标系统 Socket 队列资源耗尽而无法接受新的连接;为了应付这种攻击,现代 Unix 系统中普遍采用多连接队列处理的方式来缓冲(而不是解决)这种攻击,是用一个基本队列处理正常的完全连接应用(Connect() 和 Accept() ),是用另一个队列单独存放半打开连接;这种双队列处理方式和其他一些系统内核措施(例如 Syn-Cookies/Caches)联合应用时,能够比较有效的缓解小规模的 SYN Flood 攻击(事实证明)
net.ipv4.tcp_max_tw_buckets = 6000 # 表示系统同时保持 TIME_WAIT 的最大数量,如果超过这个数字,TIME_WAIT 将立刻被清除并打印警告信息。默认为 180000,改为 6000
net.core.netdev_max_backlog = 32768 # 每个网络接口接收数据包的速率比内核处理这些包的速率快时,允许送到队列的数据包的最大数目,对重负载服务器而言,该值需要调高一点
net.core.somaxconn = 32768 # web 应用中 listen 函数的 backlog 默认会给我们内核参数的 net.core.somaxconn 限制到 128,而 nginx 定义的 NGX_LISTEN_BACKLOG 默认为511,所以有必要调整这个值
net.core.wmem_default = 8388608
net.core.rmem_default = 8388608
net.core.rmem_max = 873200 # 最大 socket 读 buffer,可参考的优化值:873200
net.core.wmem_max = 873200 # 最大 socket 写 buffer,可参考的优化值:873200
net.core.optmem_max = 10240 # socket buffer的最大初始化值,默认10K(10240).也可调整到20k(20480).但建议保留不变
net.ipv4.tcp_timestamps = 1 # Timestamps 用在其它一些东西中﹐可以防范那些伪造的 sequence 号码,一条1G的宽带线路或许会重遇到带 out-of-line 数值的旧 sequence 号码(假如它是由于上次产生的)。Timestamp 会让它知道这是个 '旧封包'。(该文件表示是否启用以一种比超时重发更精确的方法(RFC 1323)来启用对 RTT 的计算;为了实现更好的性能应该启用这个选项。)
net.ipv4.tcp_synack_retries = 2 # 为了打开对端的连接,内核需要发送一个 SYN 并附带一个回应前面一个 SYN 的 ACK,也就是所谓三次握手中的第二次握手,这个设置决定了内核放弃连接之前发送 SYN+ACK 包的数量
net.ipv4.tcp_syn_retries = 2 # 在内核放弃建立连接之前发送SYN包的数量
net.ipv4.tcp_orphan_retries = 3 # 在近端丢弃TCP连接之前,要进行多少次重试;默认值是 7 个,相当于 50秒–16分钟,视 RTO 而定。如果您的系统是负载很大的 web服务器,那么也许需要降低该值,这类 sockets 可能会耗费大量的资源
net.ipv4.tcp_retries1 = 3 # 放弃回应一个TCP连接请求前,需要进行多少次重试;RFC 规定最低的数值是 3
net.ipv4.tcp_retries2 = 5 # 在丢弃激活(已建立通讯状况)的 TCP 连接之前﹐需要进行多少次重试。默认值为15,根据 RTO 的值来决定,相当于13-30分钟(RFC1122 规定,必须大于100秒)(这个值根据目前的网络设置,可以适当地改小)
net.ipv4.tcp_tw_len = 1
net.ipv4.tcp_tw_reuse = 1 # 开启重用,允许将 TIME-WAIT sockets 重新用于新的 TCP 连接
net.ipv4.tcp_wmem = min default max # min:为 TCP socket 预留用于发送缓冲的内存最小值,每个 TCP socket 都可以在建议以后都可以使用它,默认值为:4096(约4K);default:为 TCP socket 预留用于发送缓冲的内存数量,默认情况下该值会影响其它协议使用的 net.core.wmem_default 值,一般要低于net.core.wmem_default 的值,默认值为16384(约16K);max: 用于 TCP socket 发送缓冲的内存最大值,该值不会影响 net.core.wmem_max,"静态"选择参数 SO_SNDBUF 则不受该值影响,默认值为131072(约128K)
net.ipv4.tcp_rmem = min default max # min:为 TCP socket 预留用于读取缓冲的内存最小值,每个 TCP socket 都可以在建议以后都可以使用它,默认值为:4096(约4K);default:为 TCP socket 预留用于读取缓冲的内存数量,默认情况下该值会影响其它协议使用的 net.core.rmem_default 值,一般要低于net.core.rmem_default 的值,默认值为87380(约87K);max: 用于 TCP socket 发送读取的内存最大值,该值不会影响 net.core.rmem_max,"静态"选择参数 SO_SNDBUF 则不受该值影响,默认值为174760(约175K)
net.ipv4.tcp_mem = low pressure high # low:当 TCP 使用了低于该值的内存页面数时,TCP不会考虑释放内存,即低于此值没有内存压力(理想情况下,这个值应与指定给 tcp_wmem 的第 2 个值相匹配 - 这第 2 个值表明,最大页面大小乘以最大并发请求数除以页大小 (131072 * 300 / 4096));net.ipv4.tcp_mem[1]:在此值下,进入内存压力阶段;net.ipv4.tcp_mem[2]:高于此值,TCP 拒绝分配 socket,上述内存单位是页,而不是字节(1 Page = 4096 Bytes,建议值:不超过内存大小的一半)
net.ipv4.tcp_max_orphans = 3276800 # 系统中最多有多少个 TCP 套接字不被关联到任何一个用户文件句柄上,如果超过这个数字,连接将即刻被复位并打印出警告信息,这个限制仅仅是为了防止简单的 DoS 攻击,不能过分依靠它或者人为地减小这个值,更应该增加这个值(如果增加了内存之后)

# TCP 内存能容纳的连接数 ≈ net.ipv4.tcp_mem default/(net.ipv4.tcp_wmem default + net.ipv4.tcp_rmem default)

# 禁用 IPV6 #
net.ipv6.conf.all.disable_ipv6 = 1
net.ipv6.conf.default.disable_ipv6 = 1

重启配置

sysctl -p

如果出现以下错误:

则需先执行

modprobe bridge
lsmod|grep bridge

再执行

sysctl -p

(参考资料:http://www.centoscn.com/CentOS/Intermediate/2014/0318/2594.htmlhttp://blog.csdn.net/shaobingj126/article/details/8549494http://blog.39.net/zih/a_16200732.html

展开阅读全文
打赏
0
3 收藏
分享
加载中
更多评论
打赏
0 评论
3 收藏
0
分享
返回顶部
顶部