概述

简明扼要，本文主要分析及解决以下两个问题

1. 因操作系统缺少基础的动态库，比如libatomic 引起的编译和运行失败
2. 因操作系统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=yes
  endif
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的内存占用更高，但是在多核多线程下的表现也最为优异。