单服100w长连接报告笔记
建议直接看参考的原版报告，这篇为我大致记录的一些配置，部分还为理解，后续进行修改补充。
C1000K
从 C1000K 说起 ，C1000K 是什么意思?为了搞清楚这个问题，必须先提 起”The C10K problem” ()， 顾名思义 10K 就是 1 万，这篇文章可以说是高性能服务器开发的一个标志性文档，它讨论的就是 单机为1万个连接提供服务这个问题，当时因为硬件和软件的限制，单机1万还是一个非常值得挑战的目标。 但是时光荏苒，随着硬件和软件的飞速发展，单机 1 万 的目标已经变成了最简单不过的事情。 现在用任何一种主流语言都能提供单机 1 万 的并发处理的能力。所以现在目标早已提高了100倍，变成 C1000k，也就是一台服务器为100万连接提供服务 。 国外公司 whatapps 的曾经分享过相关内容，他们在2011年9月宣称完成了单机100万用户支持(他们最后做到了 C2000k，而且是实打实的在线用户)。所以 C10M，C100M 才是今后继续努力的方向，
系统准备
硬件
服务器
首先查看服务器的信息
dmidecode | grep "Product Name"
CPU
然后检查 CPU 的规格
cat /proc/cpuinfo | grep name | awk -F: '{print $(NF)}' | uniq -c 内存
检查内存大小
cat /proc/meminfo
网卡
查看网卡， 网卡一般为 eth0 等。
dmesg | grep -i eth
软件
操作系统
lsb_release -a
内核版本
uname -a
系统优化
系统优化是非常关键的一步，因为默认的系统设置并不是以高并发高负载 的服务器做为目标的，所有配置需要进行修改，这样可以尽可能的使用操作系统和 硬件的能力。
- 根据高并发高负载的业务要求，对 Linux 的系统设置进行优化，如最大 文件数目，TCP/IP 的设置参数等等。这个层级的优化经验，基本适用于大多数的 服务器设置。
- 根据硬件的特性，对硬件的设置进行优化。这个级别的要求更高，也更 有正针对性。
Linux 系统设置
提高文件数目上限
在 Linux 中 socket 被表示为一个文件描述符，默认的文件数目上限是 1024，当然这是远远不够的。 你需要做的是自然是提高文件打开上限。
ulimit -a
可以看到现有的 open files 的数值为 1024. 这意味着这 台服务器只能同时为 1024 个用户提供服务。当然这是远远不够。
有 2 个方法,
- 修改linux
1. 修改 /etc/security/limits.confhard nofile 1025500soft nofile 10255002. 修改/etc/sysctl.conffs.file-max=10255003. 运行 sysctl –p 使修改生效4. 重新登录并确认修改生效
- TCP/IP 的优化
TCP/IP 的优化选项非常的多.
- 修改 net.core.somaxconn 以及 net.core.tcp_max_syn_backlog
要解释这个问题，需要对网络服务的 Accpet 有深入的了解，这里我借 助陶辉老师关于高性能服务器系列博客里的一张图来解释这个选项。 []
如果有高并发的请求来进行连接，而我们的队 列过小，客户端就直接连接失败。如果我们把队列扩大，那么我们的服务器 就有机会把暂时处理不了的请求，暂存起来，慢慢处理。
使用 ss –n –l 命令，检查 Send-Q 那一列，你就知道是否已经生效了。
- tcp_syncookies
开启 tcp_syncookie 可以防止 syn floor 攻击,同时在 syn_backlog 已满的情况下,不会抛弃 syn 包。推荐打开
- tcp_max_tw_buckets
修改系统中处于 timewait 状态的连接的数目。关于 timewait 状态, Steven 老师说过他是我们的朋友。但有时候我们需要关闭它。主要为了防> 止对系统资源的占有。我把它设置为 10000
- tcp_tw_recycle
用于快速回收处于 timewait 的连接。但是它和 timestamp 一起作用时可能会导致同一个 NAT 过来的连接失败。关闭它。
- timestamps
为了避免它和 tcp_tw_recycle 一起导致问题, 我推荐关闭它。
- tcp_tw_reuse
允许将 TIME-WAIT sockets 重新用于新的 TCP 连接,使用下来效果不是 很好。但是还是建议开启。
- tcp_fin_timeout
如果本方关闭连接，则它在 FIN_WAIT_2 状态的时间。建议改为 10。
- tcp_synack_retries
对于远端的连接请求 SYN,服务器对应的 ack 响应的数目。我把它设置为10。
- tcp_keepalive_time tcp_keepalive_intvl tcp_keepalive_probes
这主要是为了解决 TCP 的 CLOSE_WAIT 问题,有人说它是 TCP 的癌症。 一般来说 TCP 处于 CLOSE_WAIT 的状态,说明你的连接处于半连接状态,你已 经无法收到对方的信息了， 绝大多数的情况下,你需要离开关闭连接。如果 你的代码出现问题,忘记关闭了这个连接(TCP 是双工的),那么资源就一直被 泄漏着。 还有一种情况则是,对方故意不收取你的数据,导致你最后的 fin 包无法发送给对方。(如果希望重现这个攻击的过程,你可以写一个简单的客户端,连接上一台 Nginx 获取一个比较大的文件。 在发送完请求以后，并不 读取数据, 那么服务端的这个连接,将在 tcp_keepalive_time 时间内无法 被关闭。)修改这 3 个参数可以减少被攻击的几率。
- tcp_keepalive_time : 防止空连接攻击,可以缩小该值, 建议改为 180
- tcp_keepalive_intvl : 当探测没有确认时，重新发送探测的频度。缺省是 75 秒。建议改为 30 秒
- tcp_keepalive_probes 进行多少次探测,因为探测的间隔是按照指数级别增长,默认为 9 次。建议改为 5 次。
客户端相关
- 提高cwnd
提高拥塞窗口大小。 拥塞窗口主要是为了解决网络拥塞的问题，但是 默认的拥塞窗口会导致网络传输数据的启动速度比较低。
按照 google 的推荐,我建议将其改为 10. 修改方法如下(火丁笔记 )
shell> ip route | while read p; do ip route change $p initcwnd 10 done
- ip_local_port_range
可用端口范围。很简单改到 1024 到 65535
硬件优化
确定网卡的 IRQ
cat /proc/interrupts
网卡 eth0 的 IRQ 为 49
从硬件信息可知我的 CPU 为 4 核，那么我们可以把主设备的中断处理分配到 4个核上。
echo 0-3 > /proc/irq/49/smp_affinity_listcat smp_affinity_listcat /proc/irq/49/smp_affinity
还需要启动 RPS 。(注意 RPS 对 linux 内核版本有要求，需要高于 2.6.32, 而我们的内核是 3.x,所以肯定会支持 这个特性)
如何确定我的网卡是一块单队列的网卡呢?
首先 lspci –vvv 找到网卡相应的信息，按照 [] 的说法 “Ethernet controller 的条目内容， 如果有 MSI-X && Enable+ && TabSize > 1， 则该网卡是多队列网卡 ”，这条信息显示了是否是多队列，很不幸这是块单队列的网卡。
还有个办法 去/sys 里面再次确认一下
ls /sys/class/net/eth0/queues/结果：rx-0 tx-0
发现的确只有一个 RX 一个 TX。这说明这是一个单队列的网卡
目前系统的优化，就告一个段落。 sysctl.conf 文件的一些修改。
sysctl -p