Pregunta para los desarrolladores: uso de todos los núcleos de cálculo durante la optimización - página 8
Está perdiendo oportunidades comerciales:
- Aplicaciones de trading gratuitas
- 8 000+ señales para copiar
- Noticias económicas para analizar los mercados financieros
Registro
Entrada
Usted acepta la política del sitio web y las condiciones de uso
Si no tiene cuenta de usuario, regístrese
Un enfoque interesante.
Puede haber varias soluciones a este problema dependiendo de los detalles.
Si todos los parámetros, los que ya existen y los que pueden aparecer, tienen un lugar estrictamente definido en el conjunto de parámetros (cromosoma u otro equivalente), entonces no hay ningún problema.
Si no se puede definir de antemano el lugar definitivo de cada parámetro, entonces es necesario dividir los parámetros en tipos que puedan combinarse estrictamente entre sí (entonces no importa dónde esté un parámetro) - se requiere la modificación de AO.
Hay otras formas de resolver el problema, pero en cualquier caso necesitarás una OA personalizada, una superestructura sobre la estándar.
sobrecarga de memoria confirmada .... Aunque es extraño, nadie canceló el intercambio, una vez más, creo que los desarrolladores deben tener esto en cuenta
Deberías informarnos de cómo se resuelve el problema. Estamos preocupados por ti, ¿verdad?
Cuánta memoria mínima necesita por agente (¿ha reducido el número de agentes activados hasta que todos estén cargados uniformemente?)
¿Aumentó el archivo de páginas? La memoria física se intercambiará constantemente, puede ralentizarse mucho, hay que encontrar un número de núcleos donde el tiempo total de optimización sea mínimo.
Deberías informarnos de cómo se resuelve el problema. Estamos preocupados por ti, ¿verdad?
Cuánta memoria mínima necesita por agente (¿ha reducido el número de agentes activados hasta que todos estén cargados uniformemente?)
¿Aumentó el archivo de páginas? La memoria física se intercambiará constantemente, podría haber graves ralentizaciones, tenemos que encontrar un número de núcleos donde el tiempo total de optimización sea mínimo.
Todo depende del uso de las garrapatas, la profundidad del historial y el número de herramientas. Sólo tienes que mirar en el administrador de tareas, verás allí todo, la cantidad de toda la RAM menos 1-2 GB para el sistema operativo dividido por la cantidad utilizada por un agente. Es diferente para cada uno.
Los desarrolladores pueden realizar una verdadera mejora si se utiliza una zona de la RAM para las cotizaciones y, posiblemente, para los indicadores.Todo depende del uso de las garrapatas, la profundidad del historial y el número de herramientas. Sólo tienes que mirar el administrador de tareas, puedes ver el tamaño total de la RAM menos 1-2 GB para el sistema operativo dividido por el tamaño utilizado por un agente. Es diferente para cada uno.
Los desarrolladores pueden realmente mejorar la situación, si un área de la RAM se utiliza para las cotizaciones y, tal vez, para los indicadores.¿Me lo estás explicando? Estaba explicando el problema a un hombre, y ahora me interesa el resultado. No hay retroalimentación.
Y ya hemos discutido muchas veces el uso ineficiente de la memoria por parte del terminal, y MQ varias veces prometió cambiar la situación con la duplicación del historial de ticks y los archivos temporales para cada agente, y su larga creación antes de cada optimización de ticks. Personalmente he tenido que desactivar casi la mitad de los agentes y las optimizaciones de las garrapatas durante varios años. Tengo 8GB y 8 agentes. Pero por ahora usamos lo que tenemos, y podemos aumentar el tamaño de la memoria o desactivar los agentes.
¿Me lo estás explicando? Le expliqué el problema y ahora me pregunto por el resultado. No hay retroalimentación.
Y el uso ineficiente de la memoria por parte del terminal ya lo hemos discutido muchas veces, y MQ varias veces prometió cambiar la situación con la duplicación del historial de ticks y los archivos temporales para cada agente, y su larga creación antes de cada optimización de ticks. Personalmente he tenido que desactivar casi la mitad de los agentes y las optimizaciones de las garrapatas durante varios años. Tengo 8GB y 8 agentes. Pero por ahora usamos lo que tenemos, y podemos aumentar el tamaño de la memoria o desactivar los agentes.
>Sólo tienes que hacernos saber cómo se resuelve el problema. Estamos preocupados por ti.
>Le expliqué el problema y ahora me interesa el resultado. No hay comentarios.
Lo siento, estaba trabajando, no tenía tiempo.
He optimizado el EA. He eliminado algunas partes "sin importancia" para que el optimizador funcione (concretamente, todo lo relacionado con OpenCL y SQLite). Ahora no tengo desbordamiento de memoria. PERO... no es una solución, por supuesto.
En otro ordenador tuve que desactivar algunos de los núcleos para evitar que se congelara... Así, por ejemplo, el sistema en un 3950X (16 núcleos/32 hilos) y 32 GB, utilizando todos los hilos simplemente se cuelga. Además, se cuelga de los agentes y se queda colgado hasta que se mata manualmente el proceso a través del administrador de tareas .... Desactivé algunos de los núcleos y el cálculo continuó. Creo que los desarrolladores deberían hacer algo para explicitar el problema. Si el optimizador realmente necesita más de diez gigas de memoria para el cálculo debería estar claramente escrito en algo como una alerta. Sin embargo, le recordaré una vez más lo del intercambio. Tengo instalado Xmeters... Así puedo ver la carga de memoria visualmente en la barra de tareas.
Creo que hay algún otro fallo relacionado específicamente con la CPU de amdc y que antes no existía, aunque el asesor era el mismo. Los síntomas son los siguientes - sólo 5 núcleos .... y el error de cálculo cuelga... Y no es exactamente la memoria, es decir, el mismo Asesor Experto fuerza 16 hilos sin problema, y el problema es la flotación, ahora y luego no. Si ejecuto la prueba sin el optimizador, se ejecuta bien. Lo he notado más de una vez. Así que tengo que comprobarlo.
Con respecto a los frenos en los agentes de la red, todavía no puedo llegar a ella. El "un núcleo - un trabajo" está más allá de la comprensión de los desarrolladores. Al igual que antes, 10 núcleos recibirán cada uno 30 trabajos y otros 30 agentes de red estarán inactivos. Tarda mucho en distribuir las tareas pensando en algo. Así que en general hay mucho retraso.
Y sí, se me olvidaba: muchas gracias a todos por vuestra participación, ayuda y consejos.aRenat Fatkhullin
Aun así, quiero plantear el tema una vez más y hacer una pregunta específicamentea Renat Fatkhullin
1. Estoy optimizando una granja local que consiste en varios servidores con rendimientos bastante diferentes y vi algunos retrasos realmente terribles durante la optimización causados por CPUs con diferentes rendimientos. Supongamos que hay servidores con CPU Xeon E5-2620 v2 (2,1 GHz), Xeon E5-2620 0 (2,00 GHz), i7-3820 (3,6 GHz), Xeon E3-1245 (3,7 GHz), Ryzen 7 2700, Ryzen 9 3900X, Ryzen 9 3950X. El algoritmo actual funciona así: forma una pila de trabajos, divide esa pila de trabajos en partes iguales para cada núcleo disponible. Debido a las CPUs Xeon E5-2620 0 (2,00GHz) y Xeon E5-2620 v2 (2,1GHz) de baja velocidad, la granja estaba inactiva y contaba sus tareas, pero estas dos CPUs no contaban ni la mitad de ellas. Así, toda la granja se queda parada. Ocurre y seguirá ocurriendo porque las CPUs tienen diferente velocidad y mientras los trabajos se distribuyan en paquetes. La experiencia demuestra que la latencia de la red no importa en absoluto y es insignificante. ¿Es posible ya reelaborar el algoritmo de distribución de trabajos: no distribuir varios trabajos a cada núcleo disponible, sino"dar a cada núcleo liberado un trabajo de la pila de generación actual"?
2. ¿Es posible añadir que se guarden los resultados de las pruebas en un archivo xml cada 10 minutos .... y que se ejecute desde el último guardado?
Hemos emprendido una reescritura completa del probador y del optimizador.
Vamos a revisar y arreglar drásticamente los problemas acumulados.
Hemos emprendido una reescritura completa del probador y del optimizador.
Vamos a revisar y arreglar drásticamente los problemas acumulados.
Lo habrá:
1. Reacción más rápida al abandono del agente, donde, por ejemplo, si no hay retirada del agente, la entrega de paquetes se interrumpe durante minutos y los paquetes se redistribuyen.
2. ¿Será posible cargar en una sola instancia los datos de todos los agentes de una máquina remota?
3. ¿el problema de la transferencia de grandes cantidades de datos, cuando se rompe la conexión con un agente, al no haber descargado todos los datos (archivos) necesarios para la optimización?
Hay otra cosa que me molesta ....
digamos que la optimización está en marcha y en ese momento el metatrader del agente se actualiza .... el agente tiene un trabajo (o más bien un lote de trabajos), ¿se perderá o se recalculará?