一、哪些因素會成為系統的瓶頸？
1、CPU，如果存在大量的計算，他們會長時間不間斷的占用CPU資源，導致其他資源無法爭奪到CPU而回應緩慢，從而帶來系統性能問題，例如頻繁的FullGC，以及多執行緒造成的背景關系頻繁的切換，都會導致CPU繁忙，一般情況下CPU使用率<75%比較合適，
2、記憶體，Java記憶體一般是通過jvm記憶體進行分配的，主要是用jvm中堆記憶體來存盤Java創建的物件，記憶體的讀寫速度非常快，但是記憶體空間又是有限的，當記憶體空間被占滿，物件無法回收時，就會導致記憶體溢位或記憶體泄漏，
3、磁盤I/O，磁盤的存盤空間要比記憶體存盤空間大很多，但是磁盤的讀寫速度比記憶體慢，雖然現在引入SSD固態硬碟，但是還是無法跟記憶體速度相比，
4、網路，帶寬的大小，會對傳輸資料有很大影響，當并發量增加時，網路很容易就會成為瓶頸，
5、例外，Java程式，拋出例外，要對例外進行捕獲，這個程序要消耗性能，如果在高并發的情況下，持續進行例外處理，系統的性能會受影響，
6、資料庫，資料庫的操作一般涉及磁盤I/O的讀寫，大量的資料庫讀寫操作，會導致磁盤I/O性能瓶頸，進而導致資料庫操作延遲，
7、當在并發編程的時候，經常會用多執行緒操作同一個資源，這個時候為了保證資料的原子性，就要使用到鎖，鎖的使用會帶來背景關系切換，從而帶來性能開銷，在JDK1.6之后新增了偏向鎖、自旋鎖、輕量級鎖、鎖粗化、鎖消除，
二、哪些指標做為衡量系統的性能
1、RT回應時間，包括如下
1.1 資料庫回應時間，即資料庫操作的時間
1.2 服務端回應時間，服務端包括Nginx分發的請求所消耗的時間及服務端程式執行所消耗的時間，
1.3 網路回應時間，網路傳輸，網路硬體需要對傳輸的請求進行決議所消耗的時間
1.4 客戶端回應時間，一般Web、App客戶端，消耗時間可以忽略不計，但是如果客戶端存在大量的邏輯處理，消耗的時間有能能就會變長，
2、TPS吞吐量
2.1 磁盤吞吐量
IOPS（Input/Output Per Second）每秒的輸入輸出量，這種是單位時間內系統能處理的I/O請求數量，I/O請求通常為讀或寫資料操作請求，關注隨機讀寫性能，適用于隨機讀寫頻繁的應用，如小檔案存盤，郵件服務器， 資料吞吐量，這種是單位時間可以傳輸的資料量，對于大量順序讀寫頻繁的應用，傳輸大量連續資料，例如視頻編輯，
2.2 網路吞吐量
指網路傳輸時沒有丟幀的情況下，設備能夠接受的最大資料速率，網路吞吐量不僅跟帶寬有關系，還跟CPU處理能力、網卡、防火墻、以及I/O等緊密聯系，吞吐量的大小由網卡的處理能力、內部程式演算法以及帶寬大小決定，
3、資源使用率
3.1 CPU使用率，首先可以先了解CPU的基本資訊，包括物理CPU的個數、單個CPU的核數，然后可以通過命令查看使用率，vmstat、mpstat、top
3.2 記憶體使用率，free -m、vmstat、top
3.3 磁盤I/O， iostat、 iotop、
3.4 網路I/O，netstat、ifconfig、tcpstat、
三、性能測驗注意的問題
1、我們在做性能測驗的時候，系統的運行會越來越快，后面的訪問速度比我們第一次訪問的速度快了好幾倍，這是因為Java語言編譯的順序是，.java檔案先編譯為.class檔案，然后通過解釋器將.class的位元組碼轉換成本地機器碼后，才能運行，為了節約記憶體和執行效率，代碼最初被執行時，解釋器會率先解釋執行這段代碼，隨著代碼被執行的次數增多，虛擬機發現某個方法或代碼運行的特別頻繁，就被認定為熱點代碼（Hot Spot Code），為了提高熱點代碼的執行效率，在運行時虛擬機將會通過即時編譯器（JIT）把這些代碼編譯成為本地平臺相關的機器碼，然后儲存在記憶體中，之后每次運行代碼時，直接從記憶體中獲取，這樣就會導致第一次系統運行慢，后面訪問的速度快幾倍，
2、在做性能測驗的時候，每次測驗處理的資料集都是一樣的，但是結果卻有差異，這是因為測驗時，伴隨著很多不穩定因素，比如機器其他行程的影響、網路波動以及每個階段JVM垃圾回收的不同等，我們可以通過多次測驗，將測驗結果求平均，只要保證平均值在合理范圍之內，并且波動不是很大，這種情況，性能測驗就算通過，
四、定位性能問題的時候，可以使用自下而上的策略分析排查
當我們進行壓測之后，我們會輸出一份性能測驗報告，其中包括，RT、TPS、TP99，被壓服務器的CPU、記憶體、I/O，以及JVM的GC頻率，通過這些指標可以發現性能瓶頸，我們可以采用自下而上的方式進行分析，
1、首先從作業系統層面，查看系統的CPU、記憶體、I/O、網路的使用率是否例外，再通過命令查找例外日志，最后通過日志分析，找到導致瓶頸的問原因，
2、還可以從Java應用的JVM層面，查看JVM的垃圾回收頻率以及記憶體分配情況是否存在例外，分析垃圾回收日志，找到導致瓶頸的原因，
3、如果系統和JVM層面都沒有出現例外情況，然后可以從應用服務業務層查看是否存在性能瓶頸，例如，Java編程問題，讀寫資料庫瓶頸等，
五、優化性能問題的時候，可以使用自上而下的策略進行優化
整體的調優順序，我們可以從業務調優到編程調優，最后再到系統調優
1、應用層調優
首先是優化代碼，代碼問題往往會因為消耗系統資源而暴漏出來，例如代碼導致記憶體溢位，使JVM記憶體用完，而發生頻繁的FullGC，導致CPU偏高，
其次是優化設計，主要是優化業務層和中間件層代碼，例如可以采用代理模式，放在頻繁呼叫的創建物件的場景里，共享一個創建物件，減少創建物件的消耗，
再次是優化演算法，選擇合適的演算法降低時間復雜度，
2、中間件調優
MySQL調優
1)、表結構與索引優化，
主要是對資料庫設計、表結構設計以及索引設定維度進行的優化，設計表結構的時候，考慮資料庫的水平與垂直的拓展能力，提前規劃好將來資料量、讀寫量的增長，規劃好分庫分表方案，對欄位選擇合適的資料型別，優先選用較小的資料結構，
2)、SQL陳述句優化，
主要是對SQL陳述句進行的優化，使用explain來查看執行計劃，來查看是否使用了索引，使用了哪些索引，也可以使用Profile命令分析陳述句執行程序中各個分步的耗時，
3)、MySQL引數優化，
主要是對MySQL服務的配置進行優化，例如連接數的管理，對索引快取、查詢快取、排序快取等各種快取大小進行優化
4)、硬體及系統配置，
對硬體設備和作業系統設定進行優化，例如調整作業系統引數、禁用swap、增加記憶體、升級固態硬碟，
3、系統調優
首先是作業系統調優，Linux操作的內核引數設定可以進行調優，已達到提供高性能的目的，
其次，JVM調優，設定合理的JVM記憶體空間，以及垃圾回收演算法來提高性能，例如，如果業務邏輯會創建大物件，我們就可以設定，將大的物件直接放到老年代中，這樣可以減少年輕代頻發發生YongGC，減少CPU的占用時間，
4、調優的策略
首先是時間換取空間，有的時候系統對查詢速度要求不高，對存盤空間要求較高，這個時候我們可以考慮用時間換取空間，
其次是空間換取時間，用存盤空間提升訪問速度，典型的就是MySQL的分庫分表策略，MySQL表單資料存盤千萬以上的時候，讀寫性能就會下降，這個時候我們可以將資料進行拆分，以達到查詢的時候，每個表的資料是少量的，以達到提升性能的目的，
5、兜底策略
系統調優后，仍然還會存在性能問題，這個時候我們需要有兜底策略， 首先是限流，對系統的入口設定最大訪問限制，同時采取斷熔措施，回傳沒有成功的請求， 其次是橫向擴容，當訪問量超過某一個閾值時，系統可以自動橫向增加服務，
作者：京東健康 牛金亮
內容來源：京東云開發者社區
轉載請註明出處，本文鏈接：https://www.uj5u.com/houduan/553520.html
標籤：其他
下一篇：返回列表