1、输出一些观察信息（printTDinfo()）
每个10秒中显示一次关键、重要的信息。
当前在线人数，空闲链接列表大小，将来释放的连接大小，当前时间队列。
收消息队列和发消息队列大小。
2、一楼安全问题思考
2.1、收到太多数据包处理不过来
一、降速：暂时关闭读事件在epoll对象中。客户端的请求会积压在客户端的发送缓冲区和服务器的接收缓冲区。等到服务端数据处理的差不多了再接收。
二、增加线程。
2.2、积压太多数据包发送不出去
一、壮士断腕，清楚发送缓冲区的队列。
二、针对某个连接的发送数量过高，关闭该连接。
2.3、连入安全的进一步完善
延迟释放导致如果介入的客户端过快过多，会导致延迟回收队列急速扩张。
应对办法：不接收新的连接进来，只到延迟队列到时缩小。（这样好吗？）
3、压力测试前的准备工作
3.1、配置文件内容和配置项确认
3.2、整理业务逻辑函数
4、压力测试
服务器压力测试需要连续跑很多天，才能暴露缺陷。因为小小的内存泄露，多日累计就会变得庞大。
创建2048个socket，连接到服务端。
客户端和服务器分开不同的电脑测试，在linux服务器上运行服务器程序。
测试程序崩溃；程序异常（内存不断增加，收发连接异常）；
top -p xxxx 查看服务器的cpu和内存的动态变化。
cat /proc/3645/status 查看进程占用的实际内存 VMRSS
当前缺陷：要释放的连接越来越多。
4.1、最大连接数只在1000多个
设置最大了2048，但只再现1018。频繁报accept失败。
用户进程可打开的文件数有关，系统为每个TCP连接创建一个文件句柄。每个进程可打开的文件数大小：ulimit -n 可以开到只是1024。而且还有监听句柄，日志文件，配置文件，标准输入、输出、错误等。。。所以最后只有1018能打开。
如何摆脱限制？
必须修改linux对当前用户进程可打开的文件数限制。
#修改文件 /etc/sysctl.conf ，在末尾追加这些文字
fs.file-max = 2097152
fs.nr_open = 2097152
net.core.somaxconn = 65535
net.core.rmem_default = 65535
net.core.wmem_default = 65535
net.core.rmem_max = 8388608
net.core.wmem_max = 83886080
net.core.optmem_max = 40960
net.ipv4.tcp_rmem = 4096 87380 83886080
net.ipv4.tcp_wmem = 4096 65535 83886080
net.ipv4.tcp_mem = 8388608 8388608 83886080
修改完，输入终端命令，使能生效 sysctl -p
4.2、学习忠告
自己学会解决问题。
网友评论