* GreatSQL社区原创内容未经授权不得随意使用，转载请联系小编并注明来源。

故障现象：

之前协助用户安装 GreatSQL 测试环境时，遇到一个 case，数据库初始化时没有报错，但是使用mysqld_safe
去启动，会直接 crash ,详情报错如下：

.....
<jemalloc>: Error in munmap():Invalid argument
2025-02-13T06:32:20.617961Z [System][MY-013576][InnoDB]InnoDB initialization has satrt.
<jemalloc>: Error in munmap():Invalid argument
2025-02-13T06:32:20Z - mysqld got signal 11;
most likely, you have hit a bug,but this error can also be caused by malfunctioning hardware.
.....

用户机器系统为 kylin uos-PC 4.19.17 arm64-desktop ,aarch 64 架构， 配置8C8GB。

问题分析：

查看系统报错日志 tail -n 10000 var/log/messages | grep memory
  没有明显报错；

网上查阅资料，mysqld got signal 11 
报错的相关信息很少，而且每个遇到signal 11
 导致crash 的原因并不相同，有的是磁盘满了，有的是内存问题等等问题。

我把重点放在了 <jemalloc>:Error in munmap():Invalid argument
 上。查阅jemalloc 官网，得知jemalloc 是一个内存管理器，可以优化内存分配策略、减少内存碎片、提升性能等方面。

查看GreatSQL源码，发现在 mysqld_safe
 上找到了 jemalloc 的踪迹：

...
# Add jemalloc to ld_preload if no other malloc forced - needed for TokuDB 
#
 if test $load_jemalloc -eq 1 
 then   
     for libjemall in "${MY_BASEDIR_VERSION}/lib/mysql" "/usr/lib64" "/usr/lib/x86_64-linux-gnu" "/usr/lib"; do     
     if [ -r "$libjemall/libjemalloc.so.1" ]; then                    add_mysqld_ld_preload "$libjemall/libjemalloc.so.1"       
     break     
     fi     
  done
fi 

进一步查看源码,发现参数  load_jemalloc=1
  ,也就是说使用 mysqld_safe
 去启动GreatSQL 时，默认使用jemalloc 进行内存管理。

查看用户机器的jemalloc 的信息：

strings lib/libjemalloc.so | grep JEMALLOC_VERSION
 ,发现没有信息打印;

再次尝试全局查找:

find -name jemalloc*
 , 没有找到相关软件。

至此断定,用户的PC端没有 jemalloc 的相关依赖。初步断定是由于缺少软件依赖造成的GreatSQL 服务没法启动。

问题调试

不妨假设如果不使用jemalloc 而改用其他内存管理方式呢？

尝试将 load_jemalloc=1
改成 load_jemalloc=0
 ，继续使用 mysqld_safe
 发现数据库能正常启动。

# ps -ef | grep greatsql
root      4521     1  0 15:07 ?        00:00:00 bin/sh greatsql/svr/greatsql/bin/mysqld_safe --defaults-file=/greatsql/conf/greatsql.cnf
greatsql   6176  4521  5 15:07 ?        00:00:02 greatsql/svr/greatsql/bin/mysqld --defaults-file=/greatsql/conf/greatsql.cnf --basedir=/greatsql/svr/greatsql --datadir=/greatsql/dbdata/data3306/data --plugin-dir=/greatsql/svr/greatsql/lib/plugin --user=greatsql --log-error=/greatsql/logs/error3306.log --pid-file=/greatsql/dbdata/data3306/data/greatsql.pid --socket=/greatsql/dbdata/data3306/data/greatsql.sock --port=3306

继续查看源码，发现如果将load_jemalloc 更改成disable (value=0),GreatSQL 会使用 glibc 默认的ptmalloc
 进行内存分配。

那如果改用 mysqld
方式启动，不使用 mysqld_safe
  去启动呢？

1. 更改回 mysqld_safe
    的默认值： load_jemalloc=1
    （控制变量）
2. 使用 mysqld --defaults-file=greatsql.cnf &
       去启动

发现数据库也能正常启动。

这时候不妨回顾一下mysqld_safe
和mysqld
的关系：

mysqld_safe 是一个在Unix上启动GreatSQL服务器推荐的方式，可以安全地启动，监控和重启mysqld 进程。

所以如果不指定 malloc_lib 的方式，mysqld
使用 glibc 默认ptmalloc
进行内存分配。

这时候就有疑问了，为了适配多环境，为什么不继续使用glibc默认的ptmalloc
而是使用jemalloc
 呢？

网上资料大多都是推荐摒弃 glibc 原生的 ptmalloc，而改用 jemalloc 或者 tcmalloc 作为默认分配器。ptmalloc 的主要问题是内存浪费、内存碎片、以及加锁导致的性能问题。

因为笔者对内存分配原理这块不是很了解，对这一块感兴趣的可以在网上查找相关的资料研究。

• ptmalloc、tcmalloc与jemalloc对比分析:https://www.cyningsun.com/07-07-2018/memory-allocator-contrasts.html

而根据以上的分析，更加推荐在缺少GreatSQL 相关软件依赖时 ，手动安装软件（如jemalloc 等）去启动GreatSQL,以提升数据库性能。

总结

• 对数据库必须的依赖建议放在前期检查里，可以参考相关文章：openEuler、龙蜥Anolis、统信UOS三大主流操作系统下编译GreatSQL二进制包:https://www.greatdb.com/Home/news/news_1/id/501.html
• mysqld_safe
   默认使用jemalloc
    进行内存分配
• mysqld
  使用glibc 默认的ptmalloc
   进行内存分配
• 有时候遇到没有头绪的故障时，可以尝试从源码找到蛛丝马迹，进行问题排查和调试

（对文章有疑问或见解可去社区官网提出哦~）

加入微信交流群	加入QQ交流群