在排除網(wǎng)絡(luò)和環(huán)境配置問題后，如果發(fā)現(xiàn)本地調(diào)試比較快，而部署到服務(wù)器就會(huì)出現(xiàn)卡頓現(xiàn)象，可以檢查下在上傳服務(wù)器時(shí)，是否將連接mysql 的IP改為：localhoast、或者unix_socket 方式連接。

本地調(diào)試需要使用服務(wù)器ip地址!

更改如下：

補(bǔ)充：服務(wù)器響應(yīng)慢問題

一.分析思路

　　1.排除本機(jī)自身原因

　　2.服務(wù)器性能分析

　　3.項(xiàng)目本身分析（不詳細(xì)說）

　　4.虛擬機(jī)分析

　　5.數(shù)據(jù)庫分析

二.詳細(xì)分析方法

1.排除本機(jī)自身原因

可以使用站長工具測(cè)試網(wǎng)站速度。

2.服務(wù)器性能分析

使用top命令查看服務(wù)器的資源使用情況，主要分析CPU和內(nèi)存的使用情況（top 命令是 Linux 下常用的性能分析工具，能夠?qū)崟r(shí)顯示系統(tǒng)中各個(gè)進(jìn)程的資源占用狀況，默認(rèn)5秒刷新一下進(jìn)程列表，所以類似于 Windows 的任務(wù)管理器。）：

第三行顯示的是Cpu的使用情況，詳細(xì)含義如下：

us---用戶空間占用CPU的百分比、sy---內(nèi)核空間占用CPU的百分比、ni---改變過優(yōu)先級(jí)的進(jìn)程占用CPU的百分比、id---空閑CPU百分比、wa---IO等待占用CPU的百分比、hi---硬中斷（Hardware IRQ）占用CPU的百分比、si---軟中斷（Software Interrupts）占用CPU的百分比、st---Steal Time，分配給運(yùn)行在主機(jī)上其它虛擬機(jī)的任務(wù)的實(shí)際CPU時(shí)間，一般只有在虛擬機(jī)OS。

第4行是當(dāng)前的內(nèi)存情況，服務(wù)器總內(nèi)存8054352k，已使用2879468k，剩余5174884k，緩沖265728k。

我個(gè)人的理解是：當(dāng)us的百分比小于50%時(shí)，是不需要去考慮服務(wù)器的配置問題的，如果服務(wù)器的us百分比長時(shí)間在70%以上時(shí)，可以考慮加強(qiáng)服務(wù)器的硬件配置。此外，還需要查看服務(wù)器的網(wǎng)絡(luò)情況，下載一個(gè)大型文件基本就可以確定網(wǎng)絡(luò)情況了。

3.項(xiàng)目本身分析

如果使用JDBC連接池，需要對(duì)連接池的配置進(jìn)行分析（分析線程池的最大數(shù)量和釋放時(shí)間等等）。

這里以C3P0為例，下面是我曾經(jīng)做的一個(gè)項(xiàng)目的配置，如下圖：

這里本來只是本地測(cè)試的配置方案，由于粗心，上線后忘記修改了，當(dāng)多人訪問時(shí)，會(huì)出現(xiàn)等待連接超時(shí)的情況，我們需要根據(jù)項(xiàng)目的實(shí)際情況設(shè)定合適的配置數(shù)據(jù)。

還有可能項(xiàng)目的設(shè)計(jì)方面不合理導(dǎo)致響應(yīng)緩慢，這里就不詳細(xì)說明了。

checkoutTimeout---當(dāng)連接池連接耗盡時(shí)，客戶端調(diào)用getConnection()后等待獲取新連接的時(shí)間，超時(shí)后將拋出SQLException，如設(shè)為0則無限期等待。單位毫秒。默認(rèn): 0 　　

minPoolSize---連接池中保留的最小連接數(shù)，默認(rèn)為：3 　　

maxPoolSize---連接池中保留的最大連接數(shù)。默認(rèn)值: 15 　　

maxIdleTime---最大空閑時(shí)間，設(shè)定時(shí)間內(nèi)未使用則連接被丟棄。若為0則永不丟棄。默認(rèn)值: 0 　　

maxIdleTimeExcessConnections---default : 0 單位 s 這個(gè)配置主要是為了減輕連接池的負(fù)載，比如連接池中連接數(shù)因?yàn)槟炒螖?shù)據(jù)訪問高峰導(dǎo)致創(chuàng)建了很多數(shù)據(jù)連接 ，但是后面的時(shí)間段需要的數(shù)據(jù)庫連接數(shù)很少，則此時(shí)連接池完全沒有必要維護(hù)那么多的連接，所以有必要將斷開丟棄掉一些連接來減輕負(fù)載，必須小于maxIdleTime。配置不為0，則會(huì)將連接池中的連接數(shù)量保持到minPoolSize。為0則不處理　　

acquireIncrement---當(dāng)連接池中的連接耗盡的時(shí)候c3p0一次同時(shí)獲取的連接數(shù)。默認(rèn)值: 3

