"¿Cuántos terminales puedo tener?" es la pregunta equivocada. La buena es: qué recurso se agota antes — RAM o CPU — y cuánto margen dejas para los días en que todo pasa a la vez. Si te equivocas con el recurso limitante no fallas de forma limpia; acabas con un terminal que se salta ticks en silencio mientras sigue pareciendo que va bien.
Los dos límites
Cada terminal de MetaTrader que añades consume dos cosas, y se agotan a ritmos distintos:
- RAM — un terminal MT4/MT5 moderno con un par de gráficos y un EA ronda 250–450 MB en reposo. Los indicadores pesados, muchos símbolos en Market Watch, histórico profundo y varios gráficos llevan un solo terminal muy por encima de 700 MB.
- CPU — casi siempre tranquila, pero se dispara con cada tick nuevo, en las optimizaciones y backtests, y cuando varios terminales recalculan en el mismo cierre de vela. Un símbolo con muchos ticks, como un índice volátil en la apertura de Londres, cuesta mucha más CPU que un cruce dormido a las 3 de la madrugada.
Tu capacidad real es el límite menor de los dos, no la media. Un servidor con RAM de sobra puede ahogarse por CPU cuando todos los terminales recalculan en el mismo instante, y al revés.
Un ejemplo con números
Coge un VPS de trading habitual: 4 vCPU, 8 GB de RAM. Reserva un 20% para el sistema y el antivirus, y quedan 6,4 GB y unos 3,2 núcleos utilizables. Supón que cada terminal consume de media 350 MB y 0,15 de un núcleo operando en reposo:
máx por RAM = 6,4 GB ÷ 0,35 GB ≈ 18 terminales · máx por CPU = 3,2 ÷ 0,15 ≈ 21 terminales
La RAM manda primero, así que el techo honesto son unos 18 terminales — no 21, y desde luego no los 23 que saldrían ignorando el margen. Ahora cambia un dato: carga un EA multisímbolo pesado que consume 600 MB por terminal. La capacidad por RAM se hunde a unos 10 terminales mientras la CPU apenas se mueve. Mismo servidor, casi la mitad de terminales, porque el recurso limitante ha cambiado. Por eso una única cifra por terminal engaña: hay que medir ambos recursos con tus EAs reales.
Dónde falla la gente
Correr decenas de EAs entre MT4 y MT5 expone siempre los mismos errores:
- Dimensionar para la media tranquila. El servidor que ronronea al 40% durante seis horas puede llegar al 100% en los noventa segundos posteriores a una noticia importante, cuando todos los EAs reaccionan al mismo tick.
- Olvidar que el terminal no es el único proceso. El sistema, Windows Update, los análisis del antivirus y tu propia sesión de escritorio remoto también consumen RAM y CPU. Presupuéstalos o te sorprenderán.
- Contar solo el coste en reposo. La ejecución de órdenes, el redibujado de gráficos y las sincronizaciones de histórico son más irregulares que la cifra en reposo. Mide un terminal mientras abre y gestiona posiciones de verdad, no cuando está plano.
- Optimizar en el servidor real. Una sola optimización del probador de estrategias satura todos los núcleos que le permitas y deja sin ticks a tus terminales en real. Mantén las pruebas en otra máquina.
- Demasiados terminales flacos. Diez sesiones con un gráfico cada una cargan diez copias de la sobrecarga fija del terminal. Consolidar EAs en menos terminales con más gráficos suele pesar menos — siempre que cada EA conserve un magic number único para que no se gestionen las operaciones entre ellos.
Deja margen a propósito
Correr un VPS al 95% "porque cabe" es la forma de acabar con terminales congelados, ticks perdidos y un EA que deja de operar en silencio sin lanzar ni un error. Dimensiona para el peor momento simultáneo, no para la media tranquila:
- Mantén un 15–20% de RAM y de CPU libres como colchón permanente.
- Reparte las tareas pesadas — descargas de histórico, reinicios, actualizaciones — fuera de tus horas de sesión activa.
- Vigila el archivo de paginación. En cuanto Windows empieza a volcar RAM al disco, la latencia de todos los terminales sube y ya has perdido.
- Vuelve a medir tras cualquier cambio de EA. Nueva lógica, más símbolos o una ventana de histórico mayor mueven los números.
Usa el estimador
El Estimador de capacidad de VPS hace justo esta aritmética. Introduce tus núcleos de CPU, la RAM total, la RAM por terminal que has medido, la carga de CPU por terminal y un porcentaje de margen de seguridad. Devuelve un número recomendado de terminales y — lo importante — te dice si el recurso que manda es la RAM o la CPU, para que sepas si la próxima ampliación debe comprar núcleos o memoria en lugar de adivinar.
En resumen
No satures el servidor. Mide ambos recursos con tus EAs reales, encuentra el que se agota antes, deja margen de verdad para el peor caso simultáneo y revísalo cada vez que cambie tu configuración. El número de terminales que siguen respondiendo de verdad siempre es menor que el que "técnicamente cabe" — y en esa diferencia es justo donde viven los fallos silenciosos.
