zhangzhen02的博客

1.如果存在多个war包程序，开启并行加载在server.xml中 Host部分加入startStopThreads="0"<Host name="localhost" appBase="webapps" unpackWARs="true" autoDeploy="true" startStopThreads="0">tomcat 不设置此值的话，默认单线程加载。设置为0，tomcat会获取当前cpu核心数，使用该值作为多线程数，进行并行加载。实测大大提高部署

今天发现一个服务在新环境中特别卡，经过排查，定位到InetAddress.getLocalHost()引起的，其中调用了native方法去获取本机的hostname,Ip等信息，如果本机配置的resolv.conf文件有问题的话，就有可能会卡住。测试办法，在服务器上查看本机hostnamehostname -i该方法如果特别卡，那么java InetAddress.getLocalHost()方法就会同样卡住。这是一个DNS客户机配置文件，用户配置DNS服务器地址。改为配置一个能够使用的地址即可了

一，将dump文件下载到本地二，使用jhat生成分析页面，jhat ./dump.hprof三，打开页面浏览器打开页面http://localhost:7000/四，拉到最下面，点击instance count of classes可以看到bson相关有几十万个实例alarmMessage有十几万个实例，那么问题逐渐明了了。五，...

一，是什么是逃逸分析？逃逸分析是分析指针可以存储的所有地方，用于判断指针是否能确保在当前线程。我理解的就是用来分析，一个对象是否仅在某个线程被访问到。二，为什么要进行逃逸分析？在JIT时，进行逃逸分析后，就可以确定对象仅在某一线程中被访问到，这样JIT就可以对其方法进行优化。包括：1.堆分配转化为栈分配2.锁消除3.分离对象或标量替换具体方式见下文。三，判断逃逸的标准有哪些？1.对象被赋值给堆中的变量或者类的静态变量2.对象被传进了不确定的代码中运行下面举几个例子public c

explain 可以用来分析该条Sql被执行的情况，是sql优化的必备技能。有哪些字段各个字段的含义id这个字段我用来确定执行的顺序。存在多条时，按数字从大到小执行。同样的数字，由上向下执行。select_type这个字段用来表示该条是一个什么类型的，主查询，子查询等。A：simple：表示不需要union操作或者不包含子查询的简单select查询。有连接查询时，外层的查询为simple，且只有一个。B：primary：一个需要union操作或者含有子查询的select，位于最外层的单位

基础的用户服务需要进行线上压测，但是这个项目的接口数400+，目前没有流量录制的功能，完成400+个接口的脚本编写和数据准备工作量是巨大的需要从400+接口中挑选部分接口150+进行性能压测，那如何选择哪些接口进行压测呢？如果根据线上请求量top150个接口，但是有些接口比如参数是list格式，虽然是少量的请求，但是依然可能会对服务器造成很大的压力甚至是雪崩根据性能测试的经验，梳理了一些规则如下：1.请求tps中top50的接口需要重点关注请求量高的接口2.涉及写操作的接口写操作比较容易

一，先搭建jmeter服务器，安装本地jmeter,本文不赘述。二，在远程jmeter 下生成 jkscd /apache-jmeter-5.2.1/bin/./create-rmi-keystore.sh将生成的rmi_keystore.jks 下载到本地说明1:下载可以使用sz命令，在iterm下需要安装trigger说明2:sz命令，在expect 命令下不起作用，所以要手动s...

压测时，并发量提高后，发现如下报错：进行以下操作进行解决：1.使用以下命令增加本地端口范围：echo 1024 65000 > /proc/sys/net/ipv4/ip_local_port_range此命令用户增大本地可用的端口数目2.开启tcp_tw 快速回收sudo sysctl -w net.ipv4.tcp_tw_recycle =13.开始tcp_tw重用...

压测中TPS上不去的原因：1、网络带宽在压力测试中，有时候要模拟大量的用户请求，如果单位时间内传递的数据包过大，超过了带宽的传输能力，那么就会造成网络资源竞争，间接导致服务端接收到的请求数达不到服务端的处理能力上限。2、连接池可用的连接数太少，造成请求等待。连接池一般分为服务器连接池（比如Tomcat）和数据库连接池（或者理解为最大允许连接数也行）。（关于连接池的具体内容，可参考之前的博...

测试说，网站页面突然很卡。首先kubernates集群没有报警，集群资源cpu，内存使用也还算正常。然后查看jvm，发现并没有大量的full gc。确切的说，近期连一次full gc都没有发生。那么说明，不是pod问题，不是jvm的gc引起的。再然后排查数据库连接，通过druid查看，发现sql也没有什么问题。看起来一切都是这么安好。。。转念一想，既然服务都如此正常，会不会是网络资源问题...

本地原始效果吞吐量在10左右，平均响应时长5000ms左右。（机器配置，32g,8核）经代码优化，主要有以下手段，1.减少服务间的调用请求，2.数据加缓存代码优化后的效果，吞吐量提升了4倍，响应时间减少了75%放到线上后查看效果，没想到，差到爆，吞吐量1.9/s,平均相应时间28.9s。无法忍受。1.原始结果3.查看系统jvm，发现 cpu跑满.于是判断，本接口用到jwt...