數據庫調優實踐案例

數據庫作為基礎數據支撐層的核心部分，對于應用和平臺整體性能表現有著決定性的影響。因此，數據庫性能優化可以說是最考驗DBA能力的工作了。本文我們就由數據庫內核專家來，以 SequoiaDB 5.0 內核的部分性能優化為例，帶領各位數據庫愛好者揭開數據庫性能優化的“神秘面紗”。

通常優化思路：

提高數據庫性能的方式有很多，總結起來從易到難無外乎如下三種：

最簡單直觀的是通過使用數據庫提供的工具，找到SQL語句執行中消耗資源最大或耗時最長的部分，也即性能瓶頸。然后通過調整數據本身或數據庫配置解決這些性能瓶頸。比如說發現數據分布不均勻，我們可以通過切分數據(split)達到數據均衡(rebalance)；再比如我們發現某些網絡時延較長，在確定不是網絡本身的問題后，我們可以通過調整連接端口數和通訊處理線程提高數據庫消息處理能力；再比如單點磁盤IO過多，需要調整緩存或調整部分數據的分布。SequoiaDB提供了圖形化的性能診斷工具SequoiaPerf，可以協助用戶完成上述的調優。
業界經驗證明，效果最明顯，成本最低的方法其實是SQL語句的調優，通常是通過理解分析訪問計劃，對比實際語句執行時的開銷來判斷語句是否優化。比如對比索引讀和表讀的個數判斷否創建使用了合適的索引；對比訪問計劃的打分和時間執行開銷來判斷表/集合/索引的統計信息是否反映當前最新的狀態；觀察鎖等待時間來判斷系統中是否存在應用持鎖時間過長阻塞其他應用而；對比join兩邊表的返回數據集以及使用的過濾條件判斷使用join的類型是否合理。SequoiaDB 提供了完善監控功能，通過結合圖形化的sequoiaPerf 與snapshot，用戶可以相對容易的定位和實現SQL語句的調優。
前兩種方式通常是DBA或應用開發者就能完成的任務，第三種是數據庫內核的優化。這主要是數據庫廠商在不斷的實踐中，通過各種相對底層的性能診斷工具，定位和優化數據引擎的性能。

內核調優

在數據庫內核的調優中，開發人員通常會跑一定的workload或benchmark，使用操作系統或三方提供的工具，持續監控系統各類資源的使用情況，在高并發系統中，也會關注并發控制中使用的鎖和原子變量帶來的開銷。下面我們通過TPCC場景下的逐步優化SequoiaDB內核的過程，來了解我們是如何使用工具來定位優化數據引擎的。

CPU usage

我們常使用兩大神器觀察CPU使用情況：top 和 perf。top能動態的顯示linux 系統中各進程/線程以及內存使用的匯總信息。

以上圖為例，我們知道這臺機器的CPU基本上被用滿了，其中系統CPU占13%，用戶CPU占81.7%。如果CPU出現過多的空閑，往往意味著系統要么還可以增加負載提高性能，要么有瓶頸導致CPU上不去，比如說并發不好，太多等待，串行化太多。在這個例子中，我們沒有看到等IO的情況，idle的比例也非常小，這都是好的現象。在CPU用滿的情況下，優化系統也意味著要盡量減少開銷，讓系統能盡可能的跑多點任務。需要注意的是，如果系統CPU過高，意味著CPU不是在執行跟程序邏輯相關的指令，也可以理解為是overhead。根據以往的經驗，這里系統CPU占比還是偏高。使用線程模式，更進一步分析，我們可以看到潛在的問題可能是在系統調用，context switch和并發控制的mutex上。

至于更精確的定位，就要perf出馬了。注意的是SequoiaDB 的代碼編譯時加入了debug symbol，這樣會帶來一定的性能損失，但能夠極大的方便問題診斷和定位。

perf 是linux提供的一種基于event的性能搜集分析工具，能夠分析CPU/內存/鎖等資源的統計信息。perf本身已經提供了相當完整的文字的報表輸出功能。

比如這里能看到system_call 也是跟sys_futex 相關的，通常是線程/進程同步共享資源互踩時造成的，還有部分是通訊線程相關的。這樣我們的方向就可以從各種鎖沖突入手。Perf也能提供鎖沖突的信息。

