mysql - MariaDB 内存使用过多

Question

我有一个基于四核处理器的 16 GiG RAM 和 4 TB HDD 用于 DB 和 4 TB 用于 OS。
分配的缓冲池为 6 GB。也尝试了 70% 的内存，但结果是一样的。
内存很快就被填满了。当我重新启动服务时，它被释放，但在不到 20 分钟的时间内，10-15% 的空间被填满。

我的 my.conf 配置:

[client]
socket=/db/mysql/mysql.sock

[mysqld]
datadir=/db/mysql
socket=/db/mysql/mysql.sock

innodb_max_dirty_pages_pct = 0
innodb_file_per_table = 1
innodb_buffer_pool_size = 6G
innodb_buffer_pool_instances = 6
thread_cache_size = 4
innodb_flush_log_at_trx_commit = 2
innodb_flush_method = O_DIRECT
innodb_flush_log_at_trx_commit = 2
innodb_flush_method = O_DIRECT
query_cache_type = 0
innodb_fast_shutdown=0

[mysqld_safe]
log-error=/var/log/mariadb/mariadb.log
pid-file=/var/run/mariadb/mariadb.pid

也附上我的内存使用图。






重要引用:

显示变量 - pastebin.com/wzAhva55
显示全局状态 - pastebin.com/8G1N3g78

Answer 1

观察:

Version: **5.5.50-MariaDB**
**16 GB** of RAM
Uptime = **3d 05:16:26**
You are **not** running on Windows.
Running **64-bit** version
You appear to be running entirely (or mostly) **InnoDB**.
20 issues flagged, out of 145 computed Variables/Status/Expressions checked

更重要的问题

既然你有一个“小”的 6G 用于 buffer_pool，那么为什么 RAM 如此满是令人费解的。

不涉及复制，对吗？

为什么是 innodb_max_dirty_pages_pct设置为零？通常为 75 (%)。我希望你会遭受很多 I/O。

iblog 的旋转速度非常快。这是因为活跃度高，加上极小的 log_file_size = 5M .将其更改为 1G；但要注意:更改它很复杂，并且需要重新启动。

每秒创建 6K tmp 表。 3K 表扫描/秒。这意味着某些索引或查询调优可能有用。

您似乎在连接方面的周转率非常低，因此下面关于线程和连接的评论可能并不重要。

Aborted_connects/Connections = 98.8%。 (最多 20% 是“好的”。)

你有内存盘吗？多大？我通常反对这种做法。但是，如果您有一个 RAM 磁盘，那就可以解释高内存使用率、高查询率以及看似低 I/O 的问题。

细节和其他观察
( innodb_buffer_pool_size / _ram ) = 6,442,450,944 / 16384M = 37.5% -- 用于 InnoDB buffer_pool 的 RAM 百分比
( open_files_limit ) = 1,024 -- ulimit -n
-- 要允许更多文件，请更改 ulimit 或/etc/security/limits.conf 或 sysctl.conf (kern.maxfiles & kern.maxfilesperproc) 或其他内容(取决于操作系统)另一方面， Open_table*值非常低，因此您似乎使用的表很少。
( innodb_max_dirty_pages_pct ) = 0 -- 当 buffer_pool 开始刷新到磁盘时
——你在做实验吗？
( Innodb_log_writes ) = 26,966,874 / 278186 = 97 /sec ( Innodb_os_log_written / (Uptime / 3600) / innodb_log_files_in_group / innodb_log_file_size ) = 253,091,451,392 / (278186 / 3600) / 2 / 5M = 312 - 比率
( Uptime / 60 * innodb_log_file_size / Innodb_os_log_written ) = 278,186 / 60 * 5M / 253091451392 = 0.096 -- InnoDB 日志轮换之间的分钟数从 5.6.8 开始，可以动态更改；请务必同时更改 my.cnf。
-- (轮换间隔 60 分钟的建议有些随意。)调整 innodb_log_file_size。
( Questions ) = 889,470,233 / 278186 = 3197 /sec -- 查询(SP 外) -- “qps”
-->2000 可能是服务器压力
( Queries ) = 85,684,886,985 / 278186 = 308012 /sec -- 查询(包括 SP 内部)
-->3000 可能是服务器压力
( (Queries-Questions)/Queries ) = (85684886985-889470233)/85684886985 = 99.0% -- 存储例程内的查询部分。
--(如果高也不错；但它会影响其他一些结论的有效性。)
( Created_tmp_tables ) = 1,674,262,702 / 278186 = 6018 /sec -- 创建“临时”表作为复杂 SELECT 的一部分的频率。
( Select_scan ) = 837,131,930 / 278186 = 3009 /sec -- 全表扫描
-- 添加索引/优化查询(除非它们是小表)
( Select_scan / Com_select ) = 837,131,930 / 2511393099 = 33.3% -- % 的选择进行全表扫描。 (可能会被存储的例程愚弄。)
-- 添加索引/优化查询
( Com_insert + Com_delete + Com_delete_multi + Com_replace + Com_update + Com_update_multi ) = (837130735 + 0 + 0 + 0 + 0 + 0) / 278186 = 3009 /sec -- 写入/秒
-- 50 次写入/秒 + 日志刷新可能会最大化普通驱动器的 I/O 写入容量
( expire_logs_days ) = 0 -- 多久自动清除 binlog(经过这么多天)
-- 太大(或为零)= 消耗磁盘空间；太小 = 需要快速响应网络/机器崩溃。
(如果 log_bin = OFF，则不相关)
( long_query_time ) = 10.000000 = 10 -- 用于定义“慢”查询的截止时间(秒)。
-- 建议 2
( Aborted_connects / Connections ) = 11,455 / 11594 = 98.8% ——也许黑客正试图闯入？
( thread_cache_size ) = 4 -- 要保留多少额外进程(使用线程池时不相关)(自 5.6.8 起自动调整；基于 max_connections)

更多
Select_scan / Com_select如此接近 1/3，以至于您在执行的查询中有很强的模式令人怀疑。也许有可以避免的重复？同样， Com_set_option/Queries非常接近1/6。
Handler_read*与查询数量相比，值非常小。

嗯... Select_scan/秒， Com_call_procedure/秒，和 Com_insert/sec 都非常相似(3009/sec)。只有一个程序，它被称为很多？
Innodb_rows_inserted = 622/秒。

抱歉，此分析大部分针对的是性能，而不是内存。我确实想出了一个内存想法。我猜ramdisk是4-5G？