4.虛擬機(jī)分析

使用top指令查看虛擬機(jī)的內(nèi)存占用情況，有時(shí)候可以發(fā)現(xiàn)雖然虛擬機(jī)占用內(nèi)存的百分比不大卻有明顯的上限值，我們就需要去查看虛擬機(jī)的配置情況。

解決方法（以tomcat為例）：

具體的數(shù)值根據(jù)實(shí)際情況而定。

5.數(shù)據(jù)庫分析（MySql）

數(shù)據(jù)庫的分析內(nèi)容和需要考慮的方面有很多，這里只說本人遇到過的幾種情況：

a.最大連接數(shù)　　　　

show variables like '%max_connections%'; 查看最大連接數(shù)
show status like 'Threads%';當(dāng)前連接的使用情況

Threads_connected---打開的連接數(shù)

Threads_running---這個(gè)數(shù)值指的是激活的連接數(shù)，這個(gè)數(shù)值一般遠(yuǎn)低于connected數(shù)值

如果最大連接數(shù)的值太小可以根據(jù)實(shí)際情況進(jìn)行修改，一般修改為1000即可，設(shè)置方法有兩種：

1.臨時(shí)設(shè)置，重啟服務(wù)后將失效

2.修改數(shù)據(jù)庫配置文件

在/etc/my.cnf 文件的[mysqld]下增減一行：max_connections = 1000

b.超時(shí)控制

mysql存在一項(xiàng)屬性“wait_timeout”,默認(rèn)值為28800秒(8小時(shí))，wait_timeout的值可以設(shè)定，但最多只能是2147483，不能再大了。也就是約24.85天 ，可以通過show global variables like 'wait_timeout';命令來查看。

wait_timeout的含義是：一個(gè)connection空閑超過8個(gè)小時(shí)，Mysql將自動(dòng)斷開該connection，通俗的講就是一個(gè)連接在8小時(shí)內(nèi)沒有活動(dòng)，就會(huì)自動(dòng)斷開該連接。由于dbcp沒有檢驗(yàn)該connection是否有效，用其進(jìn)行數(shù)據(jù)操作便會(huì)出現(xiàn)異常。

如果是由超時(shí)控制引起的問題，不建議修改wait_timeout的值，在數(shù)據(jù)庫連接的url的后面加上“autoReconnect=truefailOverReadOnly=false”即可解決。

c.DNS反向解析　　

MySQL數(shù)據(jù)庫收到一個(gè)網(wǎng)絡(luò)連接后，首先拿到對(duì)方的IP地址，然后對(duì)這個(gè)IP地址進(jìn)行反向DNS解析從而得到這個(gè)IP地址對(duì)應(yīng)的主機(jī)名。用主機(jī)名在權(quán)限系統(tǒng)里面進(jìn)行權(quán)限判斷。反向DNS解析是耗費(fèi)時(shí)間的，有可能讓用戶感覺起來很慢。甚至有的時(shí)候，反向解析出來的主機(jī)名并沒有指向這個(gè)IP地址，這時(shí)候就無法連接成功了。 可以在配置文件里面禁止MySQL進(jìn)行反向DNS解析，只需在my.cnf的[mysqld]段落中加入如下行即可：

skip-name-resolve (windows與linux下一樣的)

d.表高速緩存

show global status like 'open%tables%';查看打開的表的數(shù)量：

open_tables是當(dāng)前在緩存中打開表的數(shù)量。　　

opened_tables是mysql自啟動(dòng)起，打開表的數(shù)量。　　

當(dāng)Opened_tables數(shù)值非常大，說明cache太小，導(dǎo)致要頻繁地open table，可以查看下當(dāng)前的table_open_cache設(shè)置：　　show variables like 'table_open_cache'; 查看緩存的上限值

設(shè)置table_open_cache的值有兩種方式(如果是4G左右內(nèi)存的服務(wù)器,建議設(shè)為2048):

1.臨時(shí)設(shè)置，重啟服務(wù)后將失效

set global table_open_cache=2048;

2.修改數(shù)據(jù)庫配置文件

在/etc/my.cnf 文件的[mysqld]下增減一行：table_open_cache = 2048

e.慢查詢?nèi)罩?/h4>

記錄的慢查詢?nèi)罩镜哪康氖谴_認(rèn)是否是由于某些語句執(zhí)行緩慢而導(dǎo)致的服務(wù)器響應(yīng)慢。

慢查詢就不詳細(xì)說了，網(wǎng)上可以查到很多。

以上為個(gè)人經(jīng)驗(yàn)，希望能給大家一個(gè)參考，也希望大家多多支持腳本之家。如有錯(cuò)誤或未考慮完全的地方，望不吝賜教。

您可能感興趣的文章:

• Python查詢oracle數(shù)據(jù)庫速度慢的解決方案
• 解決Python訪問MySQL數(shù)據(jù)庫速度慢的問題
• 解決python存數(shù)據(jù)庫速度太慢的問題