營銷型網(wǎng)站的現(xiàn)狀近期國內(nèi)新聞
作者:李文杰 網(wǎng)易游戲計費 TiDB 負責(zé)人
在使用或運維管理 TiDB 的過程中,大家?guī)缀醵加龅竭^ SQL 變慢的問題,尤其是查詢相關(guān)的讀變慢問題。讀變慢的問題大部分情況下都遵循一定的規(guī)律,通過經(jīng)驗的積累可以快速的定位和優(yōu)化,不好排查的問題需要從讀 TiDB 的每個過程一一排查和分析處理。
本文針對讀 TiDB 集群的場景,總結(jié)業(yè)務(wù) SQL 在查詢突然變慢時的分析和排查思路,旨在沉淀經(jīng)驗、共享與社區(qū)。
一. 讀原理
業(yè)務(wù) SQL 從客戶端發(fā)送到 TiDB 集群后,主要經(jīng)歷解析、生成執(zhí)行計劃、執(zhí)行查詢、返回查詢結(jié)果這幾個流程。如下所示是 TiDB 讀過程的架構(gòu)簡圖:
來自客戶端的每個讀取數(shù)據(jù)的操作,TiDB 也會將其封裝為讀事務(wù),通常情況下事務(wù)在執(zhí)行的過程分別會與 TiDB Server、TiPD Server 和 TiKV Server 進行交互。
TiDB?Server
● 用戶提交的業(yè)務(wù) SQL 經(jīng)過 Protocol Layer 進行 SQL 協(xié)議轉(zhuǎn)換后,內(nèi)部 PD Client 向 TiPD Server 申請到一個 TSO,此 TSO 即為讀事務(wù)的開始時間 txn_start_tso,同時也是該讀事務(wù)在全局的唯一 ID。
● TiDB Server 在解析前會將 SQL 做分類,分為 KV 點查詢(唯一鍵查詢,Point Get)和 DistSQL 復(fù)雜查詢(非點查,Copprocessor )。
○ KV 點查詢跳過執(zhí)行計劃優(yōu)化階段,直接到查詢層,對于在線交易相關(guān)的 TP 場景,會大大降低響應(yīng)延遲。
○ 復(fù)雜的 SQL 查詢會被解析、轉(zhuǎn)為抽象語法樹 AST、編譯、基于 RBO/CBO 等優(yōu)化,會生成真正可以執(zhí)行的計劃。最終生成一個個對單個表訪問的數(shù)據(jù)請求。
● TiKV Client 模塊負責(zé)和存儲層進行交互,查詢請求經(jīng)過 gRPC 調(diào)用,會優(yōu)先進入 Unified Read Pool 線程池。
TiKV?Server
● Unified Read Pool 線程池負責(zé)確認查詢的數(shù)據(jù) Snapshot 和統(tǒng)一調(diào)度查詢優(yōu)先級。
○ 新來的查詢請求其優(yōu)先級是最高的,落在 L0 隊列里。隨著查詢時間越久,為了保證系統(tǒng)整體吞吐量,慢查詢的優(yōu)先級會不斷降低,即會從 L0 調(diào)低到 L1、L2 等,隨著優(yōu)先級調(diào)低其分配到的 CPU 會減少。
○ 也就是說,一個大查詢它越慢,它的優(yōu)先級就會不斷調(diào)低,優(yōu)先級不斷調(diào)低其執(zhí)行的時間可能會更久。所以,盡可能減少大查詢事務(wù)。
● 查詢請求讀取 RocksDB 數(shù)據(jù)
○ 先去 LSM Tree 的 MemTable 查找,最新的數(shù)據(jù)會寫在這里,如果命中則返回。
○ 如果沒找到,繼續(xù)到 Immutable Memory Table 查找,找到則返回。
○ 如果再找不到,則搜查 SST 文件的緩存 Block Cache,找到則返回。
○ 如果還沒找到,則會開始讀取磁盤 SST 文件,會依次搜索 L0 至 L6 各個層級的內(nèi)容。每一層的文件都會配備一個布隆過濾器。
過濾器對一個 Key 如果判斷不存在,那么它一定不存在這個 SST 文件內(nèi),此時可以跳過這個文件;
如果判斷在文件內(nèi)則它可能在可能不在,無法判斷準確,此時會直接去查文件內(nèi)容,由于 SST 文件嚴格有序,所以在文件內(nèi)是效率較高的二分查找。
○ 直到找到數(shù)據(jù)后,通過 gRPC 調(diào)用返回查詢結(jié)果。
上面描述的過程,大致就是一個查詢請求在 TiDB 集群內(nèi)部的流轉(zhuǎn)步驟,這也是我們在遇到讀慢時的分析步驟。
二. 讀變慢排查思路
2.1 讀慢常規(guī)分析
業(yè)務(wù)的 SQL 變慢后,我們在 TiDB Server 的 Grafana 面板可以看到整體的或者某一百分位的請求延遲會升高,我們根據(jù)現(xiàn)象先確認方向性的問題:是整體變慢,還是某個 SQL 變慢。
● 是否整體變慢
○ 分析各個組件 TiDB、TiKV、TiPD 的響應(yīng)延遲情況
● 整體如果是正常的,繼續(xù)分析是不是某類 SQL 變慢
○ 到 Dashboard 查一查慢查詢,看一看集群熱力圖,分析一下 Top SQL
根據(jù)上面的思路,通常就可以對讀變慢的問題有一個整體的把握。
接著,和寫入變慢的分析一樣,我們可以依次排查物理硬件環(huán)境、是否有業(yè)務(wù)變更操作等情況,直到定位清楚問題。如下圖所示,業(yè)務(wù)讀 SQL 變慢的分析思路可以有下面步驟:
● 遇到問題我們應(yīng)該養(yǎng)成習(xí)慣,要先到 Dashboard 看看,對集群運行狀況有個整體的把握
○ 查看集群熱力圖,關(guān)注集群高亮的區(qū)域,分析是否有讀熱點出現(xiàn),如果有則確認對應(yīng)的庫表、Region 等信息
熱點問題處理 (?https://docs.pingcap.com/zh/tidb/stable/troubleshoot-hot-spot-issues#tidb-熱點問題處理 )
○ 排查慢 SQL 情況,查看集群慢查詢結(jié)果,分析 SQL 慢查詢原因
○ 查看 TOP SQL 面板,分析集群的 CPU 消耗與 SQL 關(guān)聯(lián)的情況
● 物理硬件排查
○ 排查客戶端與集群之間、集群內(nèi)部 TiDB 、TiPD、TiKV 各組件之間的網(wǎng)絡(luò)問題
○ 排查集群的內(nèi)存、CPU、磁盤 IO 等情況,尤其是混合部署的集群,確認是否存在資源相互競爭、擠兌的場景出現(xiàn)
○ 排查操作系統(tǒng)的內(nèi)核操作是否與官方建議的最佳實踐值是否一致,確認 TiDB 集群運行在最優(yōu)的系統(tǒng)環(huán)境內(nèi)
● 業(yè)務(wù)變更
○ 確認是否是新上線業(yè)務(wù)
○ 查看集群的 DDL Jobs,確認是否由于在線 DDL 導(dǎo)致的問題,特別是大表加索引的場景,會消耗集群較多的資源,從而干擾集群正常的訪問請求
2.2 讀慢全鏈路排查
常規(guī)分析思路可以解決絕大部分的問題,對于剩下那些無法確認的或較為復(fù)雜業(yè)務(wù)的問題,這時候可以分析讀請求從 TiDB Server 到 TiKV Server 、到讀 RocksDB 的整個過程,對全部查詢的鏈路逐一進行排查,從而確認查詢慢所在的節(jié)點,定位到原因后再進行優(yōu)化即可,這一過程大致如下圖所示。
同樣地,這個是一個兜底的排查思路,適用范圍較廣、通用性較強,但是排查起來要花費更多的時間和精力,也要求管理員對數(shù)據(jù)庫本身的運行原理有一定的掌握。上面的排查步驟還是很復(fù)雜的,對用戶很不友好。
但是,目前官方已經(jīng)推出的 Dashboard 慢查詢分析功能,已經(jīng)幫我們集成和記錄了各個環(huán)節(jié)的延遲,再也不用一個一個去查找 Grafana 面板來確認和分析了,極大地降低排查難度和縮短問題解決時長,是 TiDB 用戶的一大福音。
下面是一個慢查詢執(zhí)行時長分析的例子,可以看到慢查詢是因為 TiKV 執(zhí)行 Coprocessor 任務(wù)的累計處理時間比較久,所以導(dǎo)致整個查詢較慢, 我們再繼續(xù)針對性分析和優(yōu)化 Coprocessor 算子即可。
三. 總結(jié)
● 了解 TiDB 的讀過程,有助于我們掌握數(shù)據(jù)庫的底層執(zhí)行原理,遇到問題時可以快速定位和分析原因,也能引導(dǎo)我們更好地使用數(shù)據(jù)庫,發(fā)揮其最好的性能。
● TiDB Dashboard 是對用戶非常友好的一個官方工具,它使得我們分析慢查詢 SQL 變得更輕松和快速,大大降低了問題處理的時間,強烈建議使用。
● 下面的官方文檔,在分析此類問題時推薦優(yōu)先查看:
○ 集群讀寫延遲增加排查 ( 讀寫延遲增加 | PingCAP 文檔中心 )
○ 熱點問題處理 ( TiDB 熱點問題處理 | PingCAP 文檔中心 )
○ 定位慢查詢 ( 慢查詢?nèi)罩?| PingCAP 文檔中心 )
○ 分析慢查詢 ( 分析慢查詢 | PingCAP 文檔中心 )