为什么你的博客访问慢？

　　不知道大家有没有注意到，在22.10.31 21点之后，凯哥的个人访问速度提升了不少。那是因为凯哥对站点做了优化。本文就记录优化方面：

　　优化从以下几个方面入手的：

　　1：JVM调优

　　2：日志打印

　　3：删除已经不用的代码

　　前提条件：

　　凯哥个人博客，是购买阿里云最廉价的机器。配置如下：1C2G1M的共享性。

　　一：JVM调优

　　先来看看优化前凯哥配置的Tomcat启动参数

　　-Xms512m -Xmx512m -Xmn512m -Xss1024K -XX:MaxPermSize=256m -XX:MaxNewSize=256m

　　再来看看修改前服务器情况：

　　是不是很刺激。

　　排查网站访问慢，主要原因是CPU使用率太高了。不小心就100%的使用率。CPU处理不过来,页面可不响应慢吗。

　　这真好是一个CPU占用过高的案例。我们就来讲讲CPU占用过高排查流程吧

　　1：CPU占用过高排查流程

　　1：利用top命令查出CPU最高的进程PID。比如是16379

　　top

　　2：查看该进程下占用最高的线程ID .

　　公式：【top -Hp pid】

　　top -Hp 16379

　　3：根据占用率最高的线程ID。将其转换成16精致形式(因为java native线程以16进制形式书城)

　　公式：【printf '%x\n' 线程id】

　　比如上图占用最高的线程id是16383。所以查看命令：

　　printf '%x\n' 16383

　　4：利用jstack打印出线程调用栈信息。

　　公式：【jstack top最高pid | grep printf出来的十六进制 -A50 --color】

　　jstack 16379 | grep '3fff' -A50 --color

　　可以看到GC相关的线程在runnable。吆西。那我们就来看看GC的情况：

　　从上图，我们可以看到Full GC 还是很频繁啊。

　　我们再来看看JVM调优一些理论知识：

　　低延迟。延迟时间是值STW时间。STW越短，响应时间越好。度量标准是缩短由于垃圾收集引起的停顿时间或完全消除因垃圾收集所引起的停顿，避免应用程序运行时发生抖动。暂停时间越短算法越好。

　　3：MinorGC尽可能多地收集垃圾。这个原则就是MinorGC原则。准守这一原则可以降低应用程序FullGC的发生频率。

　　4：堆大小调整的着手点，分析点：

　　a、统计Minor GC持续时间

　　b、统计Minor GC的次数

　　c、统计Full GC的最长持续时间

　　d、统计最差情况下Full GC评率

　　e、统计GC持续时间和频率对优化堆的大小是主要着手点

　　f、我们按照业务系统对延迟和吞吐量的需求，在按照这些我们可以进行各个区大小的调整

　　g、一般来说吞吐量优先的垃圾回收器：-XX:+UseParallelGC -XX:+UseParallelOldGC.也就是常规的(PS/PO)

　　再来想想什么情况下需要调优？

　　1：老年代(Heap内存)持续上涨达到设置的最大内存值

　　2：Full GC次数频繁

　　3：GC停顿(STW)时间长(超过1S，具体值按照应用场景而定)

　　4：应用出现OOM等内存异常情况

　　5：应用出现堆外内存异常(OutOfDirectMemoryErro)等内存异常(failed to allocate 167777216byte(s) of directmemory. used:1056964615，max:1073741824)

　　6：应用中有使用本地缓存且占用大量内存空间

　　7：系统吞吐量与响应性能不高或下降

　　8：应用CPU占用过高不下或内存占用过高不下

　　额滴乖乖~。上面8种情况，凯哥命中了：1、2、3、7、8。哇嘎嘎。博客响应速度真的有点慢。得好几秒才能响应过来。调优走起：

　　我们先来看看常用的JVM参数：

　　设置JVM对内存的初始化大小和最大大小相关参数：

　　1：-Xms：设置JVM启动时候申请的最小内存。默认是物理内存的1/64

　　2：-Xmx：设置JVM可申请的最大内存。默认为物理内存的1/4。

　　从最小内存到最大内存调整过程：默认当空余堆内存小于40%的时候，JVM会增大Heap到-Xmx指定的大小。这个比例可以通过-XX:MinHeapFreeRation来指定；

