Question

我有一个基于四核处理器的16 GiG RAM和4 TB硬盘用于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

更重要的问题

由于你的buffer_pool有一个“小”的6G，所以令人费解的是为什么RAM太满了。
不涉及复制，对吗？
为什么innodb_max_dirty_pages_pct设置为零？通常为75（％）。我希望你会遭受很多I / O.
iblogs旋转非常迅速。这是因为活动量很大，而且非常小log_file_size = 5M。改为1G;但请注意：更改它很复杂，需要重新启动。
每秒创建6K tmp表。 3K表扫描/秒。这些暗示某些索引或查询调优可能有用。
您似乎在连接中的流量非常低，因此下面关于线程和连接的评论可能并不重要。
Aborted_connects / Connections = 98.8％。（最多20％是'确定'。）

你有RAM磁盘吗？多大？我通常反对这样的观点。但是，如果你有一个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＆amp; 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” - ＆gt; 2000 可能压力服务器

( Queries ) = 85,684,886,985 / 278186 = 308012 /sec - 查询（包括SP内部） - ＆gt; 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% - 选择进行全表扫描的百分比。（可能被Stored Routines愚弄了。） - 添加索引/优化查询

( 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 /秒都非常相似（3009 /秒）。只有一个程序，它被称为很多？

Innodb_rows_inserted = 622 /秒。

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

MariaDB内存使用率过高

1 个答案: