lnmp一键安装包安装系统的时候一般用Jemalloc
TCMalloc
优点：很多系统都可以用源来安装 TCMalloc ，而且支持的 gcc 编译库比较新。
缺点：软件是在 Google Perftools 下的，安装的时候如果不编译好可能会安装到我们不需要的其他软件，而且 Google Perftools 安装过程比较复杂还需要安装相应的库。
Jemalloc
优点：目前是 Maridab 、Tengine、Redis 中默认推荐的内存优化工具，所以使用 Jemalloc 对这些程序的兼容度还是比较高的。而且经过测试高负载情况下 Jemalloc 更加优秀。安装过程方便，不用安装额外的库。
缺点：对使用最新的gcc编译不友好。
redis有用到jemalloc。
首先，jemalloc是干什么的？
我们看看作者自己的介绍：
jemalloc is a general purpose malloc(3) implementation that emphasizes fragmentation avoidance and scalable concurrency support
意思是说jemalloc干了malloc干的活，而且干得好一些，主要体现在避免内存碎片与并发扩展上。
首先，什么是内存碎片？
malloc/free或new/delete大量使用后回造成内存碎片，那么这种碎片形成的机理是什么？
如果机理是申请的内存空间大小（太小）所形成的，那么，申请多大的区域能够最大限度的避免内存碎片呢？（这里的避免不是绝对的避免，只是一种概率）
内存碎片一般是由于空闲的连续空间比要申请的空间小，导致这些小内存块不能被利用。产生内存碎片的方法很简单，举个例：
假设有一块一共有100个单位的连续空闲内存空间，范围是0~99。如果你从中申请一块内存，如10个单位，那么申请出来的内存块就为0~9区间。这时候你继续申请一块内存，比如说5个单位大，第二块得到的内存块就应该为10~14区间。
如果你把第一块内存块释放，然后再申请一块大于10个单位的内存块，比如说20个单位。因为刚被释放的内存块不能满足新的请求，所以只能从15开始分配出20个单位的内存块。
现在整个内存空间的状态是0~9空闲，10~14被占用，15~24被占用，25~99空闲。其中0~9就是一个内存碎片了。如果10~14一直被占用，而以后申请的空间都大于10个单位，那么0~9就永远用不上了，造成内存浪费。
如果你每次申请内存的大小，都比前一次释放的内村大小要小，那么就申请就总能成功。
内存碎片很可怕吗？
短时间内不明显，对于线上的服务器比如nginx,运行时间可能经年，每天几亿的请求量，如果每天产生100片 ，一年下来也是3万多片 ，相当恐怖！
jemalloc可以有效的解决这个问题！
使用jemalloc或tcmalloc可以有效提升mysql的性能，强烈建议大家可以尝试。
简化后的步骤如下：
1. yum -y install autoconf make
2. 安装 jemalloc
wget http://www.canonware.com/download/jemalloc/jemalloc-3.6.0.tar.bz2
tar -xjf jemalloc-3.6.0.tar.bz2
cd jemalloc-3.6.0
./configure --prefix=/usr/local/jemalloc --libdir=/usr/local/lib
make && make install
3.my.cnf中添加配置，并重启mysql（mysql 5.5+）
[mysqld_safe]
malloc-lib=/usr/local/lib/libjemalloc.so
4.验证是否生效
lsof -n | grep jemalloc
cmalloc
tcmalloc是Google开源的一个内存管理库， 作为glibc malloc的替代品。目前已经在chrome、safari等知名软件中运用。
根据官方测试报告，ptmalloc在一台2.8GHz的P4机器上（对于小对象）执行一次malloc及free大约需要300纳秒。而TCMalloc的版本同样的操作大约只需要50纳秒。
小对象分配
tcmalloc为每个线程分配了一个线程本地ThreadCache，小内存从ThreadCache分配，此外还有个中央堆（CentralCache），ThreadCache不够用的时候，会从CentralCache中获取空间放到ThreadCache中。
小对象（<=32K）从ThreadCache分配，大对象从CentralCache分配。大对象分配的空间都是4k页面对齐的，多个pages也能切割成多个小对象划分到ThreadCache中。
tcmalloc小对象类型链表
小对象有将近170个不同的大小分类(class)，每个class有个该大小内存块的FreeList单链表，分配的时候先找到best fit的class，然后无锁的获取该链表首元素返回。如果链表中无空间了，则到CentralCache中划分几个页面并切割成该class的大小，放入链表中。
CentralCache分配管理
大对象(>32K)先4k对齐后，从CentralCache中分配。 CentralCache维护的PageHeap如下图所示， 数组中第256个元素是所有大于255个页面都挂到该链表中。
tcmalloc-pageheap
当best fit的页面链表中没有空闲空间时，则一直往更大的页面空间则，如果所有256个链表遍历后依然没有成功分配。 则使用sbrk, mmap, /dev/mem从系统中分配。
tcmalloc PageHeap管理的连续的页面被称为span.
如果span未分配， 则span是PageHeap中的一个链表元素
如果span已经分配，它可能是返回给应用程序的大对象， 或者已经被切割成多小对象，该小对象的size-class会被记录在span中
在32位系统中，使用一个中央数组(central array)映射了页面和span对应关系， 数组索引号是页面号，数组元素是页面所在的span。 在64位系统中，使用一个3-level radix tree记录了该映射关系。
回收
当一个object free的时候，会根据地址对齐计算所在的页面号，然后通过central array找到对应的span。
如果是小对象，span会告诉我们他的size class，然后把该对象插入当前线程的ThreadCache中。如果此时ThreadCache超过一个预算的值（默认2MB），则会使用垃圾回收机制把未使用的object从ThreadCache移动到CentralCache的central free lists中。
如果是大对象，span会告诉我们对象锁在的页面号范围。 假设这个范围是[p,q]， 先查找页面p-1和q+1所在的span，如果这些临近的span也是free的，则合并到[p,q]所在的span， 然后把这个span回收到PageHeap中。
CentralCache的central free lists类似ThreadCache的FreeList，不过它增加了一级结构，先根据size-class关联到spans的集合， 然后是对应span的object链表。如果span的链表中所有object已经free， 则span回收到PageHeap中。
tcmalloc的改进
ThreadCache会阶段性的回收内存到CentralCache里。 解决了ptmalloc2中arena之间不能迁移的问题。
Tcmalloc占用更少的额外空间。例如，分配N个8字节对象可能要使用大约8N * 1.01字节的空间。即，多用百分之一的空间。Ptmalloc2使用最少8字节描述一个chunk。
更快。小对象几乎无锁， >32KB的对象从CentralCache中分配使用自旋锁。 并且>32KB对象都是页面对齐分配，多线程的时候应尽量避免频繁分配，否则也会造成自旋锁的竞争和页面对齐造成的浪费。
性能对比
官方测试
测试环境是2.4GHz dual Xeon，开启超线程，redhat9，glibc-2.3.2, 每个线程测试100万个操作。
尤其是对于小内存的分配， tcmalloc有非常明显性能优势。
随着线程数的增加，tcmalloc性能上也有明显的优势，并且相对平稳。
github mysql优化
github使用tcmalloc后，mysql性能提升30%
Jemalloc
jemalloc是facebook推出的， 最早的时候是freebsd的libc malloc实现。 目前在firefox、facebook服务器各种组件中大量使用。
jemalloc原理
与tcmalloc类似，每个线程同样在<32KB的时候无锁使用线程本地cache。
Jemalloc在64bits系统上使用下面的size-class分类：
Small: [8], [16, 32, 48, …, 128], [192, 256, 320, …, 512], [768, 1024, 1280, …, 3840]
Large: [4 KiB, 8 KiB, 12 KiB, …, 4072 KiB]
Huge: [4 MiB, 8 MiB, 12 MiB, …]
small/large对象查找metadata需要常量时间， huge对象通过全局红黑树在对数时间内查找。
虚拟内存被逻辑上分割成chunks（默认是4MB，1024个4k页），应用线程通过round-robin算法在第一次malloc的时候分配arena， 每个arena都是相互独立的，维护自己的chunks， chunk切割pages到small/large对象。free()的内存总是返回到所属的arena中，而不管是哪个线程调用free()。
可以看到每个arena管理的arena chunk结构， 开始的header主要是维护了一个page map（1024个页面关联的对象状态）， header下方就是它的页面空间。 Small对象被分到一起， metadata信息存放在起始位置。 large chunk相互独立，它的metadata信息存放在chunk header map中。
通过arena分配的时候需要对arena bin（每个small size-class一个，细粒度）加锁，或arena本身加锁。
并且线程cache对象也会通过垃圾回收指数退让算法返回到arena中。
jemalloc Arena and thread cache layout
jemalloc的优化
Jmalloc小对象也根据size-class，但是它使用了低地址优先的策略，来降低内存碎片化。
Jemalloc大概需要2%的额外开销。（tcmalloc 1%， ptmalloc最少8B）
Jemalloc和tcmalloc类似的线程本地缓存，避免锁的竞争
相对未使用的页面，优先使用dirty page，提升缓存命中。
4.3.2 mysql优化
测试环境：2x Intel E5/2.2Ghz with 8 real cores per socket，16 real cores， 开启hyper-threading， 总共32个vcpu。 16个table，每个5M row。
OLTP_RO测试包含5个select查询：select_ranges, select_order_ranges, select_distinct_ranges, select_sum_ranges,
在多核心或者多线程的场景下， jemalloc和tcmalloc带来的tps增加非常明显。
参考资料
glibc内存管理ptmalloc源代码分析
Inside jemalloc
tcmalloc浅析
tcmalloc官方文档
Scalable memory allocation using jemalloc
mysql-performance-impact-of-memory-allocators-part-2
ptmalloc,tcmalloc和jemalloc内存分配策略研究
Tick Tock, malloc Needs a Clock
总结
在多线程环境使用tcmalloc和jemalloc效果非常明显。
当线程数量固定，不会频繁创建退出的时候， 可以使用jemalloc；反之使用tcmalloc可能是更好的选择。
