精华内容
下载资源
问答
  • 部署到线上是jar包方式 开始我以为线上是用的外部tomcat所以把 ServerEndpointExporter类注释掉了 开启后。如下图 线上服务器nginx配置如下: 然后OK:

    部署到线上是jar包方式
    开始我以为线上是用的外部tomcat所以把

    ServerEndpointExporter类注释掉了
    

    开启后。如下图

    线上服务器nginx配置如下:

    然后OK:
     

    展开全文
  • 某天中午的时候,企业微信一监控群突然收到 14 条消息的告警,显示提现接口请求超时,因为这个接口设置的超时时间是 30s,说明这8 条请求超过 30s 了。 正常这个接口,统计了以往的响应耗时,其实最长也就 2s 内返

    1、背景引入

    这个接口是用户提现的接口,大概每天 12:30 14:30 大概有几百人同时发起提现请求,然后这些人属于同一公司。

    然后我们服务进行一系列的校验,比如账户余额、请求参数啥的,人、公司都加了分布式锁,然后校验通过后就是生成任务,再去调用支付中心去扣款。

    2、问题介绍

    某天中午的时候,企业微信一监控群突然收到 14 条消息的告警,显示提现接口请求超时,因为这个接口设置的超时时间是 30s,说明这8 条请求超过 30s 了。

    正常这个接口,统计了以往的响应耗时,其实最长也就 2s 内返回了,基本上都是 1s 内返回了。因为这个是老系统,这个超时设置暂不去研究是否合适。

    3、问题排查

    3.1 排查所有可能出现问题的地方

    1、然后就去查看了线上日志,看 skywalking,发现当天有 324 条提现请求,大概有 14 条接口请求超时,还有一些的数据请求耗时在 10s、20s 以上,所以这些肯定是不正常的
    2、看了机器的 cpu、内存、网络负载都很正常,没有明显有波动。
    3、然后又看了 db 的慢查统计,也没有慢查。
    4、 jstack、gc 都看了没有问题

    所有的都看了,就是没有发现任何可能存在的问题.因为这个过程很长,里面打印了很多日志,分阶段统计了每个阶段的耗时,每个阶段也没有明显的问题。
    然后就这样持续了 2 天。还是一样的问题,还是同样超时。每天都会有大概 10 条左右的超时

    3.2 发现不一样的日志

    直到第 3 天的时候发现了一个连接获取不到的异常。如下:

    Caused by: java.sql.SQLTransientConnectionException: RalphPool - Connection is not available, request timed out after 10049ms,
    

    从日志里可以看出来,获取 db 连接的时候,10s 还没有获取到连接,因为 hikari 默认获取连接超时时间设置的是 10s.
    看到这个消息然后就有点怀疑,是不是连接池配置的有问题。

    3.3 分析连接池配置

    来看一下配置:

    spring.datasource.hikari.minimum-idle = 10
    spring.datasource.hikari.maximum-pool-size = 40
    # 就是初始化的时候有 10 个连接,然后最大是 40 个。
    

    然后就分析了这几天的连接信息:
    连接池打印信息
    看了日志,发现最大的连接数没有超过 40 个的, 最多 30 几个,所以连接数不应该是瓶颈呀。

    但是有个问题就是,初始化连接数是 10 个,当一大批请求瞬间涌进的时候,10 个肯定是不够用的,会瞬时添加足够的连接去处理请求。所以想可不可以把初始化连接数加大一下。

    还有下面的问题,同一个方法里的上下行的代码,中间有 6s 的耗时。猜肯定应该也是数据库连接获取的耗时。
    查询问题

    然后看一下 Hikari 官方配置的一些说明:

    hikari 官方配置也建议,minimum-idle 不要配置,或者跟 maximum-pool-size 保持一致。如果有高峰期的需要的话。
    https://github.com/brettwooldridge/HikariCP
    
    minimumIdle
      This property controls the minimum number of idle connections that HikariCP tries to maintain in the pool. If the idle connections dip below this value and total connections in the pool are less than maximumPoolSize, HikariCP will make a best effort to add additional connections quickly and efficiently. 
    
    However, for maximum performance and responsiveness to spike demands, we recommend not setting this value and instead allowing HikariCP to act as a fixed size connection pool. Default: same as maximumPoolSize
    但是,为了最大性能和响应峰值需求,我们建议不要设置这个值,而是允许HikariCP作为固定大小的连接池。默认值:与maximumPoolSize相同
    

    所以基于此,我们把 Hikari 的配置调整了一下。初始化的大小数,调整为 30.调整后的配置如下:

    spring.datasource.hikari.minimum-idle = 30
    spring.datasource.hikari.maximum-pool-size = 200
    

    修改配置后,上线第 2 天的时候,一切正常,而且最大响应时间不超过 2 s.至此问题得到解决。

    4、总结

    连接池的配置,正常 10 个都是够用的,但是遇到高峰期的时候,瞬时过来几百个请求,然后 10 个就明显不够,然后此时连接池就会去创建连接,创建连接的过程是很耗时的,所以就可能会导致连接使用紧张,再加上,本身代码里有锁,查询比较多,所以连接就会释放的慢,所以引发了连锁反应.

    所以如果有瞬时很高的请求的时候,要基于业务来调整相应的数据库连接池配置。

    展开全文
  • String result = HttpRequest.get(url) // 设置请求url .header(X_API_KEY, apiKey) // 设置header .timeout(TIME_OUT) // 设置超时时间 .execute().body();
  • 1.现象: OMS订单履约系统调用供应链基础服务接口超时(图1) 图1 2.调用链查看: 供应链基础服务这段时间内存在一定的接口超时(图2) 图2 根据以往经验首先想到是服务有频繁FULLGC,查看服务是否频繁fullgc...

    1.现象: OMS订单履约系统调用服务接口超时(图1)
    在这里插入图片描述

    							图1 
    

    2.调用链查看: 服务这段时间内存在一定的接口超时(图2)

    在这里插入图片描述

                                                                                                      图2
    
    1. 根据以往经验首先想到是服务有频繁FULLGC,查看服务是否频繁fullgc
      进入jdk bin目录下执行 ./jstat -gccause <进程id> <时间(单位毫秒)> (图3)
      在这里插入图片描述

                                                                     图3
      

    发现虽然有fullgc,但是7月4号启动的进程到7月9号, 总共fullgc次数为14次. 每天平均不到3次 (图4)

    在这里插入图片描述

                                                                                                                                                                                                              图4
    

    4.此时可以断定代码有问题,但是不足以致命,继续跟踪应用服务器性能监控
    cpu: 发现9:22分左右有明显尖刺, 但是整体cpu负载在40%以下(图5)
    在这里插入图片描述

                                                                   图5
    

    网络: 网络流量在9:22分左右有明显尖刺,说明有大量的数据流量占据网络IO(图6)
    在这里插入图片描述

                                                                                                      图6
    

    5.根据上述性能指标分析, 数据包数据来源估计是从DB读取的数据写入到内存,接下来我们看DB的性能指标
    cpu: 9:22分左右cpu使用率在12%左右, 整体负载不高(图7)
    在这里插入图片描述

                                                                                                                                                    图7
    

    iops: iops数据在9:22左右有尖刺, 说明此事有一波较大的瞬时流量打入到DB(图8)
    在这里插入图片描述

                                                                                                                                                     图8
    

    网络流量: 根据9:22分左右网络流量的尖刺, 平均每秒钟输出流量峰值为:46178.8kb, 说明此段时间内存在有问题的查询语句, 并且查询返回的数据量较大,也可能是瞬时并发较大,导致整体的网络流量出现尖刺(图9)
    在这里插入图片描述

                                                                                                                                                       图9
    

    6.根据上述问题,继续往下跟,既然知道了可能是存在大数据量查询的sql语句, 那我们就正好利用sql统计中的审计日志来进行分析
    首先,选择时间段,生成审计日志(图10)
    在这里插入图片描述

                                                                                                     图10
    

    然后对审计日志进行分析,因为我想查找到底是哪个sql返回的行数较大, 所以分析维度选择返回行数
    发现第一个sql执行了2次居然返回了6587993行数据, 第二个sql执行了218次,返回了1274864行数据,

    在这里插入图片描述

    sql1:
    在这里插入图片描述

    sql2:
    在这里插入图片描述

    1. 由此,问题的根本原因基本找到, 这两个sql语句对应的接口在设计上存在问题,第一个是操作日志表(因为历史原因,这个表是整个供应链记录操作记录的日志表), type为5的数据有10108830条记录(表中总共数据为18037716条), 第二个sql是每次查全部生效的类目数据, 但是查询次数较多,并且没有缓存, 穿透到DB, 这两个问题综合引起了整个网络流量的尖刺.
      8.后续解决方案

    A.操作记录日志表及服务按照业务线拆分并做数据迁移.
    B.梳理调用量较大并且数据变更频率不高的接口,完善相应的缓存机制.
    C.一般问题出现时如果初步断定是网络问题的话, 都很有可能是系统问题引起的.需要进一步跟进具体产生此类问题的根源.
    附:
    第2步中细节部分
    1.详细调用链路
    在这里插入图片描述

    上图中的调用行为分以下四种:
    cs - Client Send : 客户端已经提出了请求。这就设置了跨度的开始。
    sr - Server Receive: 服务器已收到请求并将开始处理它。这与CS之间的差异将是网络延迟和时钟抖动的组合。
    ss - Server Send: 服务器已完成处理,并将请求发送回客户端。这与SR之间的差异将是服务器处理请求所花费的时间
    cr - Client Receive : 客户端已经收到来自服务器的响应。这就设置了跨度的终点。当记录注释时,RPC被认为是完整的。

    2.总上所述.服务整个的接口内部处理时间为ss-sr = 2019-07-09 09:23:21 199 - 2019-07-09 09:23:21 190 = 9ms, 但是返回给客户端的RPC耗时为cs-cr = 6s . 很大程度上断定这就是网路问题引起的, 但是一般问题出现时如果初步断定是网络问题的话,
    都很有可能是系统问题引起的.需要进一步跟进具体产生此类问题的根源.

    展开全文
  • 报警邮件中查询到有一部分接口超时量激增,查询定位到某个Dubbo接口,从服务器中top名查询如下: 如上图显示dubbo项目进程CPU占用已经飙高到128%,并且不断在波动,一直维持在130%左右,初步推算是调用量激增...

    线上事故复盘

    前言
    • 前一次上线,当时正常,第二天发现有部分超时报警,最终发现应为Dubbo接口一次传输数据量太大导致线程虚拟内存占用
    线上问题排查过程
    • 报警邮件中查询到有一部分接口超时量激增,查询定位到某个Dubbo接口,从服务器中top名查询如下:

    • 在这里插入图片描述

    • 如上图显示dubbo项目进程CPU占用已经飙高到128%,并且不断在波动,一直维持在130%左右,初步推算是调用量激增导致Dubbo接口请求量变大,导致线程数量消耗,使用Arthas查询消耗CPU资源最多的前面几个线程如下图:
      图不见了: 反正CPU前几名都指向同一个Dubbo接口,命令 Thread -n 5, 查询CPU资源消耗最多的前五名

    • 查询对应Dubbo接口的请求数量,用Awk命令统计今天的请求量看是否增多如下:
      在这里插入图片描述

    • 量居然这么小,因为是新的接口,只有部分功能使用,那么上面估计的请求量的问题应该不存在,但是CPU消耗的却很大,估计是因为耗时太长,在通过TOP命令查询,问题发现Men区域内核缓冲使用量很高39562828,比之空闲的物理内存379888高两个数量级
      在这里插入图片描述

    • 量这么小的Dubbo接口能把交换区的资源耗尽,那问题就比较明显了,应该是每次处理的数据体量太大,内存不够,导致处理数据变慢,接口响应时间变慢,那之后就好查询了,继续更这个接口,看那部分信息有问题,发现在sql查询中查了一个这个字段,text类型,超级大,并且一次查出来的数据条数也比较大,导致最终Dubbo接口需要返回的数据量太多

    `detail` text COMMENT '摘要',
    
    • 因dubbo协议采用单一长连接,如果每次请求的数据包大小为500KByte,假设网络为千兆网卡(1024Mbit=128MByte),每条连接最大7MByte(不同的环境可能不一样,供参考),单个服务提专供者的TPS(每秒处理事务数)最大为:128MByte / 500KByte = 262,单个消费者调用单个服务提供者的TPS(每秒处理事务数)最大为:7MByte / 500KByte = 14。
    • 如上名计算如果我数据量继续变得更大,但是没有超过Dubbo限制情况下,其实每次处理数据是非常消耗内存与IO的。
    • 最终修改将不必要字段去除,上线发布,耗时下降,内存信息,cpu都恢复正常,如下图:
      在这里插入图片描述
    展开全文
  • 关于线上一次超时处理引发的思考 背景 最近关于线上关于注册问题有超时2s的情况发生,最长时间已经是9s多,上游系统最多只能...nginx问题,由于我负责的是最下游系统,我检查我的接口超时情况,偶尔有个别的超时,...
  • 于是检查了下代码,发现这个POST请求真的没有设置socket_timeout超时时间。 /** * 发送post请求(xml字符串) * * @param url * @param data * @return */ public static String postXml(String ...
  • 先打开小程序后台找到开发管理-开发设置,如下图看看你的请求路径是否在ip白名单中,这里可以填ip地址如127.11.11.11或者https://baidu.com,这样接口请求应该是没问题了,涉及到一些资源下载或者其他的还有问题接在...
  • httpclient请求接口超时问题

    千次阅读 2019-11-04 16:03:16
    最近线上出现一个问题,外部请求过来后一直没有响应给调用方,看日志没有报错,可以复现。 想到的就可能是五个原因: 日志文件过大导致磁盘空间满了,导致正常的业务日志无法写入,但是重启后发现日志能正常写入,...
  • 特别是线上调用第三方dubbo服务的时候,如果没有输出返回结果信息,如何排查是否是第三方dubbo接口返回的数据有问题,还是我们本身的代码有问题呢,下面这段代码可以实现在本地环境直接调用线上的dubbo服务接口,并...
  • 今天线上项目出现链接超时,开始排查问题 简单的一次请求的流程(需要调用第三方): 页面-->服务-->第三方 首先修改了服务到第三方的,就是修改项目中的http请求超时时间:修改http请求超时时间 修改完,...
  • 2、后台通知交互时,如果微信收到商户的应答不符合规范或超时,微信会判定本次通知失败,重新发送通知,直到成功为止(在通知一直不成功的情况下,微信总共会发起多次通知,通知频率为15s/15s/30s/3m/10m/20m/30m/30...
  • 本文将会给大家分析一个线上的真实生产案例,在这个案例中,一个每秒仅仅只有100+请求的系统却频繁的因为OOM而崩溃。 在对这个案例进行深度分析的时候,大家会看到一个OOM问题是如何牵扯到Tomcat底层工作原理、...
  • 这几个功能都调试的差不多了,准备换成线上正式接口了,结果却出了问题,提示请求超时。。。 然后百度了一些相关问题,发现有说签名算法不对的,有说服务器SSL配置问题的,等等。。。 签名、时间戳、key都用的通用...
  • 昨天线上小白系统因为调用外部http接口超时不释放,导致页面反应很慢,时间一长,报502错误。 上网查了下,502错误是因为服务对于客户的请求没有得到及时的反应,查询日志,发现很多调http接口异常,页面反应也很...
  • 桔妹导读:业务中超时抖动是大家平时比较容易遇到的一种技术问题,本文详细记录了一次线上容器中高频 go 服务超时的排查过程。本文可以给大家提供查服务业务超时问题的一些思路,理解为什么 go...
  • 通过业务保障平台发现订单查询接口一直出现sockettimeoutexception。 三.问题原因: 如果okhttp第一次出现sockettimeoutexception,后续即使网络已经恢复正常,请求也始终返回sockettimeoutexception,必须等到双活...
  • 非高峰期,每次获取二维码接口处理响应4s左右。 高峰时期,相同消息是等待前面消息返回后,再给出返回,相当于串型处理。即,并发越高,等待越长。 事务控制 事务1 事务2 备注 begin begin select A...
  • 支付接口响应超时处理

    千次阅读 2018-01-23 17:33:50
    问题:调用第三方支付接口响应时间超过10秒,导致大量线上订单因为超时失败,该接口是实时返回结果的,而且不是一直都慢,是偶尔慢。  解决方法:调用接口时设置超时时间,当接口超过9秒未返回结果,自动将改订单...
  • 第三方支付接口响应超时处理方法

    万次阅读 2016-12-30 15:39:48
    问题:调用第三方支付接口响应时间超过10秒,导致大量线上订单因为超时失败,该接口是实时返回结果的,而且不是一直都慢,是偶尔慢。 解决方法:增加接口调用监控,预定超时时间9秒(为了安全起见),当接口超过9秒...
  • 最近写了一个线上数据处理的接口,发布上线后,调用了一下,结果发现居然请求了两次。 原因是数据处理的接口时间比较长,nginx有超时重试的设置,所以导致接口重试了,请求了多次,记录一下。 ...
  • 一天突然收到线上不同MQ消息积压告警,于是去消息界面查看积压情况,同一个服务所在的多个MQ出现不同程度的积压,应该不是业务导致的正常积压,猜测可能是服务出了问题 二、问题排查 1、依赖rpc接口超时 ...
  • 上面这张监控图,对于服务端的研发同学来说再熟悉不过了。...这篇文章将通过一个真实的线上事故,系统性地介绍下:在微服务架构下,该如何正确理解并设置RPC接口超时时间,让大家在开发服务端接口时有更全局的..
  • 一次线上关键REST接口调用卡死bug排查背景介绍初步排查组织攻关排查乱查一通现场再次复现总结 背景介绍 本来是可以在文章标题中将bug现象说的更具体一点,但聪明TX可能一眼就知道问题所在,相对来说没有了挑战性。 ...
  • RPC的超时设置,一不小心就是线上事故 上面这张监控图,对于服务端的研发同学来说再熟悉...这篇文章将通过一个真实的线上事故,系统性地介绍下:在微服务架构下,该如何正确理解并设置RPC接口超时时间,让大家在开
  • 上面这张监控图,对于服务端的研发同学来说再熟悉不过...这篇文章将通过一个真实的线上事故,系统性地介绍下:在微服务架构下,该如何正确理解并设置RPC接口超时时间,让大家在开发服务端接口时有更全局的视野。内..
  • 上面这张监控图,对于服务端的研发同学来说再熟悉不过了。...这篇文章将通过一个真实的线上事故,系统性地介绍下:在微服务架构下,该如何正确理解并设置RPC接口超时时间,让大家在开发服务端接口时...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 16,921
精华内容 6,768
关键字:

线上接口超时