- 博客(17)
- 收藏
- 关注
RSS订阅原创 两行代码把CPU使用率干到了90%+
某应用使用schedulerx来做定时任务执行，每隔一小时执行一次，每次执行5分钟左右，执行任务期间CPU使用率90%+。
2024-06-16 15:35:10
795
原创 一次druid数据库连接池连接泄露的排查分析
最近项目组某应用将数据库由Oracle切换到了TBase，遇到了数据库连接泄露导致无法创建新连接的问题，下面是问题的分析过程。
2024-06-12 12:02:13
1186
原创 Tomcat 启动速度慢背后的真相
注意一下，为什么我们这里使用的路径是"/dev/./urandom",而不是 "/dev/urandom",是因为在java 8之前的版本设置了/dev/urandom ，但是实际还是使用/dev/random，设置为"/dev/./urandom"才能正常使用 "/dev/urandom" ， 这个bug在java8版本已经修复了，如果你是java7版本的话，需要按照上面设置，java8的话可以不用加 "./"。总结 tomcat 启动慢的原因是随机数产生遭到阻塞，遭到阻塞的原因是 熵池大小。
2024-06-12 11:57:52
1159
原创 一次JVM堆外内存泄露Bug的查找
JVM的堆外内存泄露的定位一直是个比较棘手的问题。此次的Bug查找从堆内内存的泄露反推出堆外内存，同时对物理内存的使用做了定量的分析，从而实锤了Bug的源头。笔者将此Bug分析的过程写成博客，以飨读者。由于物理内存定量分析部分用到了linux kernel虚拟内存管理的知识，读者如果有兴趣了解请看ulk3(《深入理解linux内核第三版》)查找Bug的时候，现场信息越多越好，同时定位Bug必须要有实质性的证据。例如内存泄露就要用你推测出的模型进行定量分析。
2024-06-09 13:45:33
729
原创 一次完整的JVM堆外内存泄漏故障排查记录
记录一次线上JVM堆外内存泄漏问题的排查过程与思路，其中夹带一些「JVM内存分配的原理分析」以及「常用的JVM问题排查手段和工具分享」，希望对大家有所帮助。在整个排查过程中，我也走了不少弯路，但是在文章中我仍然会把完整的思路和想法写出来，当做一次经验教训，给后人参考，文章最后也总结了下内存泄漏问题快速排查的几个原则。本文的主要内容：」故障描述和排查过程故障原因和解决方案分析JVM堆内内存和堆外内存分配原理常用的进程内存泄漏排查指令和工具介绍和使用。
2024-06-09 11:53:33
1005
原创 JVM性能问题的自动分析
由于许多业务开发人员对虚拟机了解很少，所以通常在遇到一些虚拟机性能问题或故障时，不得不临时抱佛脚，现学现用一些调优工具和排查方法，而这也变成为了一个有门槛，需要付出学习成本的事情，基于这个考虑，我们可以做一些简单的性能自动分析程序，直接或辅助用户快速定位一些性能问题。下面就以虚拟机参数，堆转储文件，线程Dump和GC日志这４种数据源为基础，自动分析应用程序可能出现的问题。
2024-06-08 15:21:01
793
原创 JDK Bug导致线程阻塞案例分析
在某学习APP浏览文章，客户端会将浏览的文章信息上传到服务端，服务端将浏览信息最终存储到HBase；在某学习APP首页点击【我的】->【历史】，会展示用户浏览文章的历史记录。服务端的服务是【阅读历史离线服务】，从metaq消费用户阅读文章的信息，解析、处理相关业务逻辑，最后存储到HBase。
2024-06-08 15:14:45
984
原创 FullGC没及时处理，差点造成大事故
目前的这个场景所涉及到的查询结果数据，被用于数据权限控制，返回的数据变多时造成的问题是，该看到该数据的人可以看到，不该看到该数据的也可以看到。只是串行查询TableStore，虽然会耗内存，但如果正在执行的pod没有其它在执行的耗内存操作，是不会触发FullGC的。想着是两年前的线上代码，code reivew就没有作为重点，具体过程，相关的同学都不记得了。新业务场景是接收到mq消息然后根据条件去触发这段老代码，当同时接收n个消息，则占用的内存*n ，则很容易触发FullGC。那么，测试是通过的。
2024-06-07 12:27:33
1017
原创 记一次服务器被入侵排查
安全问题往往被大家忽视，但它轻则导致公司用户数据泄露引发严重的舆论危机，重则导致数据被破坏导致公司破产，所以安全问题一定要重视，不过这类问题一旦出现，由于大家经验比较少，往往很难入手，今天就给大家带来一篇服务器被入侵的排查思路，相信大家看了肯定有收获！下文中的，给文件和目录加锁，是指给文件和目录增加了一些属性，只读等。chattr +ia。
2024-06-07 12:17:02
1760
原创 YGC问题排查
YGC 在新生代中进行，首先要清楚新生代的堆结构划分。新生代分为Eden区和两个Survivor区，其中Eden:from:to = 8:1:1 (比例可以通过参数 –XX:SurvivorRatio 来设定 )，这是最基本的认识。为什么会有新生代？如果不分代，所有对象全部在一个区域，每次GC都需要对全堆进行扫描，存在效率问题。分代后，可分别控制回收频率，并采用不同的回收算法，确保GC性能全局最优。为什么新生代会采用复制算法？
2024-06-06 12:02:04
571
原创 MQ-消息堆积-业务线程阻塞案例分析
上面图片中，TID=562的线程正在read Oracle返回的信息。应用侧处理MQ消息比较慢，触发了MQ的流控机制（MQ在统计到应用消费慢的时候，会逐步减少给应用侧的消息，最糟糕的情况是MQ一条消息也不会发给应用来消费）。【oracle.jdbc.driver.T4CConnection@31c02e79】是与Oracle交互的数据库连接对象，需要分析出。业务中某个应用在消费MQ的时候，出现部分机器消息堆积，随着时间推移，堆积的机器数量越来越多，消息的堆积总量越来越多。接下来的思路是慢在了哪？
2024-06-06 11:58:46
610
原创 浅析AbstractQueuedSynchronizer
这部分应该算是一个比较重要的地方了。很多的八股文什么的也都会涉猎到这部分，这里我只讨论几个问题：线程获取锁成功失败线程释放锁这也就是AQS的核心问题，我认为也没有必要再去探究更多，将这两个问题讨论清楚，也基本上可以搞清楚AQS了，并且，这里也只讨论独占锁的情况，对于共享锁，在了解了独占锁之后一般也可以做到触类旁通，不再赘述。线程获取锁通常，AQS本身的acquire就是一个获取锁的操作，源码在上文。也copy一下来方便看if (!
2024-06-05 12:54:58
585
1
原创 为什么要做代码Review？
计算机科学中，幂等表示一次和多次请求某一个资源应该具有同样的副作用，或者说，多次请求所产生的影响与一次请求执行的影响效果相同。代码评审的时候，要关注接口是否考虑幂等。比如开户接口，多次请求过来的时候，需要先查一下该客户是否已经开过户，如果已经开户成功，直接返回开户成功的报文。如果还没开户，就先开户，再返回开户成功的报文。这就是幂等处理。
2024-06-05 12:52:23
1766
原创 每秒十万QPS的社交APP 如何优化GC性能提升3倍
1、案例背景本案例的背景是一个有高峰期每秒十万QPS的社交APP，这是我曾经帮助一个朋友的公司处理过的一个JVM优化的案例。大家都知道，其实现在社交APP有很多种，不光是大家熟悉的微信、QQ之类的，还有很多细分领域的明星社交APP，诸如陌生人社交，基于地理位置的社交，等等。其实很多明星创业社交APP产品，也有每日数百万的日活用户，尤其在晚上高峰期的时候，APP的QPS也是很高的。附带一句，可能有的同学不知道QPS是什么，其实英文全称就是“Query Per Second”，也就是每秒钟的查询数量，大致可以理
2022-06-17 16:58:59
850
原创 抢购秒杀场景
1、秒杀场景下的抢购流程分析首先从秒杀活动的场景入手来分析，假设我们每天在晚上8:30都有一个秒杀活动，都会主推一个特别好的商品进行3折限量秒杀抢购，比如一个价值6888的手机就3折出售，而且限量每天100个。那么在这个8:30的时间点之前，实际上大量的用户（可能多达几十万甚至上百万）会集中登录到APP上，然后同时访问这个秒杀活动的商品页面，这个频繁访问商品页面的问题已经被商品技术团队解决掉了。接着就是到8:30之后，一到时间，页面上会让一个立即抢购的按钮变成可以点击的状态，在那之前这个按钮是灰色的，不能
2022-06-17 16:21:47
919
转载 Eureka与ZooKeeper 的比较（转）
Eureka的优势1、在Eureka平台中，如果某台服务器宕机，Eureka不会有类似于ZooKeeper的选举leader的过程；客户端请求会自动切换到新的Eureka节点；当宕机的服务器重新恢复后，Eureka会再次将其纳入到服务器集群管理之中；而对于它来说，所有要做的无非是同步一些新的服务注册信息而已。所以，再也不用担心有“掉队”的服务器恢复以后，会从Eureka服务器集群中剔除出去的风险了。Eureka甚至被设计用来应付范围更广的网络分割故障，并实现“0”宕机维护需求。（多个zookeeper之
2022-04-18 10:43:01
2058
空空如也
空空如也
TA创建的收藏夹 TA关注的收藏夹
TA关注的人