為了簡單直觀的分析結果，我們還使用火焰圖(flame graph)來用圖形的方式展現結果，以利用更快的發現問題。下面兩張圖分別提供了CPU和鎖的使用統計：從中我們發現的確有幾處熱的Latch/mutex。比如內存分配時使用共享內存池，這是會造成等鎖的現象，我們可以通過使用線程上獨享的內存池解決；還要部分內部表的物理鎖沖突嚴重，我們通過增加鎖的控制粒度減少沖突；再有就是盡量減少鎖內操作，比如內存分配，磁盤IO盡可能的搬出熱鎖保護范圍。通過一系列優化，我們實現了5%左右的性能提升。

CPU 火焰圖

鎖火焰圖

1.Memory allocation

內存是個好東西，現在計算機系統內存越來越大，軟件也盡量通過使用內存來實現空間換時間以提高系統相應速度。但是動態內存分配常常成為了高性能軟件的性能瓶頸。我們通過perf 來抓取系統內存的使用情況，并用火焰圖顯示出來：

這里明顯看到的是很多動態內存分配發生在一個set的插入過程中。Std::set內部使用的紅黑樹，每次結點的插入都要進行內存分配。為了減少系統內存的動態分配與回收，SequoiaDB實現了一整套自己的內存管理機制。最開始盡量在線程預分配好的內存池上分配空間，這點和tcmalloc的原理很接近，這時的開銷最小，內存事先已經從操作系統分配好了，而且本線程上分配是無鎖的。但是如果線程內存池用完了，我們會到一個共享的預分配好的內存池上分配，這時會多一個鎖的開銷。但這兩處都用完了，我們才向操作系統申請。從火焰圖上看，我們基本上都走到向操作系統分配的分支中了。針對這種情況，我們優化了set的實現。當set中結點數量較小時，我們用一個flat的較小的array存放數據，避免了動態內存分配。當結點數較多時，我們再轉化成樹型結構以提高查找效率。但是我們會提高線程上允許的緩沖池的大小，特別是小結構線程池大小。最終我們避免了絕大多少的動態內存分配與回收，提升了系統性能。通過這塊的分析，我們也反過來幫助確定那些query會用到大量數據，并優化對應的query。

2.Cache line misses

大家知道現代CPU的主頻非常高，常有超過3GHz，執行指令速度非常快。但是我們存儲訪問速度始終跟不上，高速的內存又非常貴，這就是現代CPU里有幾級不同速度不同大小內存的原因，常見的CPU內集成有L1,L2,L3級緩存。CPU執行時需要從緩存中獲取指令和數據。在我們編譯程序的時候，編譯器會試圖優化程序，使得CPU能有效的重用或預提取數據和指令。當CPU在緩存中找不到合適的指令和數據時，就不等不從主存甚至磁盤上讀取他們，這樣的開銷非常大，我們用CPU cache line miss來衡量這種情況出現的頻繁程度。

我們還是通過perf命令來搜集cache line miss的情況，

詳細信息分解開來，最大一塊是由monitor引起的

然后我們檢查monitor相關的代碼，發現代碼中有個switch語句公有14個分支，但最常用的一個分支放在了后面。我們只需要將其挪到前面，我們的miss就有顯著下降。

還有另外一種情況造成嚴重的cache line miss，就是使用原子變量，特別是頻繁使用的原子變量。因為一旦該變量被變更了，所有cache 里的值都會變成無效，那么CPU使用時一定會碰到cache line miss。我們通過分析代碼邏輯，對于某些常用的確不需要時時精確的值，我們可以在程序邏輯開始存為本地變量，避免過多的直接訪問。對于一些只需要單線程訪問的變量，我們也避免使用原子變量。

小結：

上面我們通過幾個例子，為大家展現了如何通過系統工具進行數據庫內核性能優化，同樣的思路也可以適用于其他底層軟件的開發調試。在實際的實踐過程中，除了使用合適的工具，更重要的是還要細心，有耐心和鉆研的精神，一步步的下手，從現象中抽絲剝繭，找到根本原因。