FXVPS
Get Started
vps metatrader strategy-tester optimization backtesting ea

Running MT4 and MT5 Strategy Tester Optimizations on a VPS (Without Killing Your Live EAs)

person
FXVPS
Share
Running MT4 and MT5 Strategy Tester Optimizations on a VPS (Without Killing Your Live EAs)

There is a specific way traders discover that optimization and live trading do not belong on the same machine. You kick off a parameter sweep on Sunday evening, go to bed pleased with yourself, and wake up to find your live EA missed the Asian session because the terminal had been starved of CPU for six hours by a tester that was quite happily consuming every core on the box.

The Strategy Tester is the single most resource-hungry thing MetaTrader can do. A live EA checking conditions on each tick uses a rounding error of a modern CPU. An optimization run deliberately saturates every core you will let it touch, for as long as you let it. Those two workloads have opposite requirements, and putting them on the same VPS means the greedy one wins.

This guide covers how the tester actually consumes resources, how to size a VPS for optimization work, and the separation pattern that lets you do both without one destroying the other.

What the Strategy Tester Actually Does to a VPS

A single backtest pass is one core, saturated

One backtest — one set of parameters, one date range — runs as a single sequential simulation. It cannot be spread across cores, because bar 40,000 depends on the state left by bar 39,999. What it does instead is pin one core at 100% for the duration.

That is the important number. A single pass does not use “some CPU.” It uses one entire core, continuously, until it finishes.

An optimization is many passes at once

Optimization is where the resource profile changes shape. Because each parameter combination is independent of every other one, MetaTrader farms them out to testing agents — separate processes, each running its own pass. MT5 spins up one local agent per logical core by default. MT4 (build 600 and later) does the same thing with its own agent mechanism.

So the moment you press Start on an optimization, MetaTrader’s default behaviour is to consume all of your cores. On a 2 vCPU VPS that means both. There is nothing left over for the live terminal.

📊 Key Stat: A live MT4 or MT5 terminal running two or three EAs typically idles at low single-digit CPU percentages. A default optimization run targets 100% of every available core. That is not a difference of degree — the tester is designed to consume everything it is permitted to consume.

Each agent wants its own RAM

Every testing agent is a separate process with its own copy of the history data it is working through. Agents are individually lighter than a full terminal, but four of them running a tick-level test over several years of data add up quickly. Optimization runs are one of the few MetaTrader workloads that can genuinely exhaust a 2GB instance.

Then there is the disk

Agents write cached history, tick data and per-pass results continuously. On a tick-level optimization across a long date range, the tester generates a substantial amount of disk I/O and can leave several gigabytes of cache behind. If your VPS is close to full, an optimization is a good way to find out.

The Modelling Mode Decides Everything

Before sizing anything, understand that the cost of an optimization varies by orders of magnitude depending on one dropdown.

  • Open prices only — one simulated tick per bar. Fast, and only meaningful for EAs that act strictly on bar close.
  • Control points / 1 minute OHLC — a middle ground. Faster than tick modelling, and directionally useful for a first pass.
  • Every tick — MetaTrader interpolates ticks from M1 data. Substantially slower.
  • Every tick based on real ticks (MT5 only) — uses actual historical tick data from your broker. The most accurate mode available, and by far the most expensive in time and disk.

The practical workflow is to sweep wide and cheap first, then verify narrow and expensive. Run a broad parameter range on Open prices or 1-minute OHLC to find the regions worth caring about, then re-run only the surviving candidates on real ticks. Traders who go straight to real-tick optimization across a wide parameter grid are the ones who report runs measured in days.

⚠️ Warning: A fast optimization result on “Open prices only” is not a validated strategy — it is a shortlist. Any EA that trades intrabar, uses stops and targets tightly, or scalps will behave completely differently under real-tick modelling. Treat the cheap sweep as a filter, never as a conclusion.

Why Optimization Belongs on a Separate Terminal (or Box)

The core recommendation is simple: do not optimise inside the terminal that trades your live account.

The Strategy Tester runs inside a MetaTrader terminal instance, and that instance is also the thing maintaining your live connection and running your live EAs. Even if the agents are technically separate processes, they are competing with your terminal for the same finite cores on the same VPS.

There are three workable patterns, in increasing order of safety:

1. Separate terminal, same VPS, capped agents. Install a second MetaTrader instance in its own directory — our guide on installing multiple MT4 platforms with the same broker covers doing this cleanly — and use it only for testing. Then reduce the agent count so the tester cannot take every core. This is the minimum acceptable setup.

2. A bigger VPS with cores to spare. If your live terminals need one core and your optimization wants three, buy four. This works, and it is the pragmatic answer for most people.

3. A separate instance for research. Provision a second VPS purely for optimization work, run it when you need it, and leave your trading instance untouched. If you are running serious research cycles, this is cleaner than any amount of careful configuration on a shared box.

💡 Tip: Optimization is one of the few trading workloads where core count genuinely helps, because the passes are independent. Live EA execution is the opposite — it wants clock speed, not more cores. Our piece on clock speed vs core count explains why the two workloads pull in different directions.

How to Cap the Tester So It Cannot Starve Your Live Terminal

