jvm异常排查

线上数据异常引发的崩溃排查记录

线上数据异常的崩溃，最大的关键是还原线上数据 一个崩溃的引申 最新版本，线上报了一个崩溃，崩溃堆栈如下 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，所以知道了具体哪个商品导致的崩溃了 排查异常数据 知道某个商品有异常后，模拟请求该商品数据，发现该商品返回的阶梯价逻辑上不合理，最大购买数量超过了跟阶梯价最大量 问题得以定位，接下来跟后端伙伴反馈该问题，等后端修复上线后，可以线上直接修复该问题，

排查云镜异常

排查云镜异常，可以收集云镜日志让售后看下C:\Program Files\QCloud\YunJing\log复制该目录，对复制后的目录进行压缩，压缩成.7z格式（压缩率高，压缩文件小，方便传输）云镜的

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 熔断器熔断。

异常排查_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）在账单概览控制台查看费用趋势，确认费用上涨的产品。 排查方法-------通过明细账单自助排查 1）按量结算：这个小时收取上个小时的使用费用，第二天收取前一天的使用费用。因此在销毁资源的这个时间段，也会计入使用周期，进行结算扣费。 排查方法---通过明细账单和点播产品计费文档自助排查 1）产品日结后付费，将于每日12:00 - 18:00，对前一日实际用量所产生的费用进行结算，所以可以通过明细账单查看扣费时间对应的使用时间。 总结 账号产生莫名扣费时，可以先通过收支明细和账单查看扣费产品及扣费时间，然后通过对应扣费产品的计费文档了解扣费规则，自助排查扣费是否属于异常情况。

SocketException：Connection reset 异常排查

