做网站需要啥,安装nginx wordpress,手机电商平台怎么做的,手机qq查看网站源码一、 故障现象部分机顶盒用户出现大面积登录APP时#xff0c;界面停留在登陆页面#xff0c;无反应。二、现象初步分析本次问题出现时#xff0c;所有AAA出现了异常流量波动#xff0c;在AAA异常流量段期间接到用户故障报障。此时主要表现在LVS集群显示真实的EPG 服务器不停…一、 故障现象部分机顶盒用户出现大面积登录APP时界面停留在登陆页面无反应。二、现象初步分析本次问题出现时所有AAA出现了异常流量波动在AAA异常流量段期间接到用户故障报障。此时主要表现在LVS集群显示真实的EPG 服务器不停的被踢出集群和加入(UP/DOWN)导致了用户调度到EPG后出现了异常显示。AAA异常流量图三、问题排查过程接到故障后第一时间对AAA/EPG后台日志进行了查看发现用户接入认证和响应都正常观察到EPG 的LVS集群中有服务器的inactive连接数异常并且随机出现不同EPG服务器被踢出和加入集群随后对EPG 的LVS集群的状态进行了跟踪和抓包分析,为了快速恢复业务随后重启了EPG tomcat并进行了LVS的主备切换业务故障恢复。四、诊断分析结果出现故障时通过LVS的日志可以看到5台EPG服务器在轮询的出现连接失败和连接成功的情况也就是一台OK后另一台出现连接失败如此反复的表现在5台EPG服务器上此时被UP/DOWN的EPG会出现大量的inactive此时对集群出现UP/DOWM的服务器进行抓包发现客户端发出了SYN报文但是EPG服务器没有响应并且响应报文发不出去不停的retransmission。进一步查看该EPG的资源消耗情况netstat发现大量的SYN-RECV通过上面的现象判断是EPG的socket资源被耗尽进而出现了响应客户端异常导致了LVS检测EPG服务器异常因集群是5台EPG服务器一台异常后LVS集群把用户调度到其它EPG服务器此时异常用户也对该服务器产生了影响出现了该服务器也被资源耗尽依次循环。根据当前的用户量程度来看一般EPG的资源应该是可以满足进一步查看资源情况发现是EPG的句柄数被耗尽导致的当重启EPG后资源被释放句柄数被释放问题故障就恢复了。查看EPG服务器发现系统的默认句柄数为1024。LVS原理分析当有异常用户访问EPG时SYN消息先发送到LVSLVS会建立一个调度表显示用户与EPG的TCP对应关系EPG会直接返回ACK给用户端不经过LVS只有LVS收到用户端发送的FIN时表项的对应关系才会删除该用户客户端的EPG对应关系。当用户访问突然异常且量大的时候EPG默认的句柄数只有1024这样会导致LVS踢出该EPG但是此时LVS建立的表里面的TCP关系还在所以inactive数会变的特别大根据LVS调度策略用户会被调度到其它EPG真实服务器这样就会形成恶性循环所有集群的EPG真实服务器会被资源耗尽。五、处理优化措施从上述分析来看本次故障根本原因是EPG真实服务器的句柄数采用默认的1024一旦出现异常用户访问的时候就会变的脆弱目前修改为了204800。经过本次故障对系统的参数做了确认和文档化六、参数修改记录修改记录一net.ipv4.tcp_timestamps 0原因如下1、slb服务器为了优化性能调整以下内核参数net.ipv4.tcp_timestamps 1net.ipv4.tcp_tw_recycle 1当这两个参数都打开时tcp需要校验syn包的时间戳(timestamp)对集团用户有影响使其接入失败。2、当满足以下条件syn包将会被忽略不会回复ack包a、该源ip的上次tcp通讯发生在60s内。b、该源ip的上次tcp通讯的timestamp 大于本次tcp。注tcp通讯的timestamp 为系统启动到当前的时间。3、解释现象a、为什么普通的用户播放正常集团用户不行一个ip对应一个普通用户那么普通用户的tcp通讯的timestamp是一直增大的即不会满足2中的b条件。集团用户是做了NAT的一个ip对应多个客户端只有tcp通讯的timestamp比较大的客户端(大堂)才能请求成功timestamp比较小的(房间)请求就失败。b、房间偶尔又能播放该源ip的上次tcp通讯发生在60s之外了。修改记录二net.ipv4.tcp_max_tw_buckets 5000TIME_WAIT状态的连接过多会影响到大并发。修改记录三net.ipv4.tcp_synack_retries 0net.core.somaxconn 65535writen:aarontime:20170106原因如下SYN Flood(TCP洪水攻击优化)tcp_synack_retries表示回应第二个握手包(SYNACK包)给客户端IP后如果收不到第三次握手包(ACK包)后不进行重试加快回收“半连接”不要耗光资源。可以把tcp_synack_retries改为0因为客户端还有tcp_syn_retries参数默认是5即使服务器端没有重发SYNACK包客户端也会重发SYN握手包。net.core.somaxconn最大的监听队列的长度默认限制为128在高突发的请求中可能会导致链接超时或触发重传。修改记录四括号值为修改后的值(X)代表删除。net.ipv4.tcp_fin_timeout 5 (1)net.ipv4.tcp_max_syn_backlog 10240(262144)net.ipv4.tcp_max_tw_buckets 5000(6000)net.ipv4.tcp_mem 24794688 33059584 49589376 (X)net.ipv4.tcp_retries1 3 (2)net.ipv4.tcp_retries2 15(2)net.ipv4.tcp_keepalive_intvl 75(2)net.ipv4.tcp_keepalive_probes 9(3)net.ipv4.tcp_keepalive_time 7200(2)net.ipv4.tcp_rmem 4096 87380 4194304(X)net.ipv4.tcp_syn_retries 2net.ipv4.tcp_timestamps 0(1)// timestamps可单独起效net.ipv4.tcp_tw_recycle 1(0)// 需要timestamps起效此项才奇效单独开启无意义net.ipv4.tcp_wmem 4096 16384 4194304(X)net.ipv4.udp_mem 24794688 33059584 49589376(X)net.ipv4.udp_rmem_min 4096(X)net.ipv4.udp_wmem_min 4096(X)net.core.rps_sock_flow_entries 65535// nf_conntrack 避免iptables的conntrack模块故障net.netfilter.nf_conntrack_acct 0net.netfilter.nf_conntrack_checksum 1net.netfilter.nf_conntrack_events 1net.netfilter.nf_conntrack_events_retry_timeout 5net.netfilter.nf_conntrack_expect_max 256net.netfilter.nf_conntrack_generic_timeout 6net.netfilter.nf_conntrack_helper 1net.netfilter.nf_conntrack_icmp_timeout 3net.netfilter.nf_conntrack_log_invalid 0net.netfilter.nf_conntrack_max 524288net.netfilter.nf_conntrack_tcp_be_liberal 0net.netfilter.nf_conntrack_tcp_loose 1net.netfilter.nf_conntrack_tcp_max_retrans 2net.netfilter.nf_conntrack_tcp_timeout_close 5net.netfilter.nf_conntrack_tcp_timeout_close_wait 6net.netfilter.nf_conntrack_tcp_timeout_established 5net.netfilter.nf_conntrack_tcp_timeout_fin_wait 3net.netfilter.nf_conntrack_tcp_timeout_last_ack 3net.netfilter.nf_conntrack_tcp_timeout_max_retrans 3net.netfilter.nf_conntrack_tcp_timeout_syn_recv 3net.netfilter.nf_conntrack_tcp_timeout_syn_sent 3net.netfilter.nf_conntrack_tcp_timeout_time_wait 2net.netfilter.nf_conntrack_tcp_timeout_unacknowledged 3net.netfilter.nf_conntrack_timestamp 0net.netfilter.nf_conntrack_udp_timeout 3net.netfilter.nf_conntrack_udp_timeout_stream 3net.nf_conntrack_max 524288修改记录五net.ipv4.tcp_max_tw_buckets 6000 (262144)原因tcp_max_tw_buckets的默认值为262144修改记录六增加修改文件句柄数在/root/.bash_profile增加ulimit -n 204800标签版权申明本站文章部分自网络如有侵权请联系west999comoutlook.com特别注意本站所有转载文章言论不代表本站观点本站所提供的摄影照片插画设计作品如需使用请与原作者联系版权归原作者所有
