Ajustes de memoria y estabilidad en StrategyQuant X

Casi todos los cierres inesperados de SQX salen de una sola pantalla de configuración. Y la cifra que hay que poner ahí no es la que repite la mayoría, porque depende de algo que casi nadie menciona.

La documentación del fabricante lo dice sin rodeos: SQX es sensible a los problemas de memoria, y cualquier fallo en su gestión puede tumbar el programa. Una sesión de veinticuatro horas que termina en *Out of Memory* sin haber guardado nada es una tarde perdida y, peor, una lección mal aprendida sobre el hardware.

Los ajustes están tras el icono de la rueda dentada, arriba a la derecha. Según la versión aparecen bajo *Memory*, bajo *CPU & Memory* o repartidos con *Troubleshooting*. Los nombres bailan; la lógica no.

La cifra que genera discusiones

Circulan dos recomendaciones muy distintas sobre cuánta memoria asignar, y lo curioso es que ninguna está mal.

La documentación oficial recomienda destinar a SQX entre el 80 y el 100 % de la memoria real. Con 16 GB instalados, eso significa poner 12, 14 o incluso 16. El argumento es correcto: ese valor es un máximo, no una reserva, y el programa no ocupará necesariamente todo lo configurado.

Otra escuela, la que se enseña habitualmente en formación, deja un margen mayor: 24 a 28 GB si tienes 32, unos 96 si tienes 128. Y en el foro hay casos que le dan la razón. Uno documentado: con 16 GB instalados y 15 asignados, el uso máximo se estancaba en 12 y seguía apareciendo el mensaje de memoria agotada. El sistema operativo y el resto de aplicaciones también comen, y el recolector de basura de Java necesita espacio libre para maniobrar.

Hay un detalle que despista a quien tiene mucha RAM. Por defecto SQX deja que Java decida el máximo, y esa decisión automática se queda corta en equipos con memoria abundante. Si tienes 16 GB o más y nunca has tocado este ajuste, probablemente estés usando una fracción de lo que podrías.

Cómo se reparte esa memoria

• Datos históricos cargados: un activo en marco de un minuto completo puede ocupar cientos de megas.
• Databank activo: entre 1 y 5 MB por estrategia según complejidad.
• Espacio propio de la máquina virtual de Java, que crece hasta el máximo configurado.
• Caché de cálculos intermedios que el motor reutiliza para acelerar generaciones sucesivas.

Eso explica por qué el mismo equipo aguanta un databank de dos mil estrategias sin despeinarse y se ahoga con ocho mil. Y explica también la palanca que casi nadie usa: la documentación insiste en que con menos RAM hay que reducir el tamaño del databank y los pasos de optimización, no forzar la máquina. Bajar de diez mil a tres mil estrategias no te hace peor operador; te obliga a definir mejor tus criterios de aceptación, que es exactamente lo que separa un proceso serio de un montón de ruido acumulado.

Guardado automático: diez minutos

El programa puede pasar doce o veinticuatro horas generando. Sin guardado automático, un corte de luz borra todo el progreso.

Se activa en la misma pantalla, con intervalo de diez minutos y la escritura en disco marcada. Los archivos se escriben en la carpeta de databanks dentro de `user`. Si trabajas en una máquina remota, añade además una tarea programada de Windows que copie esa carpeta a otro sitio cada media hora: así conservas el trabajo aunque el servidor entero deje de responder.

Complementario a esto está la protección de memoria, que detiene el proyecto activo al alcanzar el 85 % del límite en lugar de dejar que el programa se caiga. La diferencia entre un proceso pausado y un databank a medio escribir es considerable.

Cuando algo falla, en este orden

La documentación propone una secuencia concreta ante cierres inesperados. Merece la pena seguirla en orden en vez de ir probando cosas:

1. Revisa la configuración de memoria y comprueba que el valor es coherente con la RAM instalada.
2. Verifica que el equipo tiene memoria suficiente. El mínimo oficial son 8 GB.
3. Activa la protección de memoria al 85 % si los cierres continúan.
4. Ejecuta el Deep Memory Test, la herramienta de diagnóstico incluida, para descartar un problema físico de la memoria.
5. Comprueba que los controladores del sistema están actualizados.
6. Si nada de lo anterior lo resuelve, prueba a cambiar el motor de Java: algunos cierres aleatorios no son de SQX.

La interfaz no responde pero hay RAM libre

Síntoma frecuente y desconcertante. El administrador de tareas muestra memoria de sobra, pero el programa va a trompicones. La causa habitual no es falta de memoria sino que la aplicación no está usando bien la que hay, precisamente porque el límite lo decide Java por su cuenta. Configurarlo a mano suele arreglarlo.

Si aun así se congela, el siguiente sospechoso es la aceleración gráfica. Desactívala en *Troubleshooting*: da problemas conocidos en máquinas remotas y en equipos con gráficos integrados.

Otros ajustes que sí importan

Lista de comprobación

• Idioma en inglés.
• Memoria asignada a mano, con el valor que corresponda a tu RAM y al uso del equipo.
• Pico real de memoria comprobado tras una sesión larga.
• Protección de memoria al 85 % activa.
• Guardado automático cada 10 minutos, con escritura en disco.
• Copia externa de la carpeta de databanks si trabajas en remoto.
• Tamaño máximo del databank coherente con la memoria instalada.
• Gráficos 3D apagados salvo cuando los necesites.
• Aceleración gráfica probada con y sin, quedándote con la más estable.

Preguntas frecuentes (FAQs)

Sigue leyendo el contenido de este tutorial

Si aun con todo esto tu equipo se queda corto, toca hablar de máquinas externas.