- 综合排序
- 最热优先
- 最新优先
- 来自专栏学习内容
jvm异常排查
class占用) 1、jmap：生成dump文件 test05.txt：生成的文件 115025：PID jmap -dump:live,format=b,file=test05.txt 115025 2、
27910编辑于 2023-08-09 - 来自专栏kl的专栏
j2Cache线上异常问题排查记录
项目使用了j2Caceh，异常是j2Cache的RedisCacheProvider抛出来的，如： Exception in thread "main" redis.clients.jedis.exceptions.JedisException (Pool.java:49) ... 3 more j2Cache:红薯开源的2阶段缓存框架：https://gitee.com/ld/J2Cache 问题分析 从异常日志表象上看，很明显是由于jedis 无外乎两点，如下： 1、正常情况：程序并发高，导致偶发性的连接池无可用资源 2、异常情况：连接池使用不当，当从连接池获取资源后，使用完时没有正常的释放资源，导致连接池取一个少一个，最后必然性的会抛出开头的异常 重新假设 如果不是连接泄漏导致的，那么肯定是并发问题了，最终的异常是j2Cache抛出来的，从j2Cache里获取连接的地方如下： 可以看到最上面红框里的是之前说的有问题，其实没有问题，他们都被包在了try 那么我们在程序里可用的连接数=（最大连接数-两个长期占用连接）=（8-2）=6个 从异常信息获取点有用信息，最终发现，抛出连接不可用的代码有共性，都指向了一个类，但是是两个方法，如： 最终跟踪代码发现，
55030编辑于 2023-11-18 - 来自专栏Android码农
线上数据异常引发的崩溃排查记录
线上数据异常的崩溃，最大的关键是还原线上数据 一个崩溃的引申 最新版本，线上报了一个崩溃，崩溃堆栈如下 Caused by: java.util.NoSuchElementException: Collection 3156) at android.view.ViewRootImpl.doTraversal(ViewRootImpl.java:2112) 很显然，这个是混淆后的崩溃，我们用对应的mapping文件排查 ，正常情况下是不会出现这个情况的，于是怀疑是接口返回的数据异常 还原异常数据 崩溃的时候，是不会上报崩溃时候的数据的，通过代码，可以知道崩溃的是页面的商详页，所以需要定位到具体是浏览哪个商品崩溃了 / time desc; 已知崩溃的时间是2021-09-13 09:38:13，查找对应崩溃时间的上报记录 定位到了跟崩溃吻合的上报事件，并且也有上报商品的id，所以知道了具体哪个商品导致的崩溃了 排查异常数据 知道某个商品有异常后，模拟请求该商品数据，发现该商品返回的阶梯价逻辑上不合理，最大购买数量超过了跟阶梯价最大量 问题得以定位，接下来跟后端伙伴反馈该问题，等后端修复上线后，可以线上直接修复该问题，
99420发布于 2021-09-29 - 来自专栏Windows技术交流
排查云镜异常
排查云镜异常，可以收集云镜日志让售后看下C:\Program Files\QCloud\YunJing\log复制该目录，对复制后的目录进行压缩，压缩成.7z格式（压缩率高，压缩文件小，方便传输）云镜的
2K40编辑于 2022-06-21 - 来自专栏ES排障
ES异常排查之-熔断
集群熔断-Data too large 问题现象： 排查监控发现存在熔断，查看日志如下 应用日志： 2022-05-24T21:17:53.142+0800 ERROR service/ indices.breaker.fielddata.limit,如下图为20% image.png 常用的内存清理方法 清理 fielddata cache： 在 text 类型的字段上进行聚合和排序时会使用 fileddata 数据结构 new bytes reserved: [275/275b] Field data 熔断器（Field data breaker） 当对 text 字段聚合或排序时，会产生 Field data 数据结构 Field data 熔断器会预估有多少数据被加载到内存中。当预估的数据占用内存到达 Field data 熔断器阈值时，会触发 Field data 熔断器熔断。
4.1K40编辑于 2022-05-25 - 来自专栏python3
异常排查_Python.[alembic
develop': __DevelopmentConfig, 'testing': __TestingConfig, 'product': __ProductionConfig, } 问题排查 此应用为一个网络检测展示程序,为了简化就没有使用任务队列,直接后端跑一个mtr检测,利用协程的方式不影响前端数据获取和展示 2. .51cto.com/ # Purpose: # """ # 说明: 导入公共模块 from app import db as _db from app import create_app # 说明: 为数据库检测
1.1K30发布于 2020-01-07 - 来自专栏计费&账号专家服务
扣费异常基本排查
背景 在使用腾讯云产品过程中，经常会遇到一些类似扣费异常，但又无法确认是否扣费异常的问题；本文基于这个主题，将通过一些案例来总结一下关于扣费异常的基本排查方法。 如何查看扣费详情？ 案例2、当月费用对比上个月增加/减少 10月份消耗金额对比9月份消耗金额增加了，需核实费用增加原因。 排查方法-------通过明细账单自助排查 1）在账单概览控制台查看费用趋势，确认费用上涨的产品。 image.png 2）按量结算资源销毁后，但持续产生扣费，有可能是因为延迟扣费导致（在该结算扣费时间段内未扣费，在后续时间段补扣） 如何在明细账单判断为延迟扣费可参考附图（9月2号晚上23:00-23 总结 账号产生莫名扣费时，可以先通过收支明细和账单查看扣费产品及扣费时间，然后通过对应扣费产品的计费文档了解扣费规则，自助排查扣费是否属于异常情况。
2.5K70发布于 2020-11-13 - 来自专栏猫头虎博客专区
SocketException：Connection reset 异常排查
长连接中，向server发请求，是先发送数据的，如果连接断开，应该是写数据异常，为什么是读数据异常呢？请求是否发送成功？发送之前有校验连接是否可用吗？ 第2个异常是java.net.ConnectException: Connection refused: connect。 该异常在客户端和服务器端均有可能发生，引起该异常的原因有两个，第一个就是如果一端的Socket被关闭（或主动关闭或者因为异常退出而引起的关闭），另一端仍发送数据，发送的第一个数据包引发该异常(Connect 现在可以回答前面的问题 长连接中，向server发请求，是先发送数据的，如果连接断开，应该是写数据异常，为什么是读数据异常呢？请求是否发送成功？发送之前有校验连接是否可用吗？ 本文就是一个例子，2s检查没有问题，但在使用之前的2s内网络出了问题，这就没有办法了。
3.1K20编辑于 2024-04-08 - 来自专栏TIGERB的技术博客
线上服务负载异常排查
前言 除了解决业务Bug之外，工作中通常我们还会面临两类问题： 线上服务负载异常，比如CPU负载异常飙高 线上服务内存持续增长，存在泄漏 一般我们会通过各种监控、报警系统，发现和定位问题，关于如何搭建服务监控可以参考之前的文章 所以今天就来看看这种情况下，如何定位服务负载异常的原因。 首先关于「负载异常」的问题，大都肯定都知道使用top或者htop等命令定位到某个进程或线程，好，问题来了： 如何定位到是哪个具体的函数导致的服务负载异常呢？ Balsamiq Mockups 3 2. Processon
68220编辑于 2022-03-14 - 来自专栏敲得码黛
生产环境NoHttpResponseException异常排查记录
生产环境发现的问题 1、NoHttpResponseException导致退款失败 功能上线后，我便开始监控B端支付模块的交易数据，前两天的数据并没有什么异常，支付完成的订单都已经退款完成。 然后在第三天快下班时，我又统计了一遍数据，发现竟然存在一笔没退款的订单，我整个人一下子就支棱了起来（不会又写了个Bug吧~），我先在数据库中查到订单号，然后找运维同事拿了一下日志，发现支付回调是正常的， 排查到这里基本已经可以确定不是支付模块这边的问题了，但问题毕竟还是要解决的，于是我联系了C端的同事，暂时先通过接口的方式把消费者的钱进行退款。 然后开始排查C端系统的问题，通过C端的日志发现，在请求支付模块进行退款时存在一个异常信息，报错信息如下 ? 2、 异常情况分析 目前能够提供帮助的信息并不多，只有这一个报错日志，通过在网上收集到的一些相关资料，发现了几篇比较有借鉴价值的文章，他们的观点也都几乎一致：服务端主动断开TCP链接，然后客户端使用半断开的链接发起请求时
2.3K10发布于 2021-07-22 - 来自专栏码客
邮件服务器异常排查
无法接收邮件 首先邮件发送的过程中，需要解析“收件人的域名”的MX与A记录，下面是测试这2个记录的步骤。
6.2K50发布于 2019-10-22 - 来自专栏慕枫技术笔记
Java服务异常排查定位大图
引言 研发工程师日常的工作除了开发实现新需求之外，排查定位问题也是重要的组成部分。 因此本文主要聚焦日常工作中经常遇到的异常场景，梳理了问题排查定位的思路大图，这样大家在实际项目中如果遇到类似的异常场景，可以按照思路大图进行问题排查定位解决，相信大家掌握了故障定位的分析套路之后就可以做到遇到问题时临危不乱 其中代码Bug为主要原因，因此在我们实际写代码的过程中就需要考量内存占用的问题，特别是对于一些递归操作、服务内一次缓存大量数据、在for循环中查询数据等都要特别注意或者避免。 因此分析排查定位过程也是主要从这两方面出发，服务自身问题主要包括代码Bug、系统资源异常使用等，依赖方主要包括依赖的中间件、下游服务接口等。 同时结合实际的经验提炼了各个异常情况下的问题根因分析思路以及排查定位大图，大家在遇到类似问题的时候可以参考大图中的思路进行问题排查定位以及解决。 END
77920编辑于 2023-03-20 - 来自专栏通用型流式数据统计
实用技巧：排查数据异常数据波动问题，该如何下手？
大多数的服务故障都有较为直观的异常日志，再结合产品表象，相对排查起来还有迹可循，但数据异常的原因就太多了，很多时候连报错日志都没有，排查起来简直无从下手。 行业目前的现状如果自身服务有异常日志，一眼就能确认问题还好说，但如果自身服务一切正常，那排查起来可得费老大劲了。这种数据异常问题，往往是突然发生，打你一个措手不及。 用一句话评价它在排查数据异常类问题的使用体验，那就是：简单、简单、你未曾体验过的简单！ 如何使用XL-LightHouse排查数据异常类问题？归根到底是一句话：在任何你有需要的地方加上流式统计。 示例2：各终端订单量数据监控假设场景：交易服务需要监控不同来源下单量的数据。
62710编辑于 2024-04-12 - 来自专栏johnnyxsu技术交流分享
CLB健康检查异常排查流程
四层转发健康检查 四层转发的健康检查机制由负载均衡器向配置中指定的服务器端口发起访问请求，如果端口访问正常则视为后端服务器运行正常，否则视为后端服务器运行异常。 假设在某场景下，HTTP 返回值为http_1xx、http_2xx、http_3xx、http_4xx和 http_5xx 这几种，用户可以根据业务需要编辑http_1xx及http_2xx为服务正常状态 ，并设置http_3xx至http_5xx的返回值代表异常状态。 公网CLB 探测源是CLB的VIP，需要用户的机器放通vip（受客户安全组限制而且受iptable限制） 健康检查异常排查 了解了健康检查的原理，下面就介绍一般排查健康检查的一些思路。 详细内容可以参见本人写的另一篇文档 《玩转CVM之tw_reuse和tw_recycle》 如果以上都排查没有问题，但健康检查还异常，请联系腾讯云售后人员进一步排查。
7.4K1361发布于 2019-07-25 - 来自专栏Greenplum
Linux 系统出现异常排查思路
16 系统出现异常排查思路 16.1 查看用户信息 16.1.1查看当前的用户 # who 04:39:39 up 1:30, 1 user, load average: 0.01, 0.01, Ss 03:09 0:02 /sbin/init root 2 0.0 0.0 0 0 ? 0 4096B sshd: root@ 136B 180B|jbd2/sda2-8 0 56k 16.10文件系统以及外接磁盘的信息 16.10.1查看当前的挂在的设备 # mount / UUID=6a5cde98-2fc5-4d8f-976c-92acb39ab2a9 swap swap defaults 0 0 tmpfs IO-APIC-edge 8: 1 IO-APIC-edge rtc0 9: 0 IO-APIC-fasteoi acpi 查看链接数据库的信息
4.3K20发布于 2019-08-05 快速解决YashanDB数据库连接异常及故障排查指南
因此，对于运维人员而言，及时、高效地排查和解决这些连接异常，不仅有助于提高系统的可用性，也可以避免潜在的业务损失。 本文旨在提供有效的YashanDB数据库连接异常排查策略，从而帮助技术团队更好地定位并解决相关问题。YashanDB数据库连接异常排查的核心技术点1. 网络连接问题网络连接问题是造成YashanDB数据库连接异常的最常见原因之一。在进行排查时，应首先检查服务器是否能通过Ping命令正常访问。 同时，确认数据库服务器与客户端之间的VPN或代理设置是否正确，并验证路由器或交换机的配置是否允许必要的流量通过。2. 数据库配置错误配置错误可能导致数据库无法接受连接。 查阅YashanDB错误日志，记录的时刻进行排查。分析数据库和应用程序的连接池配置，确保合理使用连接资源。结论YashanDB数据库连接异常和故障排查是一项综合性的任务，需要从多个角度进行分析。
29110编辑于 2025-08-15- 来自专栏MCNU云原生
记一次Elasticsearch GeoIpDownloader的启动异常排查排查过程
最近碰到了Elasticsearch GeoIpDownloader相关的一个异常，花费了不少精力排查，故此记录一下，希望碰到同样问题的童鞋们少走弯路。 这个异常是在Elasticsearch启动的过程中报的error，如下所示，从提示信息来看是因为GeoIpDownloader更新数据库失败导致。 ，名为GeoLite2-ASN.mmdb，当重新启动以后程序会自动去更新这个数据库。 这里似乎存在一个状态判断异常的问题。 我在社区留言，官方团队回复： 一、排查是否可能是因为资源不足，例如存储不足； 二、在GeoIpDownloader中有几个已知的竞争条件，在启动/停止的时候可能触发一些意向不想的问题，这些问题目前对集群的运行没有影响
2.2K30编辑于 2023-02-22 - 来自专栏数据之美
CPU 100% 异常排查实践与总结
2、排查思路 2.1 定位高负载进程 pid 首先登录到服务器使用top命令确认服务器的具体情况，根据具体情况再进行分析判断。 ? 可得出结论：该进程对应的就是数据平台的web服务。 3、根因分析 经过前面的分析与排查，最终定位到一个时间工具类的问题，造成了服务器负载以及cpu使用率的过高。 异常方法逻辑：是把时间戳转成对应的具体的日期时间格式； 上层调用：计算当天凌晨至当前时间所有秒数，转化成对应的格式放入到set中返回结果； 逻辑层：对应的是数据平台实时报表的查询逻辑，实时报表会按照固定的时间间隔来 4、解决方案 定位到问题之后，首先考虑是要减少计算次数，优化异常方法。排查后发现，在逻辑层使用时，并没有使用该方法返回的set集合中的内容，而是简单的用set的size数值。
1.6K80发布于 2018-02-24 - 来自专栏RokasYang
CLB健康检查原理及异常排查
七层健康检查，使用HTTP协议，支持GET、HEAD两种请求方法，HEAD只获取头部信息，不获取实际内容，更加轻量的探测，两种方式，都是依赖RS返回的HTTP CODE与设置的健康状态码比对(默认为1xx、2xx 二、四层健康检查 TCP/HTTP 四层监听器的健康检查支持TCP、HTTP、自定义协议三种，其中前两种为主流用法： [2rcuo2xfz3.png] 四层监听器，顾名思义传输层协议，为IP:PORT的探测方式 UDP udp探测分为检查端口和ping探测： [jdyaw1yv7q.png] 1.检查端口的探测逻辑 检查请求、检查返回结果不填写的情况下，当以下两个条件同时满足，则认为健康检查正常，否则异常： Ping 探测正常 UDP探测端口，RS没有回显xxx Port Unreachable 2.指定回显文本的探测逻辑 当检查请求、检查返回结果填写了文本或十六进制，CLB探测时将携带填写的内容去探测RS端口，当RS ] 健康检查置为正常： [ykinms2rcc.png] 三、健康检查异常排查步骤 1.确保安全组、iptables等不会成为阻碍 CLB探测默认会携带自己的VIP去请求RS，如果RS没放通VIP或健康检查端口
2.7K223发布于 2021-08-24 常见java OOM异常分析排查思路分析
内存中缓存过多数据。 解决方案 调整 JVM 堆内存大小（增加 -Xmx 参数）。 优化代码，减少内存消耗。 检查并修复内存泄漏。 Java 堆溢出排查解决思路 1.查找关键报错信息，比如 java.lang.OutOfMemoryError: Java heap space 2.使用内存映像分析工具（如Jprofiler）对Dump 2.线程栈空间不足 (Stack Overflow) 关于虚拟机栈和本地方法栈，在Java虚拟机规范中描述了两种异常： 如果线程请求的栈深度大于虚拟机所允许的深度，将抛出StackOverflowError 异常； 如果虚拟机栈可以动态扩展，当扩展时无法申请到足够的内存时会抛出 OutOfMemoryError 异常。 5.GC 造成的内存不足 (GC Overhead Limit Exceeded) 这种情况发生在垃圾回收频繁且回收效果不明显时（超过98%的时间用来做GC并且回收了不到2%的堆内存时会抛出此异常。）。
65910编辑于 2024-09-06
腾讯云开发者
Copyright © 2013 - 2026 Tencent Cloud. All Rights Reserved. 腾讯云 版权所有
深圳市腾讯计算机系统有限公司 ICP备案/许可证号：粤B2-20090059 
粤公网安备44030502008569号
腾讯云计算（北京）有限责任公司 京ICP证150476号 | 京ICP备11018762号