More CPU cores do not help much when Strategy Tester agents are waiting for memory, paging to disk, or competing for the same RAM pool.
This usually happens when you increase symbols, time ranges, agent count, or optimization depth faster than available memory grows. The result is slower passes, less predictable timing, and a server that looks busy without finishing work efficiently.
Quick answer: MT5 optimization becomes RAM-bound when the combined memory demand of local or remote agents, historical data, caches, Windows overhead, and logs exceeds real available RAM, which pushes the workload into paging and makes CPU scaling fall apart.
Optimization throughput often stops improving before CPU usage reaches a clean, stable ceiling because memory contention starts to dominate.
Adding more agents without enough RAM can make the run slower, not faster, especially when multiple symbols and long history ranges are loaded at once.
Move from a light MetaTrader VPS to a dedicated server for MetaTrader, or distribute the load with an EPYC backtest farm.
Why This Happens
A small live trading setup may fit comfortably on a normal Windows VPS for MetaTrader, but optimization is a different workload. Once Strategy Tester begins loading more history, more symbol combinations, and more concurrent agents, RAM becomes a hard capacity limit. That is one reason serious research setups often grow into a dedicated MetaTrader server or an MT5 backtest farm.
Decision Table
The goal is not to guess an exact gigabyte number in isolation. The useful question is whether the machine still has enough memory per agent and enough spare headroom for the full test shape.
| Situation | What you usually see | Likely bottleneck | Practical next step |
|---|---|---|---|
| 1 to 2 terminals, light checks, short test windows | Stable desktop, low agent count, limited memory growth | Usually not RAM yet | Start with a trading VPS and leave some spare memory. |
| Several concurrent agents, deeper history, more symbols | CPU does not scale cleanly as agent count increases | RAM pressure or mixed CPU plus RAM load | Move to a dedicated server with reserved CPU and RAM. |
| Heavy genetic optimization or many remote agents | Paging, unstable timings, long queues, desktop lag | RAM is often the main bottleneck | Reduce agent density or split the work across an EPYC backtest farm. |
| Live trading and optimization on one machine | Tests interfere with terminal responsiveness | Resource contention, often memory first | Separate live trading from test infrastructure, especially for POW EA VPS or other always-on systems. |
Practical Setup
Keep the workflow simple. First isolate the workload, then scale agent count only when memory remains stable.
Keep production terminals on their own VPS or dedicated environment so heavy testing does not affect active trading.
Use the same symbols, timeframes, data depth, and optimization mode you actually care about, then observe memory use before scaling out.
Increase concurrency step by step. If throughput stops improving while paging or desktop lag appears, memory is already close to the limit.
Do not size the server for a perfectly full RAM graph. Leave capacity for Windows, logs, updates, and cache growth across longer runs.
If a single machine becomes cramped, add remote agents and keep your local MT5 terminal as the master node.
Fast storage helps with history files and temporary data, but it does not replace enough RAM once the workload is memory-bound.
Checklist
If several of these points are true at the same time, the optimization setup usually needs more memory, fewer concurrent agents, or a different server class.
Troubleshooting
Upgrading is often the right move, but first remove the obvious mistakes that make MT5 optimization waste memory.
When VPS Is Not Enough
A VPS is still a good starting point for lighter MetaTrader work, but the upgrade path matters. The wrong choice is often not a weak server by itself. It is using the same class of server after the workload has already changed.
Good for a small number of terminals, lighter checks, and 24/5 or 24/7 trading where you mainly need Windows, RDP access, and stable uptime.
Best when you need reserved CPU and RAM for heavier MT5 optimization, many terminals, or a cleaner environment for trading infrastructure.
Best when one machine is no longer clean enough and you need many remote agents for large optimization batches while keeping your own MT5 terminal as the controller.
FAQ
RAM is usually the main bottleneck when MT5 optimization slows down as you add more local or remote agents, Windows starts paging to disk, and CPU usage stops scaling cleanly because agents are waiting for memory instead of actively computing.
Not much. Extra CPU helps only when each agent still has enough memory. If RAM is exhausted, more cores can leave you with more waiting agents, heavier paging, and less predictable optimization times.
There is no single fixed number because memory use depends on symbols, timeframes, historical depth, optimization mode, and how many agents run in parallel. In practice, you should size RAM for the full workload, not only for one terminal, and leave headroom for Windows, logs, and cached test data.
A VPS is usually no longer enough when you need many concurrent agents, stable reserved resources, or separation between live trading and heavy testing. At that point, a dedicated server or an EPYC backtest farm is a better fit.
Tell us how many terminals, agents, symbols, and test windows you run. We can help you choose between a VPS, a dedicated server, or a larger remote-agent setup without pretending that one box fits every workload.
