文章目錄

• 概述
• JEMALLOC
• 內存碎片
• Redis 中的 Jemalloc
• libatomic 缺失，引起的編譯失敗
• [jemalloc] unsupported system page size
• 擴展
• 小結

---

概述

簡明扼要，本文主要分析及解決以下兩個問題

因操作系統缺少基礎的動態庫，比如libatomic 引起的編譯和運行失敗

因操作系統PAGE SIZE差異，導致的啟動報錯 [jemalloc] unsupported system page size

---

JEMALLOC

我們先看JEMALLOC

JEMALLOC是什么呢？

github： https://github.com/jemalloc/jemalloc

jemalloc is a general purpose malloc(3) implementation that emphasizes fragmentation avoidance and scalable concurrency support

通俗來說，也是內存管理算法， 但是在避免內存碎片與并發擴展要好

內存分配器ptmalloc,jemalloc,tcmalloc調研與對比

---

內存碎片

既然在jemalloc避免內存碎片與并發擴展要好， 那什么是內存碎片呢？

假設一個簡單的玩具示例，你有10個字節的內存：

| | | | | | | | | | |0 1 2 3 4 5 6 7 8 9

現在讓我們分配三個三字節塊，名稱A，B和C：

| A | A | A | B | B | B | C | C | C | |0 1 2 3 4 5 6 7 8 9

現在解除分配塊B：

| A | A | A | | | | C | C | C | |0 1 2 3 4 5 6 7 8 9

現在如果我們嘗試分配一個四字節的塊D會發生什么？

雖然內存空間里有四個字節的內存空閑，但沒有四個連續的內存字節，所以不能分配D！同時，也不能移動C來騰出空間，因為程序中的某些變量很可能指向C，所以我們無法自動查找和更改所有這些值。

---

Redis 中的 Jemalloc

Redis在2.4及2.4以后的版本中，內存管理默認使用Facebook開源的jemalloc

我們從源碼中的Makefile文件可以看到

ifeq ($(uname_S),Linux)ifneq ($(FORCE_LIBC_MALLOC),yes)USE_JEMALLOC=yesendif endif

如果是Linux操作系統，且沒有強制使用GLIBC ， 則使用JEMALLOC

你如果找2.4.0之前版本的MakeFile ,是沒有這個邏輯的。

---

libatomic 缺失，引起的編譯失敗

運行時動態庫的搜索路徑的先后順序是：

• 1）編譯目標代碼時指定的動態庫搜索路徑；
• 2）環境變量LD_LIBRARY_PATH指定的動態庫搜索路徑；
• 3）配置文件/etc/ld.so.conf中指定的動態庫搜索路徑；
• 4）默認的動態庫搜索路徑/lib和/usr/lib；

5.0.8 及 5.0.8以后的版本中，redis源碼中的Makefile ,增加了這么一段邏輯

ARM架構(V8 ，V6)下 ，使用libatomic。

那怎么解決呢？

如果必須使用，則需要將對應的 rpm包安裝以后， /usr/lib64建立軟連接

然后，make distclean 后再 make

5.0.7 及 5.0.7 一下版本，未使用到

---

[jemalloc] unsupported system page size

3個常見的頁大小

• 4096 4k
• 16384 16K
• 65536 64k

4K環境上編譯的，無法在16和64上運行，
反之可以。

為避免出問題，建議統一在64K的 機器上編譯

getconf PAGESIZE 可查看頁大小

---

擴展

Google TCMalloc：Thread-Caching Malloc

https://github.com/google/tcmalloc

---

小結

• 作為基礎庫的ptmalloc是最為穩定的內存管理器，無論在什么環境下都能適應，但是分配效率相對較低。
• tcmalloc針對多核情況有所優化，性能有所提高，但是內存占用稍高，大內存分配容易出現CPU飆升。
• jemalloc的內存占用更高，但是在多核多線程下的表現也最為優異。

總結

以上是生活随笔為你收集整理的Redis - 适配全国产操作系统的那些坑的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。