The last packet successfully received from the server was 900,045 milliseconds ago.

• 異常信息

2018-12-12 21:57:07.034 8084 --- [SimpleAsyncTaskExecutor-3130] com.alibaba.druid.pool.DruidDataSource : discard connection
com.mysql.jdbc.exceptions.jdbc4.CommunicationsException: Communications link failure

The last packet successfully received from the server was 900,045 milliseconds ago.  The last packet sent successfully to the server was 900,044 milliseconds ago.
        at sun.reflect.GeneratedConstructorAccessor111.newInstance(Unknown Source)
        at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
        at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
        at com.mysql.jdbc.Util.handleNewInstance(Util.java:411)
        at com.mysql.jdbc.SQLError.createCommunicationsException(SQLError.java:1121)
        at com.mysql.jdbc.MysqlIO.reuseAndReadPacket(MysqlIO.java:3670)
        at com.mysql.jdbc.MysqlIO.reuseAndReadPacket(MysqlIO.java:3559)
        at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:4110)

• 解決過程

      其實這個問題特別簡單，就是超時了，根據打印的sql記錄，還能顯示出執行插入sql的時候超時了。問題一目瞭然，對於這個模塊來講本質上是循環插入的，可是這樣數據庫的IO操做比較多，因此我就把這一部分整合到一塊兒插入，結果數據量大，插入方法時間執行過長了。

      最簡單的方式
將數據拆分每500條執行一次插入操做，缺點IO操做比較多，沒有從本質解決問題。

• 排查錯誤過程 

先說系統數據庫鏈接這一部分配置 
一、數據庫 
二、mycat 
三、druid 
四、p6sy 

    超時的問題就是上述某一部分或者某幾部分鏈接超時形成，那就逐步排查吧。 
一、p6sy 
先排除p6sy，由於p6sy是將程序中執行的sql規範化，只是對執行sql加工處理，不涉及時間的問題。 
二、Druid數據源 
DruidDataSource配置屬性列表 
https://github.com/alibaba/druid/wiki/DruidDataSource%E9%85%8D%E7%BD%AE%E5%B1%9E%E6%80%A7%E5%88%97%E8%A1%A8 
其中屬性：timeBetweenEvictionRunsMillis，做用是： 
配置間隔多久才進行一次檢測，檢測須要關閉的空閒鏈接，單位是毫秒
Destroy線程會檢測鏈接的間隔時間，若是鏈接空閒時間大於等於 minEvictableIdleTimeMillis 則關閉物理鏈接。系統配置的是28800秒，將其調大後，問題沒有解決，說明不是druid的配置形成的。 
三、Mycat 
這一部分的檢測是直接將mycat換成直連mysql，根據判斷問題是否解決，以驗證是否爲mycat形成的。 
重試，問題依舊沒有獲得解決。 
四、MySQL 
通過上面的排查，能夠得知MySQL的配置限制了程序的運行。查看MySQL的鏈接時間配置。

mysql> show global variables like '
%timeout%';
+----------------------------+-------+
| Variable_name              | Value |
+----------------------------+-------+
| connect_timeout            | 10    |
| delayed_insert_timeout     | 300   |
| innodb_lock_wait_timeout   | 50    |
| innodb_rollback_on_timeout | OFF   |
| interactive_timeout        | 28800 |
| net_read_timeout           | 30    |
| net_write_timeout          | 60    |
| slave_net_timeout          | 3600  |
| table_lock_wait_timeout    | 50    |
| wait_timeout               | 28800 |
+----------------------------+-------+
10 rows in set
mysql>

簡單介紹一下每一個時間表明的意義 
connect_timeout 鏈接超時 mysql鏈接共有6次握手，3次TCP協議這個跟connect_timeout參數沒有關係，另外3次跟connect_timeout參數有關係，該參數主要是爲了防止網絡不佳時應用重連致使鏈接數漲太快，通常默認便可。 
delayed_insert_timeout 這是爲MyISAM INSERT DELAY設計的超時參數，在INSERT DELAY停止前等待INSERT語句的時間 
interactive_timeout 服務器關閉交互式鏈接前等待活動的秒數。交互式客戶端定義爲在mysql_real_connect()中使用CLIENT_INTERACTIVE選項的客戶端。參數默認值：28800秒（8小時） 
lock_wait_timeout 鎖等待超時時間 
net_read_timeout / net_write_timeout 這個參數只對TCP/IP連接有效，分別是數據庫等待接收客戶端發送網絡包和發送網絡包給客戶端的超時時間，這是在Activity狀態下的線程纔有效的參數 
slave_net_timeout 解釋：這是Slave判斷主機是否掛掉的超時設置，在設定時間內依然沒有獲取到Master的迴應就人爲Master掛掉了 
wait_timeout 服務器關閉非交互鏈接以前等待活動的秒數 
分析上面超時時間表明的含義，再根據本身的狀況，修改 
解決方案 
net_read_timeout/net_write_timeout的時間調大，從新測試完美解決！
--------------------- 
做者：Mandy-賈文靜 
來源：CSDN 
原文：https://blog.csdn.net/jiadajing267/article/details/79516989 
版權聲明：本文爲博主原創文章，轉載請附上博文連接！