一次jdk1.7升級jdk1.8後致使redis運行時blocked_clients過多問題解決

公司有個採集項目，由於請求量較大，添加了redis集羣，而且升級了原有的jdk1.7到jdk1.8版本，以後問題就出來了。

1.程序運行一段時間就自動中止，必須重啓才能再次運行。

2.redis鏈接監控查看，有大量鏈接阻塞，致使redis數據處理極慢，甚至不處理請求。

 

通過一段時間的排查才發現問題的關鍵——JDK啓動參數設置問題

原jdk1.7啓動設置爲：

java -jar -server -Xmx1024m -Xms1024m -Xmn256m
-Xss256k -XX:PermSize=128m /opt/source/crawler-storage/dev.crawler.storage1.jar > /opt/source/crawler-storage/info.out &

 

問題就發生在標紅位置，升級爲jdk1.8後仍是使用了這個啓動參數，致使問題出現。

修改後jdk1.8啓動參數後問題解決，其餘參數也有修改，可是主要仍是這個永久代參數

/opt/jdk-1.8/jdk1.8.0_191/bin/java -jar -server -Xmx1024m -Xms1024m -Xmn256m -Xss256k -XX:MetaspaceSize=128m -XX:MaxMetaspaceSize=256m -XX:SurvivorRatio=8 -XX:+UseConcMarkSweepGC
/opt/source/crawler-storage/dev.crawler.storage1.jar > /opt/source/crawler-storage/info.out &

 

 

JDK內存
jdk內存實際是jvm內存，jvm有一個運行時數據區，其實就是對這一部分的大小分配。

運行時數據區一般包括這幾個部分：程序計數器(Program Counter Register)、Java棧(VM Stack)、本地方法棧(Native Method Stack)、方法區(Method Area)、堆(Heap)

　　Xss：每一個線程的stack大小（棧）
　　Xmx：JAVA HEAP的最大值、默認爲物理內存的1/4
　　Xms：JAVA HEAP的初始值，server端最好Xms與Xmx同樣
　　Xmn：JAVA HEAP young區的大小
　　XX:PermSize：設定內存的永久保存區域
　　XX:MaxPermSize：設定最大內存的永久保存區域

在JDK1.8中，取消了PermGen，取而代之的是Metaspace，因此PermSize和MaxPermSize參數失效，取而代之的是

-XX:MetaspaceSize=64m -XX:MaxMetaspaceSize=128m

 

修改JDK內存
linux下：在tomcat的bin目錄下編輯catalina.sh
cygwin=false上面加入

JAVA_OPTS="-Xms1024m -Xmx1024m -Xss1024K -XX:MetaspaceSize=512m -XX:MaxMetaspaceSize1024m"