共计 1102 个字符，预计需要花费 3 分钟才能阅读完成。
问
当 MySQL 内存异样上涨, 咱们能够通过 performance_schema 察看内存的应用, 咱们在 试验 5 中进行过介绍。
但咱们也会发现操作系统统计的 MySQL 内存用量比 performance_schema 统计的 MySQL 内存用量要多。
那么 MySQL 的内存耗费, 有哪些是不在 performance_schema 统计内的呢?
本期咱们设计试验来察看这个问题
试验
咱们先装置 google-perftools:
装置后, 能够找到相干的库:
宽油起一个数据库:
记下数据库的启动参数, 并关掉数据库:
咱们在数据库启动命令前, 减少两个环境变量 LD_PRELOAD 和 HEAPPROFILE.
其中 LD_PRELOAD 指向方才咱们装置的 tcmalloc 库, HEAPPROFILE 是输入文件的门路.
启动数据库后, 咱们看到日志中输入了两个 heap 文件.
咱们在数据库中减少一些压力, 还是用咱们相熟的翻倍法:
多做点数据:
察看到输入了更多的 heap 文件:
上面咱们装置 pprof 来解析这些 heap 文件.
先下载 golang , 此步骤须要挂代理:
装置 golang :
装置 pprof :
用 pprof 解析咱们方才生成的 heap 文件:
咱们让 pprof 生成一个 svg 文件, 咱们将 svg 文件放到 Chrome 中关上查看:
图比拟大, 每根线都标记了内存的调配流, 咱们用红色箭头标注了三个汇集点 (所有的连线都会流向这三个汇集点中的某一个).
其中 pfs_malloc 是能够被 performance_schema 跟踪的内存调配, 而其余两个汇集点则不能.
上面咱们将图的一部分放大, 举例来做个大抵介绍 (本图中咱们用红色箭头加强了原图的连线):
咱们能够看到有 16384.53kB 是 由 log_allocate_buffer 函数调用 ut_allocator 调配的, 这部分无奈被 performance_schema 跟踪到.
查看一下代码, 得悉 log_allocate_buffer 是依据 log_buffer_size 参数申请内存的:
查看参数, 证实 log_buffer_size 的配置与咱们在图中察看到的内存调配统一:
总结
本试验中, 咱们应用了 tcmalloc 作为 MySQL 的内存分配器, 并应用 tcmalloc 提供的 heap dump 性能, 追踪 MySQL 的内存调配。
通过内存调配图, 能让咱们直观地了解 MySQL 的内存调配:
咱们能够从中察看到 每一部分的内存 是从哪个代码门路进行调配的, 以及哪些内存是 performance_schema 能追踪到的。
此性能对性能影响不大, 能够在生产上比拟安稳的应用, 用于摸索生产环境的一些内存调配异样。
对于 MySQL 的技术内容，你们还有什么想晓得的吗？连忙留言通知小编吧！