如何计算一个数据库需要多少硬件资源？

Question

我们正在扩展我们的数据库服务器。我想知道我们应该如何计算我们的数据库需要多少硬件资源？

以下是有关我们当前数据库服务器的一些信息：

• MySQL 数据库
• 所有表的 InnoDB
• 约80桌
• 最大的表是：15 GB、13 GB、12 GB、5 GB，其余小于 1 GB
• 磁盘上的数据库大小为 175 GBibdata1和 56 GB 没有它
• 数据库每月增长约 10%——12 个月前约为 5-6%
• 大约 60 个连接在正常使用中运行
• InnoDB 缓冲区大小为 24 GB 中的 16 GB，利用率为 99%
• CPU 使用率在 2.27GHz Intel Xeon 8 核 L5520 上约为 30%
• 我们有大约 33% 的写入和 66% 的读取
• 根据下面的代码片段，我们有大约 2.31 TPS 和 1126 QPS——QPS 似乎在 750 和 1500 之间上下波动

.

use information_schema;
select VARIABLE_VALUE into @num_queries from GLOBAL_STATUS where VARIABLE_NAME = 'QUESTIONS';
select VARIABLE_VALUE into @uptime from GLOBAL_STATUS where VARIABLE_NAME = 'UPTIME';
select VARIABLE_VALUE into @num_com from GLOBAL_STATUS where VARIABLE_NAME = 'COM_COMMIT';
select VARIABLE_VALUE into @num_roll from GLOBAL_STATUS where VARIABLE_NAME = 'COM_ROLLBACK';
select (@num_com + @num_roll) / @uptime as tps, @num_queries / @uptime as qps;

我们当前的服务提供商为我们提供以下升级：

