精华内容
下载资源
问答
  • 最近公司现网查询速度极慢,原因是因为有一个调度频繁查询产品详情,经理安排进行优化 笔者第一时间想到的是使用缓存,但因为生产环境产品信息量将近上千条热点数据,为防止撑爆服务器内存,考虑到了使用redis缓存。...

    最近公司现网查询速度极慢,原因是因为有一个调度频繁查询产品详情,经理安排进行优化
    笔者第一时间想到的是使用缓存,但因为生产环境产品信息量将近上千条热点数据,为防止撑爆服务器内存,考虑到了使用redis缓存。代码实现如下

    1、先在详情查询接口添加缓存注解

    在这里插入图片描述
    2、在所有需要更新缓存信息的地方,添加删除缓存注解
    在这里插入图片描述

    注意,坑就在这个allEntries注解!
    先通过info命令查询发现redis内存占用才1g,而我们线上redis内存有5g多。那么考虑是否是因为某些查询过慢导致的读取超时呢?

    慢查询记录数

    slowlog len

    获取慢查询数量前几条数据

    slowlog get n
    在这里插入图片描述
    发现查询有一个get qryProdDeatil* 的命令查询耗时极慢,速度排行第一.

    !!! 至此结果已经出来了,因为@CacheEvict注解
    的allEntries属性设置为true,会去删除redis里的整个分区的缓存key(以某一字符串开头),导致模糊匹配,数据未在规定的缓存超时时间返回。

    展开全文
  • 异常信息: Timeout expired. The timeout period elapsed prior to completion of the operation or the server is not responding. 原因: dapper 2.0 的 源代码如下 ,不满 4000长度的 字符串 按照 varchar(4000) ...

    异常信息: Timeout expired.  The timeout period elapsed prior to completion of the operation or the server is not responding.

    原因: dapper 2.0 的 源代码如下 ,不满 4000长度的 字符串 按照 varchar(4000) 处理了

    解决方法:

    convert(varchar(64),@Account)

    展开全文
  • 数据库内部对象X$统计信息过旧,导致v$lock查询慢 前段时间用python写了个zabbix监控脚本,里面有一个检查锁的sql语句,sql语句是这样子的select count(*) retvalue from v$lock where type in('TM', 'TX') and ...

     数据库内部对象X$统计信息过旧,导致v$lock查询慢

    前段时间用python写了个zabbix监控脚本,里面有一个检查锁的sql语句,sql语句是这样子的
    select count(*) retvalue from v$lock where type in('TM', 'TX') and ctime > 600;
    但是zabbix界面显示这条语句超时,zabbix超时时间默认是3s,我将其改为15s,竟然还是超时,看样子要仔细研究这个sql语句了。
    这一看不得了,这条语句执行用了18s,统计v$lock的行数竟然要7min之久,这明显无法接受。

    SQL> select count(*) retvalue from v$lock where type in('TM', 'TX') and ctime > 600;
    
      RETVALUE
    ----------
             0
    
    Elapsed: 00:00:18.82

     

    查看其执行计划

    SQL> select * from table(dbms_xplan.display_cursor());
    
    ---------------------------------------------------------------------------
    | Id  | Operation               | Name       | Rows  | Bytes | Cost (%CPU)|
    ---------------------------------------------------------------------------
    |   0 | SELECT STATEMENT        |            |       |       |     1 (100)|
    |   1 |  SORT AGGREGATE         |            |     1 |    53 |            |
    |*  2 |   HASH JOIN             |            |     1 |    53 |     0   (0)|
    |   3 |    MERGE JOIN CARTESIAN |            |     1 |    41 |     0   (0)|
    |*  4 |     FIXED TABLE FULL    | X$KSUSE    |     1 |    19 |     0   (0)|    
    |   5 |     BUFFER SORT         |            |     1 |    22 |     0   (0)|
    |*  6 |      FIXED TABLE FULL   | X$KSQRS    |     1 |    22 |     0   (0)|    
    |   7 |    VIEW                 | GV$_LOCK   |    10 |   120 |     0   (0)|
    |   8 |     UNION-ALL           |            |       |       |            |
    |*  9 |      FILTER             |            |       |       |            |
    |  10 |       VIEW              | GV$_LOCK1  |     2 |    24 |     0   (0)|
    |  11 |        UNION-ALL        |            |       |       |            |
    |* 12 |         FIXED TABLE FULL| X$KDNSSF   |     1 |    77 |     0   (0)|    
    |* 13 |         FIXED TABLE FULL| X$KSQEQ    |     1 |    77 |     0   (0)|    
    |* 14 |      FIXED TABLE FULL   | X$KTADM    |     1 |    77 |     0   (0)|    
    |* 15 |      FIXED TABLE FULL   | X$KTATRFIL |     1 |    77 |     0   (0)|    
    |* 16 |      FIXED TABLE FULL   | X$KTATRFSL |     1 |    77 |     0   (0)|    
    |* 17 |      FIXED TABLE FULL   | X$KTATL    |     1 |    77 |     0   (0)|    
    |* 18 |      FIXED TABLE FULL   | X$KTSTUSC  |     1 |    77 |     0   (0)|    
    |* 19 |      FIXED TABLE FULL   | X$KTSTUSS  |     1 |    77 |     0   (0)|    
    |* 20 |      FIXED TABLE FULL   | X$KTSTUSG  |     1 |    77 |     0   (0)|    
    |* 21 |      FIXED TABLE FULL   | X$KTCXB    |     1 |    77 |     0   (0)|    
    ---------------------------------------------------------------------------
    
    Predicate Information (identified by operation id):
    ---------------------------------------------------
    
       2 - access("SADDR"="S"."ADDR" AND
                  TO_CHAR(USERENV('INSTANCE'))||RAWTOHEX("RADDR")=TO_CHAR("R"."INST_ID")||
                  RAWTOHEX("R"."ADDR"))
       4 - filter("S"."INST_ID"=USERENV('INSTANCE'))
       6 - filter(("R"."KSQRSIDT"='TM' OR "R"."KSQRSIDT"='TX'))
       9 - filter(USERENV('INSTANCE') IS NOT NULL)

     

    统计v$lock的行数

    SQL> select count(*) from v$lock;
    
      COUNT(*)
    ----------
           600
    
    Elapsed: 00:07:46.84  

    这条语句的执行计划与上面的一样,这里我就不贴出来了

    v$lock只有600行,怎么会执行时间这么久,通过v$session能看到这条语句的等待事件为"direct path read temp"
    该等待事件表示服务器进程直接读取临时表空间的数据,通常由临时表太大造成。从上面的执行计划中可以看出临时表很大的原因可能是"MERGE JOIN CARTESIAN"。
    "MERGE JOIN CARTESIAN"表示笛卡尔联接,如果两表的行数都不小的话,这的确会造成临时表过大。查看X$KSUSE,X$KSQRS的行数

    SQL> select count(*) from X$KSUSE;                                                  
    
      COUNT(*)
    ----------
          4544
    
    SQL> select count(*) from X$KSQRS;
    
      COUNT(*)
    ----------
         20224

     这几千和几万来个笛卡尔积就是几千万的临时数据了,而我的pga只有4g,pga不够所以就用到了临时表空间进行表关联,也就造成了等待事件,所以说这条语句慢的主因就是这个笛卡儿积。

    这条语句之前执行都好好的,为什么现在慢了呢,最可能的情况是统计信息过旧,因为自动统计信息收集job不会收集固定对象也就是X$表的统计信息。

     

    收集下固定对象的统计信息

    SQL> begin
         dbms_stats.gather_fixed_objects_stats;
         end;
         /
    
    PL/SQL procedure successfully completed.  

     

    再执行以下语句,可以看到执行时间0.1s都不到,而且执行计划也恢复正常,赶紧在我这边的生产库把类似问题进行处理,嘿嘿。

    SQL> select count(*) from v$lock;
    
      COUNT(*)
    ----------
           600
    
    Elapsed: 00:00:00.08
    
    SQL> select * from table(dbms_xplan.display_cursor());
    
    ---------------------------------------------------------------------------------------
    | Id  | Operation                | Name       | Rows  | Bytes | Cost (%CPU)| Time     |
    ---------------------------------------------------------------------------------------
    |   0 | SELECT STATEMENT         |            |       |       |    29 (100)|          |
    |   1 |  SORT AGGREGATE          |            |     1 |    36 |            |          |
    |   2 |   HASH JOIN              |            |  3034 |   106K|    29 (100)| 00:00:01 |
    |   3 |    HASH JOIN             |            |    15 |   360 |    23 (100)| 00:00:01 |
    |   4 |     VIEW                 | GV$_LOCK   |    15 |   180 |    22 (100)| 00:00:01 |
    |   5 |      UNION-ALL           |            |       |       |            |          |
    |   6 |       FILTER             |            |       |       |            |          |
    |   7 |        VIEW              | GV$_LOCK1  |     7 |    84 |    15 (100)| 00:00:01 |
    |   8 |         UNION-ALL        |            |       |       |            |          |
    |   9 |          FIXED TABLE FULL| X$KDNSSF   |     1 |    16 |     1 (100)| 00:00:01 |
    |  10 |          FIXED TABLE FULL| X$KSQEQ    |     6 |   102 |    14 (100)| 00:00:01 |
    |  11 |       FIXED TABLE FULL   | X$KTADM    |     1 |    20 |     5 (100)| 00:00:01 |
    |  12 |       FIXED TABLE FULL   | X$KTATRFIL |     1 |    14 |     0   (0)|          |
    |  13 |       FIXED TABLE FULL   | X$KTATRFSL |     1 |    14 |     0   (0)|          |
    |  14 |       FIXED TABLE FULL   | X$KTATL    |     1 |    20 |     0   (0)|          |
    |  15 |       FIXED TABLE FULL   | X$KTSTUSC  |     1 |    14 |     0   (0)|          |
    |  16 |       FIXED TABLE FULL   | X$KTSTUSS  |     1 |    16 |     0   (0)|          |
    |  17 |       FIXED TABLE FULL   | X$KTSTUSG  |     1 |    14 |     0   (0)|          |
    |  18 |       FIXED TABLE FULL   | X$KTCXB    |     1 |    18 |     1 (100)| 00:00:01 |
    |  19 |     FIXED TABLE FULL     | X$KSUSE    |  4544 | 54528 |     1 (100)| 00:00:01 |
    |  20 |    FIXED TABLE FULL      | X$KSQRS    | 20224 |   237K|     5 (100)| 00:00:01 |
    ---------------------------------------------------------------------------------------

     

    总结:
    1.一些动态性能视图v$查询很慢的话,可能是由于动态性能视图所查询的内部对象表x$统计信息过旧,cbo选择了错误的执行计划造成。
    2.自动统计信息收集job不会收集内部对象表的统计信息,所以需要dba定时手工收集,或者是自己创建个job定期执行。

    转载于:https://www.cnblogs.com/ddzj01/p/10812076.html

    展开全文
  • 怀疑是网关服务注册问题,导致部分请求超时,查找网关对应服务注册的ip列表,对比发现有一批新的ip,运维定位为容灾环境ip(之前未开启容灾环境),运维下载容灾环境日志,发现出现对应接口超时的日志,原因为容灾...

    问题场景
    灰度期间生产环境出现偶发性异常报错“网络连接错误”。
    临时解决方案
    使用app老版本,问题依然存在,确认是后台灰度问题,后台回滚对应灰度,生产问题得到临时解决。
    问题查找
    查看app的请求日志id,后台查不到对应请求,且查询生产后台日志未发现报错请求。怀疑是网关服务注册问题,导致部分请求超时,查找网关对应服务注册的ip列表,对比发现有一批新的ip,运维定位为容灾环境ip(之前未开启容灾环境),运维下载容灾环境日志,发现出现对应接口超时的日志,原因为容灾环境接口未开通防火墙导致到容灾环境的流量超时。
    问题反思
    开容灾环境应提前确认
    1.所有配置信息对应的开墙,代理 ,白名单等信息
    2.提前对接好日志查询,方便研发查日志

    展开全文
  • 根据传入的member_id去查询member数据表里的member数据。 member表16W的数据。 压测的结果,大部分请求都能正常响应,但是会有0.015%的概率出现响应超时。 请问是什么原因呢? <pre><code>php ...
  • 由报错信息可初步确认是由于数据库锁等待超时导致查询异常,即上述查询中的表被另 一个并行事务锁住,而执行该事务的线程状态为sleep,当锁表时间超过mysql设置参数innodb_lock_wait_timeout,会引发上述故障现象。...
  • 报错信息如下 MySql.Data.MySqlClient.MySqlException: 'Timeout expired. The timeout period elapsed prior to completion of the operation or the server is not responding.' System....
  • 查询

    2018-06-16 08:55:44
    一.慢查询日志慢查询日志帮助开发和运维...Redis客户端一条名利分为如下四部分执行: 说明:①慢查询日志只是统计步骤3)执行命令阶段 ②客户端超时不一定慢查询,但是慢查询是客户端超时的一个可能原因。 二. 慢...
  • 错误信息: System.NotSupportedException:“The specified LINQ expression contains references to queries that are associated with different contexts.” 不支持的异常:指定的Linq语句包含了来自不同上下文...
  • Golang 分表查询优化

    2021-02-08 18:39:01
    新实现方案在大客户(具有单表十万以上记录)分页offset操作时依赖会超时,需要解决,其根本原因是单表记录数过多,导致offset遍历费时。 后续查具体list列表信息时,只需要代入对应的{表名(例如:login_info_202106...
  •  收到疯狂的慢查询及请求超时报警,通过metrics分析出来自mysql请求的异常,cli —> show proceslist 看到很多慢查询。 先前该sql是没有的,后面因为数据量的增长才出现了这问题。 虽然feeds表大到一个亿,但因为...
  • mysql开启事务后没有提交就退出,事务长时间running状态,进程又处于Sleep状态,有可能后续导致其他事物超时失败 常见原因 事务过程中执行其他非数据库操作,导致事务长期未被处理。 事务处理异常或实现逻辑有误...
  • mysql数据库查询时,遇到下面的报错信息: 二、原因分析: dw_user 表数据量比较大,直接查询速度慢,容易"卡死",导致数据库自动连接超时.... 三、解决办法: 方案1.在mysql配置文件[myslqd]下面添加一行设置skip-...
  • 可能很多网站运营者都遇到过这种情况,在...当出现域名解析异常的情况时,首先可以使用whois工具查询域名的状态信息,如果域名状态显示为“serverHold”、“clientHold”,则域名无法被解析,这种情况可能是由于未进行.
  • mysql数据库查询时,遇到下面的报错信息: 二、原因分析: dw_user 表数据量比较大,直接查询速度慢,容易"卡死",导致数据库自动连接超时.... 三、解决办法: 方案1.在mysql配置文件[myslqd]下面添加一行设置skip-...
  • `creditCheckingAmount` decimal(12,2) DEFAULT NULL COMMENT '信审查询费', `accountManageAmount` decimal(12,2) DEFAULT NULL COMMENT '账户管理费', `customerServiceAmount` decimal(12,2) DEFAULT NULL ...
  • 另外这个系统有一个高级查询功能我没有写,其原因一是我觉得现在的系统在功能上可能满足不了实际需要,二是以现在的功能如果只是测试已经足够。 如果这个系统不能满足您的需要,请Delete它,如果这个系统很好用,你...
  • 如题,最近网站频繁出现502错误,简直无法正常运转,出现这种情况大多是php-cgi超时没有返回信息,或进程僵死等情况造成的。我们的nginx已经配置到极致这些都已经老早做过修改了,但现在又出然出现。代理服务器,ip...
  • 今天我在开启Tomcat的时候遇见了这个报错,经我查询信息和报错后发现,系统报这个错误的原因是因为: 1. 连接的端口号出现了问题 检查你的远程连接端口号port是否存在,是否真确. 2. 远程服务器超时或者未运行,连接出现...
  • 全表查询数据查询失败(大概有180万条) 报错信息 ...具体原因是一次查询超时,导致sql未执行完并且报错 优化sql 分页查询并且一次只查询1000进行处理,本身就是定时任务,所以耗时并不影响 图片: ...
  • 不采用直接查询数据库的原因简单说一下,是因为这个客户信息相关的表第一数据量太大了,遍历表查询很容易超时,也不符合业务逻辑,第二,相关表信息的引用处理真的太多了,存在嵌套查询和循环遍历的问题。...
  • 2020-10-27

    2020-10-27 10:29:52
    记录oracle 数据库遇见的坑 近日正常的项目在打印报表时:出现连接超时提示,系统可以正常启动,用户登陆也可以正常完成,使用...3、查询数据库日志,未发现数据库错误信息。 转换思路,数据库连接速度慢。 原因
  • 博主遇到过使用cloudera manager重启集群后出现多个节点所有功能均无法连接,对该主机功能进行单点启动时并无报错信息,因为查询不到报错信息,就无法针对性的进行修复,所以进行多次测试定位到问题原因: 常见单...
  • 前言 SQL优化是程序开发中经常遇到的问题,尤其是在程序规模不断扩大的时候。...SQL不够健壮易造成数据查询超时、SQL注入、信息泄漏等问题。 SQL优化归根到底是SQL语句的优化,索引的优化。由于很...
  • redis阻塞

    2019-07-19 10:33:54
    2.阻塞的内在原因:确认主线程是否存在阻塞,检查慢查询信息, 发现不合理使用API或数据结构的情况,如keys、sort、hgetall等。关注CPU 使用率防止单核跑满。当硬盘IO资源紧张时,AOF追加也会阻塞主线程。 3.阻塞...
  • 使用常用的的SmtpClient进行发送,在本地进行了126的邮箱进行测试通过,客户发来对应的邮箱信息后告知是使用的是465加密端口,SSL加密协议,再把相关信息进行配置替换后发现邮件发送一直报超时,一直也找不到原因。...
  • 安全狗云备份V1.2版

    2014-06-25 16:37:08
    新增网马文件详情、备份失败原因信息展示,同时,优化日志功能界面; 4、【新增对SQL2000支持】 新增对SQL2000备份还原支持; 5、【新增文件状态标示】 新增网站文件状态标示,同时,新增文件状态快速筛选,...
  • logback控制台输出导致进程假死

    千次阅读 2019-12-24 16:24:44
    记一次线上logback日志的问题,微服务调用时客户端调用服务端超时, 检查线上机器后发现机器没有什么问题,GC也正常,于是使用...网上查询后,最终解决方案是日志不往控制台输出,但是里面具体的原因还有待探究 ...

空空如也

空空如也

1 2 3 4 5
收藏数 86
精华内容 34
关键字:

查询信息超时原因