減少 curl 中內存分配操作(malloc)
今天我在 libcurl 內部又做了一個小改動,使其做更少的 malloc。這一次,泛型鏈表函數被轉換成更少的 malloc (這才是鏈表函數應有的方式,真的)。
研究 malloc
幾周前我開始研究內存分配。這很容易,因為多年前我們 curl 中就已經有內存調試和日誌記錄系統了。使用 curl 的調試版本,並在我的構建目錄中運行此腳本:
#!/bin/sh
export CURL_MEMDEBUG=$HOME/tmp/curlmem.log
./src/curl http://localhost
./tests/memanalyze.pl -v $HOME/tmp/curlmem.log
對於 curl 7.53.1,這大約有 115 次內存分配。這算多還是少?
內存日誌非常基礎。為了讓你有所了解,這是一個示例片段:
MEM getinfo.c:70 free((nil))
MEM getinfo.c:73 free((nil))
MEM url.c:294 free((nil))
MEM url.c:297 strdup(0x559e7150d616) (24) = 0x559e73760f98
MEM url.c:294 free((nil))
MEM url.c:297 strdup(0x559e7150d62e) (22) = 0x559e73760fc8
MEM multi.c:302 calloc(1,480) = 0x559e73760ff8
MEM hash.c:75 malloc(224) = 0x559e737611f8
MEM hash.c:75 malloc(29152) = 0x559e737a2bc8
MEM hash.c:75 malloc(3104) = 0x559e737a9dc8
檢查日誌
然後,我對日誌進行了更深入的研究,我意識到在相同的代碼行做了許多小內存分配。我們顯然有一些相當愚蠢的代碼模式,我們分配一個結構體,然後將該結構添加到鏈表或哈希,然後該代碼隨後再添加另一個小結構體,如此這般,而且經常在循環中執行。(我在這裡說的是我們,不是為了責怪某個人,當然大部分的責任是我自己……)
這兩種分配操作將總是成對地出現,並被同時釋放。我決定解決這些問題。做非常小的(小於 32 位元組)的分配也是浪費的,因為非常多的數據將被用於(在 malloc 系統內)跟蹤那個微小的內存區域。更不用說堆碎片了。
因此,將該哈希和鏈表代碼修復為不使用 malloc 是快速且簡單的方法,對於最簡單的 「curl http://localhost」 傳輸,它可以消除 20% 以上的 malloc。
此時,我根據大小對所有的內存分配操作進行排序,並檢查所有最小的分配操作。一個突出的部分是在 curl_multi_wait()
中,它是一個典型的在 curl 傳輸主循環中被反覆調用的函數。對於大多數典型情況,我將其轉換為使用堆棧。在大量重複的調用函數中避免 malloc 是一件好事。
重新計數
現在,如上面的腳本所示,同樣的 curl localhost
命令從 curl 7.53.1 的 115 次分配操作下降到 80 個分配操作,而沒有犧牲任何東西。輕鬆地有 26% 的改善。一點也不差!
由於我修改了 curl_multi_wait()
,我也想看看它實際上是如何改進一些稍微更高級一些的傳輸。我使用了 multi-double.c 示例代碼,添加了初始化內存記錄的調用,讓它使用 curl_multi_wait()
,並且並行下載了這兩個 URL:
http://www.example.com/
http://localhost/512M
第二個文件是 512 兆位元組的零,第一個文件是一個 600 位元組的公共 html 頁面。這是 count-malloc.c 代碼。
首先,我使用 7.53.1 來測試上面的例子,並使用 memanalyze
腳本檢查:
Mallocs: 33901
Reallocs: 5
Callocs: 24
Strdups: 31
Wcsdups: 0
Frees: 33956
Allocations: 33961
Maximum allocated: 160385
好了,所以它總共使用了 160KB 的內存,分配操作次數超過 33900 次。而它下載超過 512 兆位元組的數據,所以它每 15KB 數據有一次 malloc。是好是壞?
回到 git master,現在是 7.54.1-DEV 的版本 - 因為我們不太確定當我們發布下一個版本時會變成哪個版本號。它可能是 7.54.1 或 7.55.0,它還尚未確定。我離題了,我再次運行相同修改的 multi-double.c 示例,再次對內存日誌運行 memanalyze,報告來了:
Mallocs: 69
Reallocs: 5
Callocs: 24
Strdups: 31
Wcsdups: 0
Frees: 124
Allocations: 129
Maximum allocated: 153247
我不敢置信地反覆看了兩遍。發生什麼了嗎?為了仔細檢查,我最好再運行一次。無論我運行多少次,結果還是一樣的。
33961 vs 129
在典型的傳輸中 curl_multi_wait()
被調用了很多次,並且在傳輸過程中至少要正常進行一次內存分配操作,因此刪除那個單一的微小分配操作對計數器有非常大的影響。正常的傳輸也會做一些將數據移入或移出鏈表和散列操作,但是它們現在也大都是無 malloc 的。簡單地說:剩餘的分配操作不會在傳輸循環中執行,所以它們的重要性不大。
以前的 curl 是當前示例分配操作數量的 263 倍。換句話說:新的是舊的分配操作數量的 0.37% 。
另外還有一點好處,新的內存分配量更少,總共減少了 7KB(4.3%)。
malloc 重要嗎?
在幾個 G 內存的時代里,在傳輸中有幾個 malloc 真的對於普通人有顯著的區別嗎?對 512MB 數據進行的 33832 個額外的 malloc 有什麼影響?
為了衡量這些變化的影響,我決定比較 localhost 的 HTTP 傳輸,看看是否可以看到任何速度差異。localhost 對於這個測試是很好的,因為沒有網路速度限制,更快的 curl 下載也越快。伺服器端也會相同的快/慢,因為我將使用相同的測試集進行這兩個測試。
我相同方式構建了 curl 7.53.1 和 curl 7.54.1-DEV,並運行這個命令:
curl http://localhost/80GB -o /dev/null
下載的 80GB 的數據會儘可能快地寫到空設備中。
我獲得的確切數字可能不是很有用,因為它將取決於機器中的 CPU、使用的 HTTP 伺服器、構建 curl 時的優化級別等,但是相對數字仍然應該是高度相關的。新代碼對決舊代碼!
7.54.1-DEV 反覆地表現出更快 30%!我的早期版本是 2200MB/秒增加到當前版本的超過 2900 MB/秒。
這裡的要點當然不是說它很容易在我的機器上使用單一內核以超過 20GB/秒的速度來進行 HTTP 傳輸,因為實際上很少有用戶可以通過 curl 做到這樣快速的傳輸。關鍵在於 curl 現在每個位元組的傳輸使用更少的 CPU,這將使更多的 CPU 轉移到系統的其餘部分來執行任何需要做的事情。或者如果設備是攜帶型設備,那麼可以省電。
關於 malloc 的成本:512MB 測試中,我使用舊代碼發生了 33832 次或更多的分配。舊代碼以大約 2200MB/秒的速率進行 HTTP 傳輸。這等於每秒 145827 次 malloc - 現在它們被消除了!600 MB/秒的改進意味著每秒鐘 curl 中每個減少的 malloc 操作能額外換來多傳輸 4300 位元組。
去掉這些 malloc 難嗎?
一點也不難,非常簡單。然而,有趣的是,在這箇舊項目中,仍然有這樣的改進空間。我有這個想法已經好幾年了,我很高興我終於花點時間來實現。感謝我們的測試套件,我可以有相當大的信心做這個「激烈的」內部變化,而不會引入太可怕的回歸問題。由於我們的 API 很好地隱藏了內部,所以這種變化可以完全不改變任何舊的或新的應用程序……
(是的,我還沒在版本中發布該變更,所以這還有風險,我有點後悔我的「這很容易」的聲明……)
注意數字
curl 的 git 倉庫從 7.53.1 到今天已經有 213 個提交。即使我沒有別的想法,可能還會有一次或多次的提交,而不僅僅是內存分配對性能的影響。
還有嗎?
還有其他類似的情況么?
也許。我們不會做很多性能測量或比較,所以誰知道呢,我們也許會做更多的愚蠢事情,我們可以收手並做得更好。有一個事情是我一直想做,但是從來沒有做,就是添加所使用的內存/malloc 和 curl 執行速度的每日「監視」 ,以便更好地跟蹤我們在這些方面不知不覺的回歸問題。
補遺,4/23
(關於我在 hacker news、Reddit 和其它地方讀到的關於這篇文章的評論)
有些人讓我再次運行那個 80GB 的下載,給出時間。我運行了三次新代碼和舊代碼,其運行「中值」如下:
舊代碼:
real 0m36.705s
user 0m20.176s
sys 0m16.072s
新代碼:
real 0m29.032s
user 0m12.196s
sys 0m12.820s
承載這個 80GB 文件的伺服器是標準的 Apache 2.4.25,文件存儲在 SSD 上,我的機器的 CPU 是 i7 3770K 3.50GHz 。
有些人也提到 alloca()
作為該補丁之一也是個解決方案,但是 alloca()
移植性不夠,只能作為一個孤立的解決方案,這意味著如果我們要使用它的話,需要寫一堆醜陋的 #ifdef
。
via: https://daniel.haxx.se/blog/2017/04/22/fewer-mallocs-in-curl/
作者:DANIEL STENBERG 譯者:geekpi 校對:wxy
本文轉載來自 Linux 中國: https://github.com/Linux-CN/archive