如何排查系統(tǒng)的性能瓶頸點？
不點藍(lán)字，我們哪來故事？
梳理系統(tǒng)的性能瓶頸點這件事應(yīng)該不是一件簡單的事情，需要針對不同設(shè)計的系統(tǒng)來進行單獨分析。
首先一套完整可用的系統(tǒng)應(yīng)該是有ui界面的（這里強調(diào)的是一套完整的，可用的系統(tǒng)，而并不是指單獨的一個中臺系統(tǒng)），系統(tǒng)分為了前端模塊和后端模塊。
這里由于我個人的擅長領(lǐng)域更多是處于后端模塊，所以對于系統(tǒng)的瓶頸點梳理我會從后端進行分析。
這里我結(jié)合常用的nginx+tomcat+redis+mysql這類常見架構(gòu)進行分析：
請求入口 所有的請求打入到后臺的服務(wù)當(dāng)中，首先需要考慮的一個點就是：
帶寬因素：
假設(shè)有200m的流量同時請求進入服務(wù)器，但是帶寬只有1m，這么來算光是接收這批數(shù)據(jù)量信息也要消耗大約200s的時間。帶寬可以理解為在指定時間內(nèi)從一端請求到另一端的流量總量。而且局域網(wǎng)和廣域網(wǎng)的帶寬計算其實也是不一樣的，
服務(wù)器的ulimit
通常我們使用的線上服務(wù)器都是centos系列，這里我列舉centos7相關(guān)的系統(tǒng)配置：ulimit配置 查看服務(wù)器允許的最大打開文件數(shù)目（linux系統(tǒng)中設(shè)計概念為一切皆文件） 通常如果我們的java程序需要增大一些socket的鏈接數(shù)目，可以通過調(diào)整ulimit 里面的open參數(shù)進行配置。
?[root@izwz9ic9ggky8kub9x1ptuz?~]#?ulimit?-a?|?grep?open
open?files??????????????????????(-n)?1000
查看用戶的最大進程數(shù)目
[root@izwz9ic9ggky8kub9x1ptuz?~]#?ulimit?-a?|?grep?user
max?user?processes??????????????(-u)?7284
相關(guān)的配置存放在了/etc/security/limits.conf文件中。
系統(tǒng)的一些內(nèi)核參數(shù)配置
如果是在一些壓力測試場景中，我們通常會預(yù)見到這種報錯：
apr_socket_recv:?Connection?reset?by?peer?(54)
通常這種情況是因為系統(tǒng)內(nèi)部的一些防范參數(shù)設(shè)置導(dǎo)致的，需要調(diào)整/etc/sysctl.conf 文件中的相關(guān)參數(shù)：
net.ipv4.tcp_syncookies?=?0
#當(dāng)并發(fā)請求數(shù)目超過了1000之后，服務(wù)器自身可能會認(rèn)為是收到了syn泛洪攻擊，但對于高并發(fā)系統(tǒng)，要禁用此設(shè)置
?
net.ipv4.tcp_max_syn_backlog
#參數(shù)決定了SYN_RECV狀態(tài)隊列的數(shù)量，一般默認(rèn)值為512或者1024，即超過這個數(shù)量，系統(tǒng)將不再接受新的TCP連接請求，一定程度上可以防止系統(tǒng)資源耗盡?？筛鶕?jù)情況增加該值以接受更多的連接請求。
?
net.ipv4.tcp_tw_recycle
#參數(shù)決定是否加速TIME_WAIT的sockets的回收，默認(rèn)為0。
?
net.ipv4.tcp_tw_reuse
#參數(shù)決定是否可將TIME_WAIT狀態(tài)的sockets用于新的TCP連接，默認(rèn)為0。
??
net.ipv4.tcp_max_tw_buckets
#參數(shù)決定TIME_WAIT狀態(tài)的sockets總數(shù)量，可根據(jù)連接數(shù)和系統(tǒng)資源需要進行設(shè)置。
對于防范參數(shù)還可以如下修改查看：
cd?/proc/sys/net/ipv4
echo?"0"?>?tcp_syncookie
通常企業(yè)中使用的都是nginx進行接收請求，然后進行負(fù)載均衡轉(zhuǎn)發(fā)。在nginx層里面會有幾個核心參數(shù)配置：最大連接數(shù)，最大并發(fā)訪問數(shù)
#指定同一個ip的每次請求數(shù)量都限制為10次
limit_conn_zone?$binary_remote_addr?zone=perip:10m;
limit_conn?perip?10
Tomcat部分分析
Tomcat支持三種接收請求的處理方式：BIO、NIO、APR 。
1、Bio方式，阻塞式I/O操作即使用的是傳統(tǒng)Java I/O操作，Tomcat7以下版本默認(rèn)情況下是以bio模式運行的，由于每個請求都要創(chuàng)建一個線程來處理，線程開銷較大，不能處理高并發(fā)的場景，在三種模式中性能也最低
2、Nio方式，是Java SE 1.4及后續(xù)版本提供的一種新的I/O操作方式(即java.nio包及其子包)，是一個基于緩沖區(qū)、并能提供非阻塞I/O操作的Java API，它擁有比傳統(tǒng)I/O操作(bio)更好的并發(fā)運行性能。tomcat 8版本及以上默認(rèn)nio模式
3、apr模式，簡單理解，就是從操作系統(tǒng)級別解決異步IO問題，大幅度的提高服務(wù)器的處理和響應(yīng)性能， 也是Tomcat運行高并發(fā)應(yīng)用的首選模式。啟用這種模式稍微麻煩一些，需要安裝一些依賴庫， 而apr的本質(zhì)就是使用jni技術(shù)調(diào)用操作系統(tǒng)底層的IO接口，所以需要提前安裝所需要的依賴，首先是需要安裝openssl和apr
tomcat連接參數(shù)調(diào)整
在tomcat中有這么一段經(jīng)典的配置參數(shù)：
"80"?maxHttpHeaderSize="8192"
????maxThreads="4000"?minSpareThreads="1000"?maxSpareThreads="2000"
????enableLookups="false"?redirectPort="8443"?acceptCount="2000"
????connectionTimeout="20000"?disableUploadTimeout="true"?/
maxThreads表示tomcat最多可以創(chuàng)建多少個線程來處理請求。
minSpareThread表示tomcat一開始啟動的時候會創(chuàng)建多少個線程，即使是閑著也會創(chuàng)建。
maxSpareThread表示tomcat創(chuàng)建的最大閑置線程數(shù)目。一旦tomcat創(chuàng)建的線程數(shù)目達(dá)到這個瓶頸，那么就需要進行線程的回收了。
connectionTimeout表示連接的超時時長。
假設(shè)我們同時有1000個請求并發(fā)訪問，但是一臺tomcat的maxThreads只設(shè)置為了500，那么此時就會出現(xiàn)請求擁塞的情況，也就是瓶頸點之一。
Redis部分性能瓶頸分析
一些大key的查詢，導(dǎo)致網(wǎng)絡(luò)出現(xiàn)擁塞情況
例如說往一個list集合中存儲了50m的數(shù)據(jù)，一旦發(fā)生list全量查詢，同時又有其他指令在進行訪問的時候，就容易會導(dǎo)致網(wǎng)絡(luò)堵塞。因為redis的設(shè)計為單線程處理請求，所以其他指令發(fā)送到redis服務(wù)端的時候，都需要等待redis將之前的任務(wù)處理完畢之后才能繼續(xù)執(zhí)行。
線上環(huán)境出現(xiàn)了一些”違規(guī)操作“
比較常見的違規(guī)操作：批量執(zhí)行keys指令
在redis處于高qps的狀態(tài)下，隨意一個keys指令都可能是致命的。keys指令的時間復(fù)雜度是O（n）級別，容易導(dǎo)致一時間系統(tǒng)的卡頓。
內(nèi)存空間不足
當(dāng)redis處于內(nèi)存空間不足的時候，基本就是整個系統(tǒng)處于癱瘓作用。因此我們在對每個存儲在redis中的數(shù)值都需要設(shè)置一個合理的過期時間，以及需要思考存儲數(shù)據(jù)的體積大小。
MySQL部分性能瓶頸分析
通常我們在分析sql查詢方面都容易出現(xiàn)一個誤區(qū)，就是上來直接進行explian分析，但是卻忽略了系統(tǒng)的運作上下文環(huán)境。
假設(shè)有一張t_user表，已經(jīng)存儲了幾千萬的數(shù)據(jù)，并且也對用戶的id進行了索引建立，但是sql執(zhí)行速度依舊是超過1s時長，這個時候就需要換一種思路進行分析了。
例如從表的拆分方面進行思考，是否該對表進行橫向拆分，拆解為t_user_01,t_user_02......
以下是我總結(jié)的一些對于數(shù)據(jù)庫層面可能出現(xiàn)性能瓶頸的幾點總結(jié)：
1.鎖
排查是否會存在鎖表的情況導(dǎo)致數(shù)據(jù)庫響應(yīng)緩慢。
2.sql查詢還有優(yōu)化空間，有待完善
通常我們對于sql的執(zhí)行分析都會使用explain命令進行查看：
這里我貼出了一張關(guān)于explain的常用參數(shù)含義表供大家參考：
3.查詢出的數(shù)據(jù)量過大
例如說一條sql直接查詢了全表的數(shù)據(jù)信息量，直接占滿了網(wǎng)絡(luò)帶寬，因此訪問時候出現(xiàn)了網(wǎng)絡(luò)擁塞。
4.硬件設(shè)備不足
例如在面對一些高qps的查詢時候，數(shù)據(jù)庫本身的機器硬件配置較低，自然處理速度會比較慢。
5.自適應(yīng)hash出現(xiàn)鎖沖突
AHI是innodb存儲引擎特有的屬性，innodb存儲引擎會針對索引數(shù)據(jù)的查詢結(jié)果做自適應(yīng)的優(yōu)化，當(dāng)某些特定的索引查詢頻率特別高的時候會自動為其建立hash索引，從而提升查詢的效率。相比于B+Tree索引來說，hash索引能夠大大減少對于io的訪問次數(shù)，“一擊命中” 查詢數(shù)據(jù)，具備更加高效的性能，而且hash索引是由mysql內(nèi)部自動適配的，無需dba在外部做過多的干預(yù)。
早期版本的hash索引是采用了單鎖模式來防范并發(fā)訪問問題，這對于程序自身的一個運作高效性有一定的”折扣“，后期通過對hash索引進行了分區(qū)，不同頁的數(shù)據(jù)用不同的hashtable，每個分區(qū)有對應(yīng)的鎖來做并發(fā)訪問的預(yù)防。
如果某天你發(fā)現(xiàn)了有很多線程都被堵塞在了RW-latches的時候，有可能就是因為hash索引的并發(fā)訪問負(fù)載過高導(dǎo)致的堵塞，這個時候可以通過增大hash索引的分區(qū)參數(shù)，或者關(guān)閉自適應(yīng)hash索引特性來進行處理。
往期推薦
下方二維碼關(guān)注我
技術(shù)草根，堅持分享?編程，算法，架構(gòu)