華為桌面云虛擬機
Windows Server 2019
版本1809
OS內部版本17763.107
Windows Server 2019服務器 一天之中內存利用率越來越高直到死機,不斷擴容內存從10G到16G一重啟就正常然后慢慢又循環，連續幾天都這樣，疑似內存泄漏
內存泄漏是什么?
內存泄漏指由于疏忽或錯誤造成程序未能釋放已經不再使用的內存。內存泄漏并非指內存在物理上的消失，而是應用程序分配某段內存后，由于設計錯誤，導致在釋放該段內存之前就失去了對該段內存的控制，從而造成了內存的浪費。內存泄漏通常情況下只能由獲得程序源代碼的程序員才能分析出來。
一周內內存利用率zabbix監控圖：
1.用PoolMonX工具，查看發現 Tag 為“toke”的進程占用內存巨大，標為綠色，即處于上升狀態
findstr /s /m /l “toke” c:/windows/system32/drivers/*.sys 通過findstr查找未發現有效信息
（未解決本案例故障）
2.網上說Win10發現微軟自帶拼音輸入法會引起這個問題，底層導致此問題的進程是TextServiceFramework，一輸入漢字就會觸發，可能某些軟件通過taskhostw.exe來提交內存。而taskhostw.exe的已提交內存并沒有被任務管理器正確的顯示出來。這就導致一些已提交內存被隱藏起來了。有人測試，新建一個文本文檔，共輸入了9千個漢字之后(我輸入的“水”字，按了十多分鐘的s鍵），已提交內存從2G，一路漲到上限9.9G，然后windows提示內存不足（設置了虛擬內存上限為2g，去掉顯卡占用的，已提交內存上限是9.9G）整個過程中，使用中內存基本保持不變。關閉文本文檔后，已提交內存下降為6.5g。不僅內存占用不正常，而且一半都無法釋放。結束taskhostw.exe進程，被輸入中文所占用的內存全部釋放，不過中文輸入法就用不了了。什么也不做，光打9千個漢字，就能爆掉8G內存。 （本案例未有這個情況，未解決）
3.殺毒，如Svchost.exe病毒
當發現Svchost.exe不在%systemroot%\System32目錄中的，可以安全刪除，同時在注冊表中查找對應的注冊項刪除掉。 或用 tasklist/svc命令查看svchost.exe 右邊的服務是不是“暫缺”，是的話為中毒了。
Svchost.exe在%systemroot%\System32目錄，說明Svchost.exe是被病毒感染了，可以用殺毒軟件清除（本案例未中毒，未解決）
4.卸載多余軟件，360安全，虛擬機插件等等，排除軟件沖突（本案例未有這個情況，未解決）
5.在系統日志文件里仔發現一個報錯：服務器無法通過系統非頁面共享區來進行分配，因為共享區當前是空的，事件ID2019（本案例未有這個情況，未解決）
6.修改注冊表而使內存占用達到一個較低程度的時候自動去整理內存，系統默認是內存達到80%時整理內存，可以手工修改注冊表
打開regedit
找到
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management
右鍵“編輯”—添加DWORD值 數值名稱：PoolUsageMaximum 數據類型：REG_DWORD
基數：十進制 數值數據：50
#通知內存管理器在達到PagedPoolMax的50%的時候開始自動整理，這里可以根據系統配置自行設置閥值
找到如果存在的話無需再創建 數值名稱：PagedPoolSize 數據類型：REG_DWORD
基數：十六進制 數值數據：0xFFFFFFFF #為計算機分配最大的頁面緩沖池已取代其他資源
重新啟動服務器生效 (本案例解決）
作者｜碼海
來源｜碼海（ID：seaofcode）
每當我們執行某個 SQL 發現很慢時，都會下意識地反應是否加了索引，那么大家是否有想過加了索引為啥會使數據查找更快呢，索引的底層一般又是用什么結構存儲的呢，相信大家看了標題已經有答案了，沒錯！B+樹！那么它相對于一般的鏈表，哈希等有何不同，為何多數存儲引擎都選擇使用它呢，今天我就來揭開 B+ 樹的面紗，相信看了此文，B+ 樹不再神秘，對你理解以下高頻面試題會大有幫助！
為啥索引常用 B+ 樹作為底層的數據結構
除了 B+ 樹索引，你還知道什么索引
為啥推薦自增 id 作為主鍵，自建主鍵不行嗎
什么是頁分裂，頁合并
怎么根據索引查找行記錄
本文將會從以下幾個方面來講解 B+ 樹
定義問題
幾種常見的數據結構對比
頁分裂與頁合并
要知道索引底層為啥使用 B+ 樹，得看它解決了什么問題，我們可以想想，日常我們用到的比較多的 SQL 有哪些呢。
假設我們有一張以下的用戶表：
CREATE TABLE `user` (
`id` int(11) unsigned NOT AUTO_INCREMENT,
`name` varchar(20) DEFAULT COMMENT '姓名',
`idcard` varchar(20) DEFAULT COMMENT '身份證號碼',
`age` tinyint(10) DEFAULT COMMENT '年齡',
PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COMMENT='用戶信息';
一般我們會有如下需求：
1、根據用戶 id 查用戶信息
select * from user where id=123;
2、根據區間值來查找用戶信息
select * from user where id > 123 and id < 234;
3、按 id 逆序排列，分頁取出用戶信息
select * from user where id < 1234 order by id desc limit 10;
從以上的幾個常用 SQL 我們可以看到索引所用的數據結構必須滿足以下三個條件
根據某個值精確快速查找
根據區間值的上下限來快速查找此區間的數據
索引值需要排好序，并支持快速順序查找和逆序查找
接下來我們以主鍵索引（id 索引）為例來看看如何用相應的數據結構來構造它
接下來我們想想有哪些數據結構滿足以上的條件
1、散列表
散列表（也稱哈希表）是根據關鍵碼值(Key value)而直接進行訪問的數據結構，它讓碼值經過哈希函數的轉換映射到散列表對應的位置上，查找效率非常高。哈希索引就是基于散列表實現的，假設我們對名字建立了哈希索引，則查找過程如下圖所示：
對于每一行數據，存儲引擎都會對所有的索引列（上圖中的 name 列）計算一個哈希碼（上圖散列表的位置），散列表里的每個元素指向數據行的指針，由于索引自身只存儲對應的哈希值，所以索引的結構十分緊湊，這讓哈希索引查找速度非常快！但是哈希索引也有它的劣勢，如下：
針對哈希索引，只有精確匹配索引所有列的查詢才有效，比如我在列（A,B）上建立了哈希索引，如果只查詢數據列 A，則無法使用該索引。
哈希索引并不是按照索引值順序存存儲的，所以也就無法用于排序，也就是說無法根據區間快速查找
哈希索引只包含哈希值和行指針，不存儲字段值，所以不能使用索引中的值來避免讀取行，不過，由于哈希索引多數是在內存中完成的，大部分情況下這一點不是問題
哈希索引只支持等值比較查詢，包括=,IN，不支持任何范圍的查找，如 age > 17
綜上所述，哈希索引只適用于特定場合， 如果用得對，確實能再帶來很大的性能提升，如在 InnoDB 引擎中，有一種特殊的功能叫「自適應哈希索引」，如果 InnoDB 注意到某些索引列值被頻繁使用時，它會在內存基于 B+ 樹索引之上再創建一個哈希索引，這樣就能讓 B+樹也具有哈希索引的優點，比如快速的哈希查找。
2、鏈表
雙向鏈表支持順序查找和逆序查找，如圖下
但顯然不支持我們說的按某個值或區間的快速查找，另外我們知道表中的數據是要不斷增加的，索引也是要及時插入更新的，鏈表顯然也不支持數據的快速插入，所以能否在鏈表的基礎上改造一下，讓它支持快速查找，更新，刪除。有一種結構剛好能滿足我們的需求，這里引入跳表的概念。
什么是跳表?簡單地說，跳表是在鏈表之上加上多層索引構成的。如下圖所示
假設我們現在要查找區間 7- 13 的記錄，再也不用從頭開始查找了，只要在上圖中的二級索引開始找即可，遍歷三次即可找到鏈表的區間位置，時間復雜度是 O(logn)，非常快，這樣看來，跳表是能滿足我們的需求的，實際上它的結構已經和 B+ 樹非常接近了，只不過 B+ 樹是從平衡二叉查找樹演化而來的而已，接下來我們一步步來看下如何將平衡二叉查找樹改造成 B+ 樹。
先來看看什么是平衡二叉查找樹，平衡二叉查找樹具有如下性質：
若左子樹不空，則左子樹上所有節點的值均小于它的根節點的值；
若右子樹不空，則右子樹上所有節點的值均大于或等于它的根節點的值；
每個非葉子節點的左右子樹的高度之差的絕對值（平衡因子）最多為1。
下圖就是一顆平衡二叉查找樹
從其特性就可以看到平衡二叉查找樹查找節點的時間復雜度是 O(log2n)
現在我們將其改造成 B+ 樹
可以看到主要區別就是所有的節點值都在最后葉節點上用雙向鏈表連接在了一起，仔細和跳表對比一下 ，是不是很像，現在如果我們要找15 ~ 27 這個區間的數只要先找到 15 這個節點（時間復雜度 logn=3 次）再從前往后遍歷直到 27 這個節點即可，即可找到這區間的節點，這樣它完美地支持了我們提的三個需求：快速查找值，區間，順序逆序查找。
假設有 1 億個節點，每個節點要查詢多少次呢，顯然最多為 log21億=27 次，如果這 1 億個節點都在內存里，那 27 次顯然不是問題，可以說是非常快了，但一個新的問題出現了，這 1 億個節點在內存大小是多少呢，我們簡單算一下，假設每個節點 16 byte，則 1 億個節點大概要占用 1.5G 內存！對于內存這么寶貴的資源來說是非常可怕的空間消耗，這還只是一個索引，一般我們都會在表中定義多個索引，或者庫中定義多張表，這樣的話內存很快就爆滿了！所以在內存中完全裝載一個 B+ 樹索引顯然是有問題的，如何解決呢。
內存放不下， 我們可以把它放到磁盤嘛，磁盤空間比內存大多了，但新的問題又來了，我們知道內存與磁盤的讀取速度相差太大了，通常內存是納秒級的，而磁盤是毫秒級的，讀取同樣大小的數據，兩者可能相差上萬倍，于是上一步我們計算的 27 次查詢如果放在磁盤中來看就非常要命了（查找一個節點可以認為是一次磁盤 IO，也就是說有 27 次磁盤 IO！），27 次查詢是否可以優化？
可以很明顯地觀察到查詢次數和樹高有關，那樹高和什么有關，很明顯和每個節點的子節點個數有關，即 N 叉樹中的 N，假設現在有 16 個數，我們分別用二叉樹和五叉樹來構建，看下樹高分別是多少
可以看到如果用二叉樹 ，要遍歷 5 個節點，如果用五叉樹 ，只要遍歷 3 次，一下少了兩次磁盤 IO，回過頭來看 上文的一億個節點，如果我們用 100 叉樹來構建，需要幾次 IO 呢
可以看到，最多遍歷五次（實際上根節點一般存在內存里的，所以可以認為是 4 次）！磁盤 IO 一下從 27 減少到了 5！性能可以說是大大提升了,有人說 5 次還是太多，是不是可以把 100 叉樹改成 1000 或 10000 叉樹呢，這樣 IO 次數不就就能進一步減少了。
這里我們就需要了解頁（page）的概念，在計算機里，無論是內存還是磁盤，操作系統都是按頁的大小進行讀取的（頁大小通常為 4 kb），磁盤每次讀取都會預讀，會提前將連續的數據讀入內存中，這樣就避免了多次 IO，這就是計算機中有名的局部性原理，即我用到一塊數據，很大可能這塊數據附近的數據也會被用到，干脆一起加載，省得多次 IO 拖慢速度， 這個連續數據有多大呢，必須是操作系統頁大小的整數倍，這個連續數據就是 MySQL 的頁，默認值為 16 KB，也就是說對于 B+ 樹的節點，最好設置成頁的大小（16 KB），這樣一個 B+ 樹上的節點就只會有一次 IO 讀。
那有人就會問了，這個頁大小是不是越大越好呢，設置大一點，節點可容納的數據就越多，樹高越小，IO 不就越小了嗎，這里要注意，頁大小并不是越大越好，InnoDB 是通過內存中的緩存池（pool buffer）來管理從磁盤中讀取的頁數據的。頁太大的話，很快就把這個緩存池撐滿了，可能會造成頁在內存與磁盤間頻繁換入換出，影響性能。
通過以上分析，相信我們不難猜測出 N 叉樹中的 N 該怎么設置了，只要選的時候盡量保證每個節點的大小等于一個頁（16kb）的大小即可。
現在我們來看看開頭的問題， 為啥推薦自增 id 作為主鍵，自建主鍵不行嗎，有人可能會說用戶的身份證是唯一的，可以用它來做主鍵，假設以身份證作主鍵，會有什么問題呢。
B+ 樹為了維護索引的有序性，每插入或更新一條記錄的時候，會對索引進行更新。假設原來基于身份證作索引的 B+ 樹如下（假設為二叉樹 ，圖中只列出了身份證的前四位）
現在有一個開頭是 3604 的身份證對應的記錄插入 db ，此時要更新索引，按排序來更新的話，顯然這個 3604 的身份證號應該插到左邊節點 3504 后面（如下圖示，假設為二叉樹）。
如果把 3604 這個身份證號插入到 3504 后面的話，這個節點的元素個數就有 3 個了，顯然不符合二叉樹的條件，此時就會造成頁分裂，就需要調整這個節點以讓它符合二叉樹的條件。
如圖示：調整過后符合二叉樹條件
這種由于頁分裂造成的調整必然導致性能的下降，尤其是以身份證作為主鍵的話，由于身份證的隨機性，必然造成大量的隨機結點中的插入，進而造成大量的頁分裂，進而造成性能的急劇下降，那如果是以自增 id 作為主鍵呢，由于新插入的表中生成的 id 比索引中所有的值都大，所以它要么合到已存在的節點（元素個數未滿）中，要么放入新建的節點中（如下圖示）所以如果是以自增 id 作為主鍵，就不存在頁分裂的問題了，推薦！
有頁分裂就必然有頁合并，什么時候會發生頁合并呢，當刪除表記錄的時候，索引也要刪除，此時就有可能發生頁合并，如圖示：
當我們刪除 id 為 7，9 對應行的時候，上圖中的索引就要更新，把 7，9 刪掉，此時 8，10 就應該合到一個節點，不然 8，10 分散在兩個節點上，可能造成兩次 IO 讀，勢必會影響查找效率! 那什么時候會發生頁合并呢，我們可以定個閾值，比如對于 N 叉樹來說，當節點的個數小于 N/2 的時候就應該和附近的節點合并，不過需要注意的是合并后節點里的元素大小可能會超過 N，造成頁分裂，需要再對父節點等進行調整以讓它滿足 N 叉樹的條件。
相信大家看完以上的 B+ 樹索引的介紹應該還有個疑惑，怎么根據對應的索引值查找行記錄呢，其實相應的行記錄就放在最后的葉子節點中，找到了索引值，也就找到了行記錄。如圖示：
可以看到，非葉子節點只存了索引值，只在最后一行才存放了行記錄，這樣極大地減小了索引了大小，而且只要找到索引值就找到了行記錄，也提升了效率，
這種在葉節點存放一整行記錄的索引被稱為聚簇索引，其他的就稱為非聚簇索引。
綜上所述，B+樹有以下特點：
每個節點中子節點的個數不能超過 N，也不能小于 N/2（不然會造成頁分裂或頁合并）
根節點的子節點個數可以不超過 m/2，這是一個例外
m 叉樹只存儲索引，并不真正存儲數據，只有最后一行的葉子節點存儲行數據。
通過鏈表將葉子節點串聯在一起，這樣可以方便按區間查找
本文由日常中常用的 SQL 由淺入深地總結了 B+ 樹的特點，相信大家應該對 B+ 樹索引有了比較清晰地認識，所以說為啥我們要掌握底層原來，學完了 B+ 樹，再看開頭提的幾個問題，其實也不過如此，深挖底層，有時候確實能讓你以不變應萬變。
?智能穿戴市場群雄逐鹿，OPPO入局能沒有殺手锏？
?半小時訓練億級規模知識圖譜，亞馬遜AI開源知識圖譜嵌入表示框架DGL-KE
?“出道” 5 年采用率達 78%，Kubernetes 的成功秘訣是什么？