haoluojie的博客

早上一来公司，质量部小伙伴们就说，后台系统“订单管理模块”无法加载出数据了，不是网络问题不是网络问题！好吧，DBA今日又请假，不能影响大家的测试，赶快排查下原因：1、 查看下日志吧：    进入k8s服务器，既然是订单模块加载数据出问题，那就找到对应的 订单微服务 ：order 服务   ①、 k8s查看 找到我们的order微服务：kubectl get pods -o wide   ②  、 ...

gis项目内存泄漏，OOM原因定位分析：现象：压测10并发，持续3分钟后，AVG>3S,TPS=3，全面监控，各服务器资源及带宽方面方面没瓶颈。监控heap内存回收现象，如图出现每次回收不尽情况，持续压测下，heap内存消耗殆尽，出现内存泄漏，如图：  dump出存活对象，MAT分析内存使用情况及内存泄漏原因，如下占用93%，如图信息 最终原因及优化：查看源代码

xx项目需要做性能测试，开发端主要是netty框架，500并发TPS能达到7000+，但是返回少量 Connection timed out，原因有可能是代码有问题，也有可能仅是客户端主动关闭了连接，导致服务端的写失败，linux服务器本身无法处理如此大量请求，监控到客户端并未有大量CLOSE_WAIT状态，不过大量timewait状态，服务器端linxu内核已做各项参数优化。优化：一是限

转载地址：http://www.cnblogs.com/chenpi/p/5377445.html当我们运行java程序时，发现程序不动，但又不知道是哪里出问题时，可以使用JDK自带的jstack工具去定位；废话不说，直接上例子吧，在window平台上的；死循环写个死循环的程序如下：package concurrency;public

问题：压测公司某业务线接口，TPS最大处理能力20左右，整个服务端资源无任何压力，cpu利用率较低6%，redis QPS较低原因排查：出现此问题，根据经验一般是代码存在死锁导致，jstack查看堆栈信息和查看业务代码。根据业务功能是发表祝福时候会生成一个楼层数据，而生成楼层加了锁，以防止并发导致楼层重复，如图：优化：由获取数据库id加锁改为redis自增获取。优化后，TP

经过对JVM堆内存使用监控，xxxx程序压测过程中yong gc正常，GC比较频繁，如图：如下系统配置参数JAVA_OPTS="-server -Xms256m -Xmx256m -XX:PermSize=64M-XX:MaxNewSize=256m -XX:MaxPermSize=128m"系统分润跑批报：java.lang.OutOfMemoryError：GC

1000并发时候，监控日志出现此问题:java.lang.OutOfMemoryError: unable to create new native thread

1、Java虚拟机运行时的数据区2、常用的内存区域调节参数-Xms：初始堆大小，默认为物理内存的1/64(-Xmx：最大堆大小，默认(MaxHeapFreeRatio参数可以调整)空余堆内存大于70%时，JVM会减少堆直到 -Xms的最小限制-Xmn：新生代的内存空间大小，注意：此处的大小是（eden+ 2 survivor space)。与jmap -heap中显示的New