• 主动/被动设计（2台服务器，每台如下所述）
• 单处理器，八核 Intel Xeon E5-2630 v3 2.4Ghz
• 64 GB 内存
• RAID 1; 300 GB 12 Gbps (15K SAS 2.5") x 2

我的问题是：

1. 我怎么知道这是否是矫枉过正？尽管这显然是一次巨大的升级，但我想知道这是否是我们真正需要的，它不会浪费资源或不明显的性能提升。感谢任何公式、文章或书籍推荐。
2. 鉴于我们当前的数据库详细信息，是否有任何自动化工具可以帮助我们找出我们可能需要多少资源，假设一年后？

更新 #1

显示变量

显示全局变量

显示全球状态

RIAD 控制器

• 戴尔 PERC 6i；RAID 5
• 写策略：直写和回写
• 缓存内存大小：256 MB

Answer 1

简短的回答：不能说。没有足够的信息。

长答案...

如果您的数据以每月 10% 的速度增长，则大约需要一年时间才能达到 64/24 倍。因此，如果您将 RAM 和 buffer_pool 增加 64/24，您可能会拥有与 buffer_pool 相同的缓存性能。仅仅一年之后。

除了您的工作集至少为 16GB 之外，99% 的利用率并没有真正说明任何其他内容。这并不奇怪，因为数据集比这大得多。

30% CPU 意味着你在任何时候平均有 1.3 个内核在运行？如果是这样，那么我怀疑您有一些缓慢的查询。让我们来看看它们是否可以改进。幸运的是，修复几个查询可能会延迟对更强大机器的需求。

8 个内核（与 1.3 相比）表示您可能拥有大量内核。但是你可能会超过你目前的 4。

由于您需要移动所有数据，我强烈建议innodb_file_per_table=1在开始移动之前在新机器上进行设置。（我假设您使用的是 InnoDB。）

移动时升级 MySQL。

不要设置query_cache_size大于50M；这可能是高 CPU 的来源。如果您“一直”写入所有表，那么最好完全关闭查询缓存。（这可能是阻止购买的另一种方式。）

您现在使用的 I/O 容量百分比是多少？

新的 RAID 会有电池供电的写缓存吗？这使得写入几乎免费。

如果您需要更多分析，请提供

RAM size (currently 24GB)
SHOW VARIABLES;
SHOW GLOBAL STATUS;   -- STATUS, not VARIABLES.

附录 - 变量和状态的审查

**观察

版本：5.6.13-log 24 GB RAM 您在 Windows 上运行。运行 64 位版本 您似乎完全（或大部分）运行 InnoDB。

更重要的问题

• innodb_buffer_pool_size 应该增加到大约 70% 的 RAM。

• 将 innodb_log_file_size 增加到 300M 左右。幸运的是，从 5.6.8 开始这更容易了

• 对频繁更改的数据库做一些事情（“USE”）；请参阅下面的 Com_change_db。

• read_buffer_size = 128K

• 看看将多个语句聚集到事务中是否有意义。

• 处理缓慢的查询。

细节

( innodb_buffer_pool_size / _ram ) = 12,884,901,888 / 24576M = 50.0% -- 用于 InnoDB buffer_pool 的 RAM 百分比 ( (Innodb_buffer_pool_reads + Innodb_buffer_pool_pages_flushed) ) = ((2518181510) / 251815104000000000秒增加innodb_buffer_pool_size？

( Innodb_log_writes ) = 306,041,138 / 1821852 = 167 /秒

( Uptime / 60 * innodb_log_file_size / Innodb_os_log_written ) = 1,821,852 / 60 * 48M / 314550301184 = 4.86 -- InnoDB 日志轮换之间的分钟数 从 5.6.8 开始，可以动态更改；一定也要更改my.cnf。--（轮换间隔60分钟的建议有点武断。）调整innodb_log_file_size。

( tmp_table_size ) = 179M --用于支持 SELECT的MEMORY临时表的大小限制-- 减少 tmp_table_size 以避免耗尽 RAM。也许不超过64M。

( Handler_read_rnd_next ) = 766,168,067,814 / 1821852 = 420543 /sec -- 如果有大量表扫描，则高 ( Select_full_join ) = 29,673,902 / 1821852 = 16 /sec -- 无索引的全表连接，87 / 21, 87 / 197 / 19 scans ( Select_scan / Com_select ) = 70,915,674 / 771524414 = 9.2% -- 执行全表扫描的选择百分比。（可能会被存储的例程所迷惑。）（ Created_tmp_tables ）= 75/sec -- 添加索引/优化查询

( Com_insert + Com_delete + Com_delete_multi + Com_replace + Com_update + Com_update_multi ) = (30050199 + 842 + 264 + 0 + 287315111 + 278) / 1821852 = 174 /sec - 最大写入/秒可能会刷新5次日志/秒out 普通驱动器的 I/O 写入容量

( long_query_time ) = 10.000000 = 10 -- 定义“慢”查询的截止时间（秒）。-- 建议 2

( Com_change_db / Connections ) = 953,574,484 / 23878 = 39,935 -- 每个连接的数据库切换 ( Com_change_db ) = 953,574,484 / 1821852 = 523 /sec -- 可能来自 USE 语句。-- 考虑与 DB 连接，使用 db.tbl 语法，消除虚假的 USE 语句等。 ( Com_admin_commands ) = 523/sec -- 管理命令 -- 某些 3rd 方是否会干扰流量？

( Threads_created / Connections ) = 1,339 / 23878 = 5.6% -- 进程创建的速度 -- 增加 thread_cache_size (non-Windows)

( read_buffer_size ) = 65536 -- http://dev.mysql.com/doc/refman/5.6/en/server-system-variables.html#sysvar_read_buffer_size -- 128K 可能更好，这取决于难以预测的事情这点。

附录 2 - 回到问题

一般来说，按照您提到的方向进行缩放似乎对您很有效。

• 你现在似乎跑得很好。
• 我列举了几件可以帮助你用你所拥有的生活一小段时间的东西。
• 一个艰难的：摆脱不必要的 3rd-party-isms（change_db 等）
• 难点：定位慢查询并改进它们
• 您已经拥有最新的 5.6，因此在 8 核上处理更多连接应该很容易。
• 有很多 InnoDB I/O，但没有任何迹象表明缓存“低效”。使用更多内存时，最重要的更改将是 innodb_buffer_pool_size（到可用内存的 70%）。
• 如果您以 10%/月的速度增长，从现在起一两年，您会很高兴拥有“巨大的升级”，而不必再次升级。

有一件事让我担心......您现在正处于普通驱动器的峰值容量。（我看到来自 InnoDB 的 110 IOP。）如果增长 10%，您可能首先会耗尽 I/O 容量。你的新配置只有一点帮助。替代方案：RAID-5（条带化和奇偶校验，但至少需要 3 个驱动器）或 SSD（更昂贵）。