我们接管了 2007 年至 2009 年间使用 Ruby 和 MySQL 实现的遗留系统，从那时起，只对其进行了必要的维护工作以保证其正常运行。
因此，就代码库而言，系统现在非常脆弱。事实上，由于一半的代码库使用一个版本的 Ruby，另一半使用另一个版本的 Ruby（这是我们的 Ruby 专家告诉我们的），我们在进行任何修改和部署到生产环境时都遇到了问题。
许多捷径导致系统的某些部分无法使用 - 例如一些管理查询需要几分钟才能完成，甚至超时。
我们目前正在用 .NET 重写该平台，但我们需要尽可能具体地评估当前设置可以容纳多少。
一个让我警觉的启发式方法是，当前生产的 MySQL 数据库目前为 15GB，并且由于自动安排的同步作业在数据库上写入大量审计日志，因此仍然处于阶段性增长的状态！
Linux 报告（通过/proc/cpuinfo）3xXeon E5420 @ 2.5GHz 处理器在不运行夜间作业时恒定负载为 30-50%。6GB RAM + 2GB 交换，其中只有 35MB 的内存是可用的，并且大部分交换都是可用的。
问题是：我们如何才能尽可能详细地评估当前设置将能承受多少压力？这显然必须在不进行负载测试的情况下完成，因为负载测试可能会导致服务器永久瘫痪。可以使用哪些启发式方法来生成估算值？
MySQL 数据库是否已知可以容纳 15GB 以上的大数据库？是否存在可靠性预计会大幅下降的已知点？
欢迎对问题调查提出任何其他见解。
答案1
我认为您关于 MySQL 可扩展性的问题与这个问题重复：
对于 MySQL 数据库来说，15GB 并不算大。但这并不意味着编写不佳的应用程序不会在该数据库上运行缓慢。TB 级的 MySQL 数据库并不罕见 - InnoDB 表的最大大小为 64TB
如果在过去 6 年中数据库仅增长到 15GB，我认为数据库增长不会成为重写应用程序所需时间的限制因素。应用程序将大概使用 30GB 数据库的运行速度与使用 15GB 数据库的运行速度差不多
但是，回答你的问题，如果你的负载通常为 30-50%，除非你有任何严重的 I/O 瓶颈（比如你可能在同步作业期间在数据库中创建大量审计日志），我猜你可能可以支持大约两倍的正常负载。这真的是一个猜测，因为它在很大程度上取决于你的应用程序实际在做什么，比如它对数据库的读取/写入量、数据库查询的效率如何（比如，是否有正确的索引）以及应用程序逻辑的复杂程度。
低“可用”内存可能没什么可担心的——这取决于您用来查找“可用”内存的实用程序，“可用”并不总是意味着“空闲”。Linux 将磁盘数据缓冲在未使用的内存中，随着时间的推移，此缓冲区缓存将变得非常大并占用程序未使用的大部分 RAM。但是，此内存在需要时随时可用，内核可以在软件需要时立即从 RAM 中删除缓存页面。为了更好地了解您有多少可用内存，请取总内存并减去“已用”内存。
如果您确实只剩下 35MB 的可用内存，我认为您将进行大量交换，性能会非常糟糕。在这种情况下，您需要对 MySQL 和/或 Web 服务器进行一些调整，以减少内存需求。但我不认为您处于这种情况，否则您会报告更多性能问题。