问题:发现线上到货单的数量,小于实际到货的数量. 怀疑一些隐藏的条件,将部分唯一码进行了过滤,导致数量变少. 开展了如下的跟踪流程: 1.找到其中一个明细的唯一码 grep 6180e-4b09f pms.log>> tmp1 2.查找出问题的方法所输出的日志 grep purchaseConfirm tmp1 >> tmp2 内容如下: 2017-02-28 16:14:25.040 [DubboServerHandler-10.26.235.193:20885-thread-1…

   为了同学们看起来一目了,特按如下思路进行讲解. 1.出现的场景    2.分析及解决的过程    3.总结 最近公司要使用zookeeper做配置管理(后面简称ZK),然后自己就提前用虚拟机进行了ZK三台集群的搭建.之后开始选择使用zookeeper的java client工具,google了半天,发现了一个很名强大的Apache的Curator工具,很多底层的东西都已经给你封装好了,所以用起来很方便,因为我使用的场景是做配置管理,所以使用Curator的Framework就够了.Cura…

昨晚我正在床上睡得着着的,突然来了一条短信. 啥,线上MySQL死锁了,我赶紧登录线上系统,查看业务日志. 能清楚看到是这条insert语句发生了死锁. MySQL如果检测到两个事务发生了死锁,会回滚其中一个事务,让另一个事务执行成功.很明显,我们这条insert语句被回滚了. insert into user (id, name, age) values (6, '张三', 6); 但是我们怎么排查这个问题呢? 到底跟哪条SQL产生了死锁? 好在MySQL记录了最近一次的死锁日志,可以用命令行…

管道符 | 前面的输出作为后面的输入 grep 可以理解为正则表达式 grep [参数] 文件名 -c 打印符合要求的行数 -v 打印不符合要求的行 -n 在输出符合要求的行的同时连同行号一起输出 -i 忽略大小写 [0-9] ^ grep -c 'root' /etc/passwd grep -nv 'root' /etc/passwd grep '[0-9]' 文件名 grep '^#' -v test.py yhq@yhq-virtual-machine:~$ grep 'r..o' /e…

grep的-A-B-选项详解grep能找出带有关键字的行,但是工作中有时需要找出该行前后的行,下面是解释1. grep -A1 keyword filename找出filename中带有keyword的行,输出中除显示该行外,还显示之后的一行(After 1)2. grep -B1 keyword filename找出filename中带有keyword的行,输出中除显示该行外,还显示之前的一行(Before 1)3. grep -1 keyword filename找出filename中带有k…

grep:正则表达式,文本过滤工具,能够实现以指定的"模式(Pattern)"逐行搜索文件中的内容,并将匹配到的行显示出来. 模式:是由正则表达式的元字符,其他字符组合起来的匹配字符. 每一类正则表达式本身的表达式是需要用户自己去写的,但表达式的元字符都有着固定的或者特定的意义,我们可以根据自己的需要去理解或者组合字符,生成我们需要的模式  -v:显示不被模式匹配到的行,invert-match -i:在做模式匹配的时候不区分大小写ignore-case -o:只显示匹配到的串,而非默…

排查了三四个小时,终于解决了这个GC问题,记录解决过程于此,希望对大家有所帮助.本文假定读者已具备基本的GC常识和JVM调优知识,关于JVM调优工具使用可以查看我在同一分类下的另一篇文章: http://my.oschina.net/feichexia/blog/196575 背景说明 发生问题的系统部署在Unix上,发生问题前已经跑了两周多了. 其中我用到了Hadoop源码中的CountingBloomFilter,并将其修改成了线程安全的实现(详情见:AdjustedCountingBloo…

排查了三四个小时,终于解决了这个GC问题,记录解决过程于此,希望对大家有所帮助.本文假定读者已具备基本的GC常识和JVM调优知识,关于JVM调优工具使用可以查看我在同一分类下的另一篇文章: http://my.oschina.net/feichexia/blog/196575 背景说明 发生问题的系统部署在Unix上,发生问题前已经跑了两周多了. 其中我用到了Hadoop源码中的CountingBloomFilter,并将其修改成了线程安全的实现(详情见:AdjustedCountingBloo…

Linux(2)---记录一次线上服务 CPU 100%的排查过程 当时产生CPU飙升接近100%的原因是因为项目中的websocket时时断开又重连导致CPU飙升接近100% .如何排查的呢 是通过日志输出错误信息: 得知websocket时时重新 连接的信息,然后找到原因 解决了. 当然这里幸好能通过日志大致分析出原因 那么我就在思考如果日志没有告诉任何信息 但线上CPU还是接近100%那么如何排查呢.所以学习了下排查过程. 通过查阅资料并实践后,这里总结了两种办法.第一种博客满天飞的方法…

å. 前言 现在的大部分 Java 应用基本都是通过 Maven 进行组织的,不论是分布式应用还是单体集群应用往往都会通过一个 父 POM 加若干子 POM 完成项目的组织.然而这种多应用多模块的拆分就带来了一个巨大的体力成本 --- 发包 举个例子,说明下为什么会出现这种情况: 上面这个图中有两个应用 portal 和 dump,其中 portal 的四个包是需要对外引用的也就是说 client .domain.common.log 这几个包是两个应用共享的二方包.而共享不可避免的会带来竞争!…