原文   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