问题描述
我阅读了很多关于这个问题的问题，但我仍然不确定我的问题是否应该通过安装新的内存分配器来解决，或者这种情况是否可以通过更改应用程序代码/my.cfn 来解决。
MysqL 版本：5.6.49
GLIBC 2.24-11
Debian 9
配置：一主二从。
所有三台服务器都显示相同的问题：MysqLd 进程分配的内存正在增加，达到很高的值，在主服务器上，我在 2 个月内已经有 2 次进程崩溃，被 OS 杀死，导致 OOM。
SHOW GLOBAL STATUS：
link
SHOW VARIABLES：
link
有人可以看看并给我意见吗？ 谢谢！
更新
输出命令 ulimit -a
core file size (blocks,-c) 0
data seg size (kbytes,-d) unlimited
scheduling priority (-e) 0
file size (blocks,-f) unlimited
pending signals (-i) 297637
max locked memory (kbytes,-l) 64
max memory size (kbytes,-m) unlimited
open files (-n) 1024
pipe size (512 bytes,-p) 8
POSIX message queues (bytes,-q) 819200
real-time priority (-r) 0
stack size (kbytes,-s) 8192
cpu time (seconds,-t) unlimited
max user processes (-u) 297637
virtual memory (kbytes,-v) unlimited
file locks (-x) unlimited
目前我无法提供 iostats 的详细信息和磁盘类型，如果我可以获得这些信息，我会询问管理员。
解决方法
您的 ulimit -a 报告表明打开文件限制为 1024。在您的操作系统命令提示符下，ulimit -n 2000000 将动态启用最多 2m 打开文件。
为了让这个值在 OS 停止/启动时保持不变，这个 URL 是一个指南，请使用 2000000 而不是他们记录的 500000 示例。 https://glassonionblog.wordpress.com/2013/01/27/increase-ulimit-and-file-descriptors-limit/ 您的操作系统版本可能存在差异。
每秒速率 = RPS 为您的 my.cnf [mysqld] 部分考虑的建议
innodb_lru_scan_depth=100 # from 1024 to conserve 90% of CPU cycles used every second for the function.
read_rnd_buffer_size=128K # from 2M to reduce handler_read_rnd_next RPS of 99,013
open_files_limit=1400000 # from 5000 to accomodate your 2000 db * 300 tbls per db with spares
table_open_cache_instances=32 # from 1 to reduce mutex contention opening tables
innodb_open_files=1000000 # from 959 to reduce opened_tables RPHr of 518,279
table_open_cache=1000000 # from 959 should always match innodb_open_files
table_definition_cache=100000 # from 32768 to support opened_table_definitions RPHr of 11,039 ~ 10 hours
请发布用于“连接”、处理、“关闭”数据库连接的代码以供分析。听起来好像缺少关闭允许 RAM 增长直到 OOM。
还有更多改进实例性能的机会。请查看配置文件、网络配置文件以获取联系信息以及可免费下载的实用程序脚本以协助性能调整。