原文 http://blog.csdn.net/woshiaotian/article/details/78133195
起因:
购买了阿里云的redis节点，但是默认阿里云不提供公网IP，所以我在一台阿里云的机器启动了rinetd，做端口的转发服务，开始一切正常，一段时间以后，随着并发力度加大。我们发现redis连不上了，提示Connection reset by peer
排查
1. 排查Redis
为什么会这样，首先我怀疑，是否redis有问题
首先我查看了redis的负载情况，使用INFO 命令
# Clientsconnected_clients:192client_longest_output_list:0client_biggest_input_buf:0blocked_clients:16# Statstotal_connections_received:1131total_commands_processed:7225865instantaneous_ops_per_sec:30total_net_input_bytes:216949807total_net_output_bytes:87315792
显然redis的负载并不高
instantaneous_ops_per_sec 要超过2w， 负载才算高
connected_clients还不到200， 默认的设置允许最大连接数是1w
2. 排查阿里云主机
首先这台的机器的连接数并不高
[root@xxx-xx-77 ~]# ss -sTotal: 733 (kernel 751)TCP: 644 (estab 598, closed 1, orphaned 0, synrecv 0, timewait 1/0), ports 234Transport Total IP IPv6* 751 - -RAW 0 0 0UDP 1 1 0TCP 643 636 7INET 644 637 7FRAG 0 0 0
但是观察机器的CPU使用率
top - 13:34:57 up 72 days, 21:21, 2 users, load average: 1.03, 1.32, 1.08Tasks: 264 total, 2 running, 262 sleeping, 0 stopped, 0 zombieCpu(s): 3.6%us, 9.9%sy, 0.0%ni, 85.8%id, 0.0%wa, 0.0%hi, 0.8%si, 0.0%stMem: 15641200k total, 15093856k used, 547344k free, 246612k buffersSwap: 4194300k total, 0k used, 4194300k free, 3384744k cached PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND19532 root 20 0 9284 1828 612 R 100.0 0.0 16:18.16 rinetd 6456 root 20 0 96076 10m 1292 S 11.6 0.1 35:13.00 redis-server13636 rabbitmq 20 0 6029m 255m 3940 S 0.7 1.7 1912:26 beam.smp16505 root 20 0 935m 79m 9.9m S 0.3 0.5 184:33.40 docker20069 root 20 0 17208 1380 952 S 0.3 0.0 0:15.24 top20312 root 20 0 17208 1384 952 R 0.3 0.0 0:00.01 top 1 root 20 0 21408 1636 1312 S 0.0 0.0 0:54.05 init
很明显是rinetd 所占CPU过高，这是一个异常点
[root@bbd-iner-2-77 ~]# ps -mp 19532 -o THREAD,tidUSER %CPU PRI SCNT WCHAN USER SYSTEM TID root 36.6 - - - - - - root 36.6 19 - - - - 19532
使用strace 追一下系统调用
strace -p 19532
sendto(1024, "*3\r\n$3\r\nSET\r\n$5\r\n11111\r\n$2\r\n15\r\n", 32, 0, NULL, 0) = 32 select(1025, [4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 ... ... 993 997 999 1003 1007 1009 1013 1017]) recvfrom(408, "+OK\r\n", 1024, 0, NULL, NULL) = 5 recvfrom(409, "*3\r\n$3\r\nSET\r\n$5\r\n11111\r\n$2\r\n15\r\n", 1024, 0, NULL, NULL) = 32recvfrom(411, "*3\r\n$3\r\nSET\r\n$5\r\n11111\r\n$2\r\n15\r\n", 1024, 0, NULL, NULL) = 32 sendto(413, "$2\r\n15\r\n", 8, 0, NULL, 0) = 8recvfrom(415, "*2\r\n$3\r\nGET\r\n$5\r\n11111\r\n", 1024, 0, NULL, NULL) = 24recvfrom(423, "*2\r\n$3\r\nGET\r\n$5\r\n11111\r\n", 1024, 0, NULL, NULL) = 24recvfrom(425, "*2\r\n$3\r\nGET\r\n$5\r\n11111\r\n", 1024, 0, NULL, NULL) = 24recvfrom(440, "+OK\r\n", 1024, 0, NULL, NULL) = 5
rinetd 没有使用epoll，而是用了select
众所周知, select是基于类似的轮训的机制，反复去查询fd的情况，并且会在内核空间和用户空间拷贝fd集合
在IO比较高的情况下，select相比epoll有更高的CPU消耗，并且select默认最大支持1024个fd
所以rinetd才把CPU打的比较高，导致转发服务异常
解决
直接使用nginx的tcp proxy模块，问题解决，并且CPU使用率也不高
参考资料：
1. select、poll、epoll之间的区别总结[整理]
2. NGINX Load Balancing – TCP and UDP Load Balancer