MySQL：如何降低“最大可能内存使用量”？

Question

由于内存不足，我最近遇到了抖动问题。（我的VPS总共有256M）

我正在尝试使用 mysqltuner.pl 调整 MySQL，并获得以下结果：

-------- 一般统计 ---------------------------------------- ----------
[--] 跳过 MySQLTuner 脚本的版本检查
[OK] 目前运行支持的 MySQL 版本 5.0.51a-3ubuntu5.4-log
[OK] 在 64 位架构上运行

-------- 存储引擎统计 ------------------------------- ----
[--] 状态：+Archive -BDB -Federated -InnoDB -ISAM -NDBCluster 
[--] MyISAM 表中的数据：114M（表：454）
[!!] 总碎片化表：34

-  -  -  -  性能指标  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  - ---------
[--] 最多：40 秒（570 q [14.250 qps]，23 conn，TX：154K，RX：23K）
[--] 读/写：100%/0%
[--] 总缓冲区：338.0M 全局 + 2.7M 每个线程（20 个最大线程）
[!!] 最大可能内存使用量：392.9M（已安装 RAM 的 153%）
[OK] 慢查询：0% (5/570)
[OK] 可用连接的最高使用率：15% (3/20)
[!!] 密钥缓冲区大小/MyISAM 索引总数：8.0M/9.4M
[!!] 键缓冲区命中率：57.1%（7 次缓存 / 3 次读取）
[OK] 查询缓存效率：21.9% (7 cached / 32 selects)
[OK] 每天查询缓存修剪：0
[OK] 需要临时表的排序：0%（0 临时排序 / 1 排序）
[OK] 在磁盘上创建的临时表：0%（磁盘上 0 个/总共 32 个）
[OK] 线程缓存命中率：86%（创建 3 个 / 23 个连接）
[OK] 表缓存命中率：26%（128打开/484打开）
[OK] 使用的打开文件限制：25% (259/1K)
[OK] 立即获得表锁：100%（492 个立即/492 个锁）

-------- 建议 ----------------------------------------- ------------
一般建议：
    运行 OPTIMIZE TABLE 对表进行碎片整理以获得更好的性能
    MySQL 在过去 24 小时内启动 - 建议可能不准确
    减少您的整体 MySQL 内存占用以确保系统稳定性
要调整的变量：
  *** MySQL 的最大内存使用量非常高 ***
  *** 在增加 MySQL 缓冲区变量之前添加 RAM ***
    key_buffer_size (> 9.4M)

但是我对如何降低最大内存使用量感到有些困惑？它似乎基于 key_buffer 和 max_connections，但一定还涉及其他内容吗？

我的.cnf：

key_buffer = 8M
max_allowed_pa​​cket = 12M
线程堆栈 = 128K
线程缓存大小 = 8
最大连接数 = 20
表缓存= 128
tmp_table_size = 256M
max_heap_table_size = 256M
join_buffer_size = 256K
query_cache_limit = 8M
query_cache_size = 64M

我一直在尝试通读 MySQL 调优文章，但它们似乎面向那些已经知道自己在做什么的人！任何帮助，将不胜感激。谢谢！

Answer 1

你有一个 256M 的服务器，但你不能使用所有的东西——记住有一些操作系统开销。此外，正如其他人所提到的那样，您已经过度承诺了，而且您肯定会在这里大吃一惊。256M 仅适用于小型数据库，20 个连接对于您配置的内容来说已经很多了。

1）将您的最大连接数减少到 4 个（您使用了 20 个中的 3 个）

2) 更好地优化您的查询缓存；8M 真的很大，根据您的点击次数/修剪次数，总共 64M 很多；尝试 4/32 组合，看看效果如何。我真的认为 2/24 组合对你有用。

3) 你没有需要临时表的排序，为什么 max_heap_table_size 动词在那里？注释掉，使用默认值

4) 你真的有 128 张桌子吗？尝试将 table_cache 减半到 64 或 48

5) 减少 thread_cache_size 到 4

6）优化这些表以减少碎片

这些是一些事情开始。看起来您在配置中扔了一堆数字，而没有进行任何实际分析来了解您需要什么并造成了混乱；如果所有其他方法都失败了，请恢复默认设置并摆脱自定义设置，然后使用您可以在 Google 上找到的一些性能调整指南重新开始。获取 SHOW VARIABLES 和 SHOW STATUS 的输出，找到无数的调整指南中的任何一个，并将您的实际数字插入它们的方程，这将告诉您需要放入配置文件的确切数字。

Answer 2

我不是 MySQL 专家，我无法通过这些信息诊断问题，但我尝试在源代码中搜索公式。这里是：

server_buffers + total_per_thread_buffers * max_connections

在哪里：

server_buffers = key_buffer_size + innodb_buffer_pool_size + innodb_additional_mem_pool_size + innodb_log_buffer_size + query_cache_size

和：

total_per_thread_buffers = read_buffer_size + read_rnd_buffer_size + sort_buffer_size + thread_stack + max_allowed_packet + join_buffer_size

现在您必须检查这些值中的每一个，并找出哪个值对这个巨大的数字负责。并且不要毫无保留地相信这个脚本——我尝试在我的一台数据库服务器上运行它，它计算出最大内存是物理内存总量的 140%，但系统已经运行了多年，没有任何稳定性问题。

祝你好运！