长连接中，向server发请求，是先发送数据的，如果连接断开，应该是写数据异常，为什么是读数据异常呢？请求是否发送成功？发送之前有校验连接是否可用吗？ 该异常在客户端和服务器端均有可能发生，引起该异常的原因有两个，第一个就是如果一端的Socket被关闭（或主动关闭或者因为异常退出而引起的关闭），另一端仍发送数据，发送的第一个数据包引发该异常(Connect 在第4个异常的第一种情况中（也就是抛出SocketExcepton:Connect reset by peer:Socket write error后），如果再继续写数据则抛出该异常。 - http-outgoing-766 >> "[\r][\n]" 接收相应数据时，出现I/O异常，关闭连接，并向上抛出异常。 (org.apache.http.wire:?) 现在可以回答前面的问题 长连接中，向server发请求，是先发送数据的，如果连接断开，应该是写数据异常，为什么是读数据异常呢？请求是否发送成功？发送之前有校验连接是否可用吗？

线上服务负载异常排查

前言 除了解决业务Bug之外，工作中通常我们还会面临两类问题： 线上服务负载异常，比如CPU负载异常飙高 线上服务内存持续增长，存在泄漏 一般我们会通过各种监控、报警系统，发现和定位问题，关于如何搭建服务监控可以参考之前的文章 所以今天就来看看这种情况下，如何定位服务负载异常的原因。 首先关于「负载异常」的问题，大都肯定都知道使用top或者htop等命令定位到某个进程或线程，好，问题来了： 如何定位到是哪个具体的函数导致的服务负载异常呢？

生产环境NoHttpResponseException异常排查记录

生产环境发现的问题 1、NoHttpResponseException导致退款失败 功能上线后，我便开始监控B端支付模块的交易数据，前两天的数据并没有什么异常，支付完成的订单都已经退款完成。 然后在第三天快下班时，我又统计了一遍数据，发现竟然存在一笔没退款的订单，我整个人一下子就支棱了起来（不会又写了个Bug吧~），我先在数据库中查到订单号，然后找运维同事拿了一下日志，发现支付回调是正常的， 排查到这里基本已经可以确定不是支付模块这边的问题了，但问题毕竟还是要解决的，于是我联系了C端的同事，暂时先通过接口的方式把消费者的钱进行退款。 然后开始排查C端系统的问题，通过C端的日志发现，在请求支付模块进行退款时存在一个异常信息，报错信息如下 ? ，服务端响应RST包导致此异常情况的发生。

邮件服务器异常排查

首先邮件发送的过程中，需要解析“收件人的域名”的MX与A记录，下面是测试这2个记录的步骤。

Java服务异常排查定位大图

引言 研发工程师日常的工作除了开发实现新需求之外，排查定位问题也是重要的组成部分。 因此本文主要聚焦日常工作中经常遇到的异常场景，梳理了问题排查定位的思路大图，这样大家在实际项目中如果遇到类似的异常场景，可以按照思路大图进行问题排查定位解决，相信大家掌握了故障定位的分析套路之后就可以做到遇到问题时临危不乱 其中代码Bug为主要原因，因此在我们实际写代码的过程中就需要考量内存占用的问题，特别是对于一些递归操作、服务内一次缓存大量数据、在for循环中查询数据等都要特别注意或者避免。 因此分析排查定位过程也是主要从这两方面出发，服务自身问题主要包括代码Bug、系统资源异常使用等，依赖方主要包括依赖的中间件、下游服务接口等。 同时结合实际的经验提炼了各个异常情况下的问题根因分析思路以及排查定位大图，大家在遇到类似问题的时候可以参考大图中的思路进行问题排查定位以及解决。 END

实用技巧：排查数据异常数据波动问题，该如何下手？

大多数的服务故障都有较为直观的异常日志，再结合产品表象，相对排查起来还有迹可循，但数据异常的原因就太多了，很多时候连报错日志都没有，排查起来简直无从下手。 本来一切都很美好，但是在排查一些数据异常类问题时却遇到了麻烦！业务的底层逻辑错综复杂，一个接口的响应需要经过三四个微服务的协同处理这非常正常，甚至涉及七八个以上的微服务都不罕见。 行业目前的现状如果自身服务有异常日志，一眼就能确认问题还好说，但如果自身服务一切正常，那排查起来可得费老大劲了。这种数据异常问题，往往是突然发生，打你一个措手不及。 用一句话评价它在排查数据异常类问题的使用体验，那就是：简单、简单、你未曾体验过的简单！ 如何使用XL-LightHouse排查数据异常类问题？归根到底是一句话：在任何你有需要的地方加上流式统计。

CLB健康检查异常排查流程

四层转发健康检查 四层转发的健康检查机制由负载均衡器向配置中指定的服务器端口发起访问请求，如果端口访问正常则视为后端服务器运行正常，否则视为后端服务器运行异常。 _2xx、http_3xx、http_4xx和 http_5xx 这几种，用户可以根据业务需要编辑http_1xx及http_2xx为服务正常状态，并设置http_3xx至http_5xx的返回值代表异常状态 来探测，也加入了DFW白名单（即不受客户安全组限制，但是受iptable限制） 2.公网CLB 探测源是CLB的VIP，需要用户的机器放通vip（受客户安全组限制而且受iptable限制） 健康检查异常排查 了解了健康检查的原理，下面就介绍一般排查健康检查的一些思路。 详细内容可以参见本人写的另一篇文档 《玩转CVM之tw_reuse和tw_recycle》 如果以上都排查没有问题，但健康检查还异常，请联系腾讯云售后人员进一步排查。

Linux 系统出现异常排查思路

16 系统出现异常排查思路 16.1 查看用户信息 16.1.1查看当前的用户 # who 04:39:39 up 1:30, 1 user, load average: 0.01, 0.01, IO-APIC-edge 8: 1 IO-APIC-edge rtc0 9: 0 IO-APIC-fasteoi acpi 查看链接数据库的信息

快速解决YashanDB数据库连接异常及故障排查指南

在现代企业中，数据库的高可用性和稳定性至关重要。然而，在复杂的技术环境中，数据库连接异常已成为众多企业面临的共同挑战。这些异常可能源于网络问题、数据库配置错误、权限设置错误或系统资源不足等多种因素。 因此，对于运维人员而言，及时、高效地排查和解决这些连接异常，不仅有助于提高系统的可用性，也可以避免潜在的业务损失。 本文旨在提供有效的YashanDB数据库连接异常排查策略，从而帮助技术团队更好地定位并解决相关问题。YashanDB数据库连接异常排查的核心技术点1. 网络连接问题网络连接问题是造成YashanDB数据库连接异常的最常见原因之一。在进行排查时，应首先检查服务器是否能通过Ping命令正常访问。 查阅YashanDB错误日志，记录的时刻进行排查。分析数据库和应用程序的连接池配置，确保合理使用连接资源。结论YashanDB数据库连接异常和故障排查是一项综合性的任务，需要从多个角度进行分析。

记一次Elasticsearch GeoIpDownloader的启动异常排查排查过程

最近碰到了Elasticsearch GeoIpDownloader相关的一个异常，花费了不少精力排查，故此记录一下，希望碰到同样问题的童鞋们少走弯路。 这个异常是在Elasticsearch启动的过程中报的error，如下所示，从提示信息来看是因为GeoIpDownloader更新数据库失败导致。 ，名为GeoLite2-ASN.mmdb，当重新启动以后程序会自动去更新这个数据库。 这里似乎存在一个状态判断异常的问题。 我在社区留言，官方团队回复： 一、排查是否可能是因为资源不足，例如存储不足； 二、在GeoIpDownloader中有几个已知的竞争条件，在启动/停止的时候可能触发一些意向不想的问题，这些问题目前对集群的运行没有影响

CPU 100% 异常排查实践与总结

2、排查思路 2.1 定位高负载进程 pid 首先登录到服务器使用top命令确认服务器的具体情况，根据具体情况再进行分析判断。 ? 可得出结论：该进程对应的就是数据平台的web服务。 3、根因分析 经过前面的分析与排查，最终定位到一个时间工具类的问题，造成了服务器负载以及cpu使用率的过高。 异常方法逻辑：是把时间戳转成对应的具体的日期时间格式； 上层调用：计算当天凌晨至当前时间所有秒数，转化成对应的格式放入到set中返回结果； 逻辑层：对应的是数据平台实时报表的查询逻辑，实时报表会按照固定的时间间隔来 4、解决方案 定位到问题之后，首先考虑是要减少计算次数，优化异常方法。排查后发现，在逻辑层使用时，并没有使用该方法返回的set集合中的内容，而是简单的用set的size数值。

CLB健康检查原理及异常排查

UDP udp探测分为检查端口和ping探测： [jdyaw1yv7q.png] 1.检查端口的探测逻辑 检查请求、检查返回结果不填写的情况下，当以下两个条件同时满足，则认为健康检查正常，否则异常： Ping 2115,fork exec:'/bin/cat' [qhs0lingid.png] RS上抓包： [po851zi2an.png] 健康检查置为正常： [ykinms2rcc.png] 三、健康检查异常排查步骤

常见java OOM异常分析排查思路分析

Java 虚拟机（JVM）发生 OutOfMemoryError（OOM）异常时，表示 JVM 在尝试分配内存时无法找到足够的内存资源。以下是几种常见的导致 OOM 异常的情况： 1. 内存中缓存过多数据。 解决方案 调整 JVM 堆内存大小（增加 -Xmx 参数）。 优化代码，减少内存消耗。 检查并修复内存泄漏。 Java 堆溢出排查解决思路 1.查找关键报错信息，比如 java.lang.OutOfMemoryError: Java heap space 2.使用内存映像分析工具（如Jprofiler）对Dump 异常； 如果虚拟机栈可以动态扩展，当扩展时无法申请到足够的内存时会抛出 OutOfMemoryError 异常。 最终，可能会导致内存耗尽，抛出 OutOfMemoryError 异常。

CDN资源访问异常排查思路与方法

如果使用了CDN，有用户反馈访问不了某URL，可通过以下方法进行检查： 1.获取异常URL和节点IP(玩家侧获取) --windows下获取节点IP --苹果ios下获取节点IP --手机安卓系统下获取节点 ----------------------------------------------------------------------------------------------- 1.获取异常 在管理中心上查询是否为腾讯云节点IP image.png https://console.cloud.tencent.com/cdn/inspect/ip 如果不是这边节点IP，那么可能是您的域名解析有问题，或者是运营商侧解析异常 如果您配置正确，运营商在该地区解析异常，提供您的外网IP地址，和外网的DNS地址(可在ping.huatuo.qq.com查看)，发邮件到cncert@cert.org.cn，向国家互联网应急中心投诉。