We've taken over a legacy system that was implemented between 2007-2009 in Ruby and MySQL and since then has had only maintenance work done on it that was necessary to keep it alive.
As a result, the system is now very fragile in terms of its code base. In fact, since half the code base is in one version of Ruby and the other half is in another (this is what our Ruby guy tells us), we have been having problems making any modifications and deploying to production.
Many of the shortcuts taken have made parts of the system unusable - such as some administration queries taking several minutes to complete, or even times out.
We are currently in the process of rewriting the platform in .NET but we need to assess with as much specificity as possible how much the current setup can hold.
One heuristic that raised a red flag for me is that the current production MySQL database is 15GB at the moment and still phases growth because of automatically scheduled sync jobs that write huge audit logs on the database!
Linux reports (through
/proc/cpuinfo) 3xXeon E5420 @ 2.5GHz processors at constant 30-50% load when not running nightly jobs. 6GB of RAM + 2GB swap, out of which only 35MB of mem is free and most of swap is free.
The question is: how can we assess in as much detail as possible how much the current setup will hold? This obviously must be done without doing say, a load test, which could bring the server down for good. What heuristics can use to produce an estimate?
Are MySQL databases known to hold databases as large as 15GB+? Is there a known point where reliability is expected to drop significantly?
Any other insights into the investigation of the problem are welcome.