问题起源

同事反馈了一个现象，dgraph arm64的镜像在kylin v10（鲲鹏920s）上面运行时启动不了，提示：

1
2
3
4
5
6
7

<jemalloc>: Unsupported system page size
<jemalloc>: Unsupported system page size
fatal error: out of memory

goroutine 1 gp=0x40000041c0 m=0 mp=0x34a12e0 [running, locked to thread]:
runtime.throw({0x22aa92d?, 0x1?})
....

其实提示已经很明确了，就是jemalloc不支持这个page size，由于docker容器实际上是使用的宿主机linux kernel，所以明显这玩意是宿主机内核page size跟这个不匹配导致的，我们看看：

1
2

$ getconf PAGE_SIZE
65536

64K，默认大多数操作系统，特别是x86下的都是4k，这玩意如果是在64K下编译的，你放到4K的页面系统下能运行，反之则不行。

解决方法

有两个途径可以解决这个问题：

重新编译linux内核

参考这个（虽然细节肯定不同，但是大概步骤是一样的）： CentOS系统下内存页Page Size如何从64K切换到4K-操作系统-产品与技术常见问题-鲲鹏常见问题开发文档-鲲鹏社区

重新编译dgraph

具体步骤我就不说了，无非就是准备gmake环境、golang、jemalloc-devel、libstdc++-static、libstdc++-devel，然后编译打镜像

这个过程中编译的时候编译程序会从操作系统中读取当前的页面大小，所以就没问题了。

为什么要用jemalloc

按照我的经验，如果用标准glibc的malloc应该吊事没有，为什么dgraph需要使用jemalloc，这个文章解释了：

Manual Memory Management in Go using jemalloc - Dgraph Blog - Blog - Discuss Dgraph