列存索引服務用戶廣泛、應用場景復雜。用戶往往無法對參數進行有效的調整，可能會導致自測結果不理想，或者需要提交工單給內核團隊尋求幫助。但內核團隊的支持能力有限，不能夠保證支持力度。因此，列存索引內存管理的設計目標是能夠在默認情況下提供足夠好的自適應管理方法，同時也支持通過人工調整參數值來適配各種場景。本文介紹了列存索引物理內存、虛擬內存以及如何控制內存與并發執行相關內容。
物理內存
列存索引執行器的所有內存全部接入到統一的內存分配接口中。該統一接口的功能如下：
統計實際內存使用量
block即將分配內存的查詢操作
kill即將分配內存的查詢操作
系統從完全自由運行到開始終止查詢需經歷如下三個階段：
當系統內存低于
ExecutionMemoryLimit * BlockMemoryThreshold（現在固定為0.8）時，所有查詢自由運行。當系統內存高于
ExecutionMemoryLimit * BlockMemoryThreshold但小于ExecutionMemoryLimit * KillMemoryThreshold（現在固定為0.99）時，查詢會被逐步block。block期間的內存被平均分成10份，內存沒有超過一個區域，就會有對應比例的查詢被block。當系統內存高于
ExecutionMemoryLimit * KillMemoryThreshold時，所有的查詢被block，kill線程開始運行，即將分配內存的查詢將會被kill。
系統每隔一段時間或內存達到一定水位就會觸發block和kill更新。當完成了這些狀態的更新之后，系統會檢測是否發生了死鎖，即所有查詢都處于block狀態。當發生死鎖時，系統會根據當前內存使用量選擇一條查詢語句使其進入執行狀態或者kill狀態。
除每秒觸發的整體狀態變化外，當內存使用跨越某個區域時，block_lwm (block low water mark)會被設置為當前區域的最小值減500 MB，block_hwm (block high water mark)會被設置為當前區域的最大值。當內存使用量超過lwm或hwm時才會觸發下一次的狀態變化。
虛擬內存
借助操作系統的虛擬內存概念來描述這個分配過程。當某個查詢從本模塊分配內存配額時，實際上當前查詢還沒有占用任何內存，且在整個查詢過程中，內存基本上不會超過分配的配額。分配配額類似于一次mmap，當前查詢預約了一部分內存的使用權，但有相當比例的內存最終不會被真實申請出來。OOM產生的實際條件是物理內存超過上限而不是虛擬內存。
虛擬內存的計算方法如下：
首先，系統的物理內存大小由規格參數
ExecutionMemoryLimit決定。物理內存模塊會統計當前正在實際使用的內存（Memoryused）。
虛擬內存可以統計當前并發執行的查詢分配的內存配額之和（MemoryQuotaAllocated）。
從VirtualMemory中為每個查詢分配內存配額，每個查詢分配的內存配額都等于物理內存大小。
VirtualMemory實際上就是預期Memoryused為ExecutionMemoryLimit時的最高可以分配出的內存配額之和，只要這個比例維持穩定，就可以安全地增加虛擬內存，從而提高系統資源的實際使用率。
虛擬內存與并發執行
對各類查詢進行測試后，您會發現在整個查詢過程中資源的使用不均勻，始終存在串行點與scale不好的問題。系統在不落盤、不kill（因內存不足）的情況下，需要盡可能地提高查詢之間的并發執行能力。如下：
當每個查詢使用的內存較少且內存資源充足時，虛擬內存變大，系統并發增加，資源使用率增加。
當每個查詢使用的內存較多且內存緊張時，虛擬內存較小，系統并發較低，查詢落盤較少或不落盤，kill比例較低或者不執行kill操作。
以上兩種情況均能帶來最佳性能收益。
性能效果
該測試使用Pareto分布生成的Sysbench表來驗證內存充足時增加并發帶來的性能提升效果。
測試使用的SQL語句如下：
SELECT SUM(id) FROM sbtest1 GROUP BY k ORDER BY k LIMIT 1;圖1 單獨執行SQL語句時的內存波動
圖2 單獨執行SQL語句時的CPU波動
從圖1和圖2可以看出，無論是CPU還是內存，雖然峰值比較高，但從平均值來看，資源并沒有被充分利用。使用虛擬內存之后，列存索引可以根據內存的實際使用情況，對并發數量進行調整。例如，一個查詢在執行過程中平均使用了一半的物理內存，那么就可以將并發數量增加為2個，如下圖所示：
圖3 根據虛擬內存與物理內存增加并發數量
增加并發數量后，理論上可以讓不同查詢錯峰使用資源，使得資源利用率更高，能有效降低scale能力差以及串行點對性能帶來的影響，從而減少整體的時延。如下圖所示：
圖4 擴大并發減少延時
不打開內存管理時的內存波動情況如下圖所示。其中，MEM-TOP為使用TOP采集整個mysqld進程的內存使用量，單位為GB。MEM-EXE是列存索引內部的內存統計量，單位為Byte。由于此時的查詢無法并發執行，內存波動較大。
圖5 未打開內存管理時的內存波動情況
打開內存管理后，列存索引會根據內存使用的實際情況適時增加并發數量，查詢之間的內存峰值與波谷可以相互疊加，波動減小，內存使用率提升。同時也帶來了性能的提升。打開內存管理后的內存波動情況如下圖所示：
圖6 打開內存管理時的內存波動情況
并發數量提升后不僅能夠提升性能，CPU使用率也會得到提升。通過更充分地利用資源，整體的延時會有一定程度的下降。效果圖如下：
圖 7 打開內存管理后的平均延時
