一.分析思路
1.排除本機自身原因
2.服務器性能分析
3.項目本身分析（不詳細說）
4.虛擬機分析
5.數據庫分析
二.詳細分析方法
1.排除本機自身原因
可以使用站長工具測試網站速度。
2.服務器性能分析
使用top命令查看服務器的資源使用情況，主要分析cpu和內存的使用情況（top 命令是 linux 下常用的性能分析工具，能夠實時顯示系統中各個進程的資源占用狀況，默認5秒刷新一下進程列表，所以類似于 windows 的任務管理器。）：
第三行顯示的是cpu的使用情況，詳細含義如下：
us---用戶空間占用cpu的百分比、sy---內核空間占用cpu的百分比、ni---改變過優先級的進程占用cpu的百分比、id---空閑cpu百分比、wa---io等待占用cpu的百分比、hi---硬中斷（hardware irq）占用cpu的百分比、si---軟中斷（software interrupts）占用cpu的百分比、st---steal time，分配給運行在主機上其它虛擬機的任務的實際cpu時間，一般只有在虛擬機os。
第4行是當前的內存情況，服務器總內存8054352k，已使用2879468k，剩余5174884k，緩沖265728k。
我個人的理解是：當us的百分比小于50%時，是不需要去考慮服務器的配置問題的，如果服務器的us百分比長時間在70%以上時，可以考慮加強服務器的硬件配置。此外，還需要查看服務器的網絡情況，下載一個大型文件基本就可以確定網絡情況了。
3.項目本身分析
如果使用jdbc連接池，需要對連接池的配置進行分析（分析線程池的最大數量和釋放時間等等）。
這里以c3p0為例，下面是我曾經做的一個項目的配置，如下圖：
這里本來只是本地測試的配置方案，由于粗心，上線后忘記修改了，當多人訪問時，會出現等待連接超時的情況，我們需要根據項目的實際情況設定合適的配置數據。
還有可能項目的設計方面不合理導致響應緩慢，這里就不詳細說明了。
checkouttimeout---當連接池連接耗盡時，客戶端調用getconnection()后等待獲取新連接的時間，超時后將拋出sqlexception，如設為0則無限期等待。單位毫秒。默認: 0
minpoolsize---連接池中保留的最小連接數，默認為：3
maxpoolsize---連接池中保留的最大連接數。默認值: 15
maxidletime---最大空閑時間，設定時間內未使用則連接被丟棄。若為0則永不丟棄。默認值: 0
maxidletimeexcessconnections---default : 0 單位 s 這個配置主要是為了減輕連接池的負載，比如連接池中連接數因為某次數據訪問高峰導致創建了很多數據連接 ，但是后面的時間段需要的數據庫連接數很少，則此時連接池完全沒有必要維護那么多的連接，所以有必要將斷開丟棄掉一些連接來減輕負載，必須小于maxidletime。配置不為0，則會將連接池中的連接數量保持到minpoolsize。為0則不處理
acquireincrement---當連接池中的連接耗盡的時候c3p0一次同時獲取的連接數。默認值: 3
4.虛擬機分析
使用top指令查看虛擬機的內存占用情況，有時候可以發現雖然虛擬機占用內存的百分比不大卻有明顯的上限值，我們就需要去查看虛擬機的配置情況。
解決方法（以tomcat為例）：
具體的數值根據實際情況而定。
5.數據庫分析（mysql）
數據庫的分析內容和需要考慮的方面有很多，這里只說本人遇到過的幾種情況：
a.最大連接數
show variables like '%max_connections%'; 查看最大連接數
show status like 'threads%';當前連接的使用情況
threads_connected---打開的連接數
threads_running---這個數值指的是激活的連接數，這個數值一般遠低于connected數值
如果最大連接數的值太小可以根據實際情況進行修改，一般修改為1000即可，設置方法有兩種：
1.臨時設置，重啟服務后將失效
2.修改數據庫配置文件
在/etc/my.cnf 文件的[mysqld]下增減一行：max_connections = 1000
b.超時控制
mysql存在一項屬性“wait_timeout”,默認值為28800秒(8小時)，wait_timeout的值可以設定，但最多只能是2147483，不能再大了。也就是約24.85天 ，可以通過show global variables like 'wait_timeout';命令來查看。
wait_timeout的含義是：一個connection空閑超過8個小時，mysql將自動斷開該connection，通俗的講就是一個連接在8小時內沒有活動，就會自動斷開該連接。由于dbcp沒有檢驗該connection是否有效，用其進行數據操作便會出現異常。
如果是由超時控制引起的問題，不建議修改wait_timeout的值，在數據庫連接的url的后面加上“&autoreconnect=true&failoverreadonly=false”即可解決。
c.dns反向解析
mysql數據庫收到一個網絡連接后，首先拿到對方的ip地址，然后對這個ip地址進行反向dns解析從而得到這個ip地址對應的主機名。用主機名在權限系統里面進行權限判斷。反向dns解析是耗費時間的，有可能讓用戶感覺起來很慢。甚至有的時候，反向解析出來的主機名并沒有指向這個ip地址，這時候就無法連接成功了。 可以在配置文件里面禁止mysql進行反向dns解析，只需在my.cnf的[mysqld]段落中加入如下行即可：
skip-name-resolve (windows與linux下一樣的)
d.表高速緩存
show global status like 'open%tables%';查看打開的表的數量：
open_tables:是當前在緩存中打開表的數量。
opened_tables:是mysql自啟動起，打開表的數量。
當opened_tables數值非常大，說明cache太小，導致要頻繁地open table，可以查看下當前的table_open_cache設置：
show variables like 'table_open_cache'; 查看緩存的上限值
設置table_open_cache的值有兩種方式(如果是4g左右內存的服務器,建議設為2048):
1.臨時設置，重啟服務后將失效
set global table_open_cache=2048;
2.修改數據庫配置文件
在/etc/my.cnf 文件的[mysqld]下增減一行：table_open_cache = 2048
e.慢查詢日志
記錄的慢查詢日志的目的是確認是否是由于某些語句執行緩慢而導致的服務器響應慢。
慢查詢就不詳細說了，網上可以查到很多。
不過，最后，根據我實際的項目分析，這些都沒有問題，是mongodb的cpu直接滿了，注釋掉就好了
以上就是本文的全部內容，希望對大家的學習有所幫助，也希望大家多多支持服務器之家。
原文鏈接：https://www.cnblogs.com/sunxun/p/9603298.html
