首页 > 其他 > 详细

后台常见问题定位及应对指南

时间:2018-02-22 23:32:54      阅读:262      评论:0      收藏:0      [点我收藏+]

目录


说明

由于个人水平有限,总结归纳的时候可能存在错误,还望指出。

前言


后台故障是一个很宽泛的概念,本文有些标题党了,本文只是针对如下几点简单分析

  • 日志规范
  • tcp短连接使用过多
  • io频繁

程序逻辑错误或是发布变更引起的故障之类的不在讨论范围内。后台服务出现故障时大多数情况下都会伴随着cpu爆满,或者内存不足,或者网卡塞满,io频繁等情况,故障的定位少不了神兵利器,这里有一篇linux下常用工具的介绍:后台故障&性能分析常用工具

常规错误

这里把能通过日志定位到的错误视为常规错误。比如说某个调用失败会导致该次请求失败,我们可以通过写日志,将关键信息都记录下来,方便之后的问题定位。写日志其实也有一些要注意的点

  • 避免无效的信息,控制好日志的量和级别,日志写多了影响性能
  • 关键信息要记录全,如某个调用失败了,不能只打印一句 xxx Fail,而是要把对应的错误码,错误信息,该调用的关键参数打印出来,方便后续问题定位。

短连接之祸

tcp连接在关闭的时候,主动关闭的一方将会经历time_wait状态,一旦端口消耗速度持续大于端口回收速度,自然会造成端口不够用。但是话说回来,端口不够用这种情况只会出现在主动发起连接的那一端,因为listen -> accept 并不需要分配端口。

定位方法

使用 ss -s 命令,查看各状态的tcp连接数,如果time_wait状态过多且端口消耗速度持续增长,就得留点神了
另外对于服务端来说,有时我们会想要定位连接主要来自哪些ip,可以通过ss配合awk及uniq,sort等命令得到结论,如:

ss -n |grep ESTAB | awk ‘{ print $5 }‘ | awk -F: ‘{ print $1 }‘ | sort | uniq -c | sort -rn

可以得到每个ip的连接数的排序

应对方案

  • 1 放开port range,既然端口不够用,那么我们就加大端口数,使用如下命令可以得到当前系统向外建立连接时可用的端口范围

    cat /proc/sys/net/ipv4/ip_local_port_range

    通过如下指令可以设置端口范围,如

    echo "1024 61000" > /proc/sys/net/ipv4/ip_local_port_range

    但是调整port range后可能会出现某些服务无法重启,这是因为range调大之后,原先的服务监听的端口被系统分配出去了,这个时候可以把相关服务所绑定的端口设置到保留端口中,如

    echo "10000,20000" > /proc/sys/net/ipv4/ip_local_reserved_ports
  • 2 加快time_wait回收速度
    通过如下命令可以打开time_wait快速回收,recycle需要配合timestapms一起使用,不过timestamps是默认就打开的,开启后在3.5*RTO时间内回收

    echo "1" > /proc/sys/net/ipv4/tcp_tw_recycle
    若timestapms关闭了,则将其打开
    echo "1" > /proc/sys/net/ipv4/tcp_timestamps
  • 3 可以打开tcp_tw_resue选项,reuse也需要配合timestapms一起使用,开启后在1s内回收

    echo "1" > /proc/sys/net/ipv4/tcp_tw_reuse

    注意: 以上的修改都是临时的,一旦系统重启又将恢复为默认值,可以通过将这些参数添加到/etc/sysctl.conf文件中,并使用sysctl –p命令使之生效。相关阅读Linux之TCPIP内核参数优化TCP连接的状态与关闭方式,及其对Server与Client的影响,另外nat网络下,打开tw_recycle将可能导致tcp连接建立错误,详见链接tcp_tw_recycle和tcp_timestamps导致connect失败问题,不过同idc内的服务器之间不存在这个问题,但是还有一个问题,timewait的存在帮我们规避掉了旧连接对新连接的影响,关闭之后,是可能导致旧连接的数据包或fin包到达新连接,或者主动关闭方发送的ack丢包,导致对端仍旧处于last_ack状态,而主动关闭方快速回收了该socket,且新建连接时,该port被重用,发送syn过去时,将被回复rst,不过同idc内的网络环境应该是非常良好的,dog微笑脸。最后还可以通过设置SO_LINGER选项,在关闭socket时会非常粗暴的直接发送一个rst报文给对端,从而避免掉timewait状态。

  • 4 使用长连接+连接池,引入长连接也有一些点需要注意,主要是以下三点
  • 一是对底层服务的负载控制,短连接模式下可以很轻松的实现对底层服务的负载控制,长连接情况要麻烦一点
  • 二是底层服务扩容时,连接池需要感知并调整
  • 三是长连接+连接池技术 如果实现的不好的话本身也可能成为性能瓶颈,最好是能根据请求量动态的调整连接数,少了容易成为性能瓶颈,多了浪费端口,不过一般情况下端口肯定是够用的。

IO之祸

这个没什么好说的,io多了必然给磁盘带来压力,由此带来的io等待时间必然上涨,对于我们的后台服务而言,io过多基本是由于写日志导致。

定位方法

使用vmstat 命令查看当前系统io情况,以及cpu的wa(cpu空转等待io就绪)所占时间比例。如

vmstat 2

重点观察bi,bo以及wa项。分别代表块读入速度和块写入速度以及io等待时间比例。

应对方法

通过/dev/null文件快速关闭日志,如

ln -s /dev/null xxx.log

关于/dev/null和/dev/zero文件的介绍可以查看链接,/dev/null 和 /dev/zero 简介及对比,关闭日志只是紧急处理方法,后续还是要优化好写日志的逻辑,控制好量和级别。

总结


后台服务出现性能故障时,可以遵循以下思路去定位(以下内容参考自客厅后台开发群熊哥的聊天内容)

  • 1 先看vmstat,看io是否高,如是,可关闭日志,快速方法:ln -s /dev/null xxx.log
  • 2 io不高,再看cpu消耗在用户态还是内核态,如果是用户态,通常是触发了程序bug,可用ltrace定位,快速方法:重启服务
  • 3 如果内核态cpu高,对tcp类网络服务,80%原因就是端口耗尽,通过ss -s看端口和time_wait等各个状态,快速方法:加大port range,打开tw_recycle和tw_reuse

感谢运维们。

后台常见问题定位及应对指南

原文:https://www.cnblogs.com/unnamedfish/p/8460422.html

(0)
(0)
   
举报
评论 一句话评论(0
关于我们 - 联系我们 - 留言反馈 - 联系我们:wmxa8@hotmail.com
© 2014 bubuko.com 版权所有
打开技术之扣,分享程序人生!