nf_conntrack (在老版本的 Linux 内核中叫 ip_conntrack )是一个内核模块，用于跟踪一个网络连接的状态 一旦内核 netfilter 模块 conntrack 相关参数配置不合理，导致 nf_conntrack table full ，就会出现丢包、连接无法建立的问题
在排查网络问题时，我们还经常碰到的一个问题，就是内核线程的 CPU 使用率很高。比如，在高并发的场景中，内核线程 ksoftirqd 的 CPU 使用率通常就会比较高。回顾一下前面学过的 CPU 和网络模块，你应该知道，这是网络收发的软中断导致的。 要分析 ksoftirqd 这类 CPU 使用率比
# 背景 我前面写了几篇文章，讲c3p0数据库连接池发生了连接泄露，但是随机出现，难以确定根因，最终呢，为了快速解决问题，我是先写了个shell脚本，脚本主要是检测服务的接口访问日志，看看过去的30s内是不是接口几乎都超时了，如果是的话，咱们就重启服务。然后把这个shell加入到了crontab里，
# 背景 最近，负责基础设施的同事，要对一批测试环境机器进行回收，回收就涉及到应用迁移，问题是整个过程一团乱。比如服务器A上一堆应用要调用服务器B上一堆服务，结果服务器B被回收了，然后服务器A上一堆应用报错。 今天就是负责查一个问题，app上一个头像上传的接口，之前都好好的，不知道怎么就不能访问了，
# 背景 上周都是查测试环境的问题，比如，我上一篇写的[问题排查：nginx的反向代理感觉失效了一样 ](https://www.cnblogs.com/grey-wolf/p/17655238.html)，就是说这个事的。在文章里，最终查到是nginx的全连接队列满了（每个监听端口有个队列，完成三
一次排查某某云上的redis读超时经历 性能排查，服务监控方面的知识往往涉及量广且比较零散，如何较为系统化的分析和解决问题，建立其对性能排查，性能优化的思路，我将在这个系列里给出我的答案。 问题背景 最近一两天线上老是偶现的redis读超时报警，并且是业务低峰期间，甚是不解，于是开始着手排查。 以下
问题排查 应用程序不在接收新请求 关键词：springboot，jstack，Arthas 问题描述 查看前端网页，发现所有请求都pending，都超时。但是查看后端程序发现并没有挂掉，cpu，内存都正常。但是日志不打印了。看起来应用程序整体卡死了。 然后重启应用程序，发现又能正常运行了，但是过了半
小编工作中负责业务的一个服务端系统，使用了 Elasticsearch 服务做数据存储，业务运营人员反馈，用户在使用该产品时发现，用户后台统计的订单笔数和导出的订单笔数不一致！对此进行排查并进行总结
前言 自己个人兴趣爱好，线上有一个阿里云服务器，处理数据用的，会频繁IO和分析数据。隔一段时间就会卡死（大概2个月），重启就OK。本来没当一回事，直到后来影响到赚取money了才引起重视。服务的启动脚本如下： nohup java -Xms512m -Xmx1024m -jar xxx.jar &
前言 日常Bug排查系列都是一些简单Bug的排查。笔者将在这里介绍一些排查Bug的简单技巧，同时顺便积累素材。 Bug现场 线上连续两天出现NP异常，而且都是凌晨低峰期才出现，在凌晨的流量远没有白天高峰期大。而出问题的接口又是通常的业务请求。于是，很自然的，我们就想凌晨有什么特殊的运维动作，翻了下时
日常Bug排查-MVCC和for update混用导致读数据不一致 前言 日常Bug排查系列都是一些简单Bug的排查。笔者将在这里介绍一些排查Bug的简单技巧，同时顺便积累素材。 Bug现场 又是喜闻乐见的读数据不一致的问题。这次的问题是这样，业务在一个事务中更新A和B两个表的两个数据。但是在另一个
日常Bug排查-偶发性读数据不一致 前言 日常Bug排查系列都是一些简单Bug的排查。笔者将在这里介绍一些排查Bug的简单技巧，同时顺便积累素材。 Bug现场 业务场景 先描述这个问题出现的业务场景。这是一个支付的场景，如果支付成功了，我们就把支付状态置为success(主单据更新)同时写入支付成功
日常Bug排查-连接突然全部关闭 前言 日常Bug排查系列都是一些简单Bug的排查。笔者将在这里介绍一些排查Bug的简单技巧，同时顺便积累素材。 Bug现场 最近碰到一个问题，一台机器上的连接数在达到一定连接数(大概4.5W)连接数之后会突然急速下降到几百。在应用上的表现就是大量的连接报错，系统失去
glide是一款非常优秀的图片加载框架，目前很多项目在使用。提供了非常方法，在此，笔者就不一一列举了，可以到官网查找。 目前项目在做内存排查，因为是车机项目，之前开发的时候没有注意内存方面的问题（车机项目你懂的），现在ota期间系统提出让我们优化内存，说出现过应用内存一直增加的情况。 一脸懵逼，第一
刚修改的服务，推到开发环境之后，总是时不时的崩溃，但是不知道为什么。尝试找到他的最后一次调用，也没有复现。 没有办法，只能抓dump了。 开启崩溃自动dump，网络上很多，不赘述了。 拿到dump之后，首先看看是什么类型的异常 如图所示，是个栈溢出的异常。 打印一下堆栈，发现密密麻麻的全是这个代码。
新买了一个Macbook Pro . 之前的工程搬家过来， 这天要跑个单元测试。 发现Junit4 一直处于运行中。没有错误信息，没有用例执行结果。遂开始排查原因。 这里插一句，苹果芯片的Mbp还是很好用的，除了性能够用之外，最主要是安静+不热。 这对比我之前的i7版本的真是太明显了。 之前的i7在
1. 背景 推荐系统的推荐请求追踪日志，通过ELK收集，方便遇到问题时，可以通过唯一标识sid来复现推荐过程 最近在碰到了几个bad case，需要通过sid来查询推荐日志，但发现部分无法在kibana查询到 2. 分析 推荐日志的整个收集流程如下： flowchart LR 线上机器日志 -->
1. 背景 另外一个推荐系统的推荐请求追踪日志，通过ELK收集，方便遇到问题时，可以通过唯一标识sid来复现推荐过程 在一次上线之后，发现日志大量缺失，缺失率达90%，确认是由上线引起的，但因为当时没立即发现这个问题，所以没有通过回滚解决 上线的内容改动了推荐请求日志，数据格式未变，增加了单条日志的
https://www.jianshu.com/p/d0dff28a4cce 一次艰难的内存泄露排查 现象 2019.4.26 22:00左右，通过jstat -gcutil pid 5000 ,发现fgc次数很多而且频繁，此时老年代占比已经大约70%左右，且已经回收不了内存，我们这边设置的fgc阈
https://www.modb.pro/db/79444 霸爷博客，干货满满。有两篇文章现在还记得，《Linux下如何知道文件被哪个进程写》[1]和《巧用Systemtap注入延迟模拟IO设备抖动》[2]，周末突然想起来，发现能看懂了:) 本文虽然说是小技巧，可是难度一点也不低 ^_^ 什么是 s