In MT5, open the Strategy Tester, go to the Agents tab, and disable local agents until only the number you want to spend remains enabled. On a 4 vCPU instance, leaving two agents enabled means the optimization runs at half speed and your live terminal always has room to breathe. That is a trade worth making.

In MT4, the equivalent control lives in the tester’s agent settings, with the same principle: reduce the number of local agents below your core count.

You can also lower the priority of the agent processes in Task Manager (right-click the process → Set priority → Below normal). Windows will then hand CPU to the terminal first whenever both want it. This is a useful belt-and-braces measure, though it is not a substitute for capping the agent count.

🚀 Try FXVPS free for $1.99 — get 7 days on the Core VPS risk-free and see how your own optimization runs behave. No long-term commitment, cancel anytime.

Core Plan ($29/mo) — 2GB RAM, 1 vCPU. This is a live-trading plan, not an optimization plan. You can run a single backtest pass on it, and short sweeps on Open-prices modelling are fine. Sustained multi-agent optimization is not what this size is for.

Pro Plan ($39/mo) — 4GB RAM, 2 vCPUs. The sensible minimum if you want to optimise and trade on the same box. Cap the tester at one agent, leave the other core for your live terminals, and accept that optimization runs take a while. Or run optimizations only at the weekend, when nothing is live.

Scaling Plan ($79/mo) — 8GB RAM, 4 vCPUs. The right plan if optimization is a regular part of your process. Four cores means you can run two or three agents in parallel and still leave headroom for live terminals, and 8GB comfortably accommodates several agents holding tick history simultaneously.

For anything beyond that — genetic optimization across large parameter spaces on real-tick data, run repeatedly — the honest answer is a dedicated research instance you spin up for the job, rather than a permanently oversized trading VPS.

✅ Best Practice: Run optimizations at the weekend. The market is closed, your live EAs have nothing to do, and you can let the tester have every core on the box without any risk to open positions. Sunday afternoon, finishing before the Sydney open, is the natural window — and it costs you nothing in plan size.

Practical Setup on Your FXVPS

  1. Install a second terminal in its own directory, dedicated to testing. Never point the Strategy Tester at the installation running your live account.

  2. Download history data first. In MT5, open the Symbols dialog and download the tick or bar history for your instrument and date range before starting. Pulling history mid-run is slow and produces gaps.

  3. Check free disk space. Tick-level runs across multi-year ranges can consume several gigabytes of cache. Verify you have room before starting a long job, not after it fails.

  4. Cap your agents as described above, unless nothing is live.

  5. Start with the cheap modelling mode and a wide parameter range. Narrow, then escalate to real ticks.

  6. Leave it running and disconnect properly. This is the actual advantage of optimising on a VPS: close the RDP session and the run continues on the server. Disconnecting is not the same as logging off — see how to properly disconnect from an RDP session, because logging off can terminate your applications.

  7. Clear the tester cache periodically. The agent directories under your terminal installation accumulate cached history across runs and are safe to clear when you are not testing.

  8. Export results before you delete anything. The optimization results tab lets you save the full pass table. Keep it — the value of a long run is in the parameter surface, not just the top line.

A Note on What Optimization Results Actually Mean

A VPS makes optimization faster and more convenient. It does not make the output more trustworthy. The most common expensive mistake in this whole workflow is not a hardware one — it is taking the top row of an optimization table, which is by construction the parameter set most fitted to that specific history, and putting it live.

The parameters worth trading are the ones sitting in a broad plateau of decent results, not the isolated spike. And even a well-chosen parameter set will behave differently live than in the tester, for reasons that have nothing to do with your CPU: spread modelling, slippage, execution latency and broker-side differences. Why your backtest doesn’t match live results covers that gap in detail, and it is worth reading before you act on any optimization output.

Frequently Asked Questions

Can I run an optimization and my live EAs on the same VPS?

Yes, if you cap the tester’s agent count so it cannot take every core, and ideally if you run optimizations at the weekend. On a 1 vCPU instance the answer is effectively no — there is no core to spare.

Does a VPS make my backtests run faster?

Only insofar as its CPU is faster or has more cores than the machine you were using. The real advantage is different: the run continues after you disconnect, it does not tie up your own computer for hours, and it will not be interrupted by your laptop sleeping.

How many cores do I need for optimization?

More is better, because passes are independent and parallelise cleanly. Four cores (Scaling) is a comfortable working level for regular optimization. Two (Pro) works if you are patient or run at weekends.

Why did my optimization fill up the disk?

Testing agents cache history and per-pass data, and real-tick modelling over long date ranges generates a lot of it. Clear the agent cache directories between large runs and keep an eye on free space before starting.

Should I use the MQL5 Cloud Network instead?

It is a legitimate option for MT5 users with very large parameter spaces, since it distributes passes across external agents for a fee. It does not replace a VPS — you still need somewhere always-on for the terminal itself and your live EAs. Think of it as an add-on for heavy research, not an alternative to hosting.

Can I optimise on one VPS and trade on another?

Yes, and it is the cleanest arrangement if you run research regularly. The optimization instance needs no low-latency broker connection at all, so it does not need to be colocated — which means you can size it for CPU rather than for geography.