　　从最大内存到最小内存调整过程：当空余堆内存大于70%的时候，JVM会减小heap的大小到-Xms指定的大小。这个比例可以通过XX:MaxHeapFreeRation来指定这个比例。

　　正是因为有了这个动态扩/缩容，为了减少JVM的扩/缩容。一般都是设置-Xms的大小等于-Xmx的值

　　线程相关参数：

　　3：-Xss：设置每个线程的堆大小。设置思路：看每个线程大约需要占用多少内存。可能会有多少线程同时运行等

　　年轻代\年老代大小设置相关的

　　4：-XX:NewSize：新生代初始化内存的大小(注意：该值需要小于-Xms的值)

　　5：-XX:MaxnewSize：新生代可悲分配的内存的最大上限(注意：该值需要小于-Xmx的值)

　　6：-Xmn：设置年轻代大小。

　　整个堆大小 = 年轻代大小 + 年老代大小+持久化大小。持久化大小一般规定为64MB。所以增大年轻代后，将会减少老年代的大小。此值对系统性能影响较大。Sun官方推荐配置为整个堆的3/8。

　　年轻代\年老代比例设置

　　-XX：NewRation：设置年轻代(包括Eden和两个Survivor区)与来年代的比值(除去持久化)。

　　-XX：SurvivorRation：设置年轻代中Eden去与Survivor去的大小比值。

　　-XX：MaxPermSize：设置持久代大小

　　--XX：MaxTenuringThreshold 设置垃圾最大年龄。如果设置为0，年轻代对象不经过Survivor区。直接进老年代。

　　再来看看凯哥服务器配置：

　　再来回顾下凯哥Tomcat配置的JVM参数：

　　-Xms512m -Xmx512m -Xmn512m -Xss1024K -XX:MaxPermSize=256m -XX:MaxNewSize=256m

　　根据上面-Xmx的设置来看，凯哥设置的Xms和Xmx应该没问题。但是GC很频繁啊，所以，不能看在上面的-Xmx：设置JVM可申请的最大内存。默认为物理内存的1/4这个来配置。应该配置大一点。

　　而且，凯哥在配置Xss的时候，也配置的有问题。把每个线程堆大小设置成了1M。凯哥服务器内存本来就紧张。而每个线程的大小1M。有点太浪费了。于是凯哥修改Tomcat的JVM参数。如下：

　　-Xms768m -Xmx768m -Xmn512m -Xss128K -XX:MaxPermSize=256m -XX:MaxNewSize=256m

　　启动的时候报错，启动失败。提示 :

　　The stack size specified is too small, Specify at least 228k

　　栈设置的太小了，最小也得228K。

　　-Xms768m -Xmx768m -Xmn512m -Xss228K -XX:MaxPermSize=256m -XX:MaxNewSize=256m

　　修改之后，重启服务后，查看gc日志：

　　可以明显的看到gc的频率下降了。服务启动正常。可以正常访问。

　　二：日志打印

　　当时查看，凯哥服务器的磁盘可以使用的剩下2~3个G了。而且日志文件：

　　磁盘读写延迟时间：

　　磁盘快满了，导致磁盘读写延迟很高。所以，凯哥优化采用的第二种方式就是删除日志文件，释放磁盘空间

　　三：删除已经不用的代码

　　从启动日志中，凯哥看到了还有很多和当前博客不相关的。于是果断删除了一些不用的代码。

　　这些都操作完成之后，服务重启，访问博客。速度有明显的提升。

　　小总结：

　　1：当服务访问速度明显下降后，要及时查看服务器资源情况。看看是cpu高还是内存占用高

　　2：分析JVM的各个参数。在对JVM进行调优前，需要对这些参数有深入理解，以及对当前服务器资源了解。别想凯哥一样，没有考虑当前服务器的资源(-Xss:1M 是之前机器配置的。之前机器性能比这个好)

　　3：要记得给服务器添加打印gc的日志文件。可以通过观察gc的日志文件查看gc频率

　　4：记得服务器磁盘大小也要监控。

　　5：及时删除项目中，已经不再使用的无用代码