Errores de sincronización en la nube - página 2
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
Hola Stringo,
En primer lugar, gracias por la información.
Sin embargo, estoy interesado en el razonamiento de MetaQuotes para esto. Si se utiliza una gran cantidad de datos "Every Tick" (digamos, por ejemplo, 2003.1.1 -> 2013.1.1) y el Experto que se está optimizando es razonablemente complicado, a menudo tomará más de 10 minutos para una sola iteración de optimización. ¿Hay alguna razón específica por la que MetaQuotes haya elegido un periodo de 10 minutos como tiempo de espera? Además, ¿hay alguna manera de que el usuario de la nube aumente este tiempo de espera o ha sido "cableado" por MetaQuotes?
Se ha detectado un bucle sin fin sólo en los agentes de la nube. Si una de las llamadas(OnInit, OnDeinit, OnTick, OnTimer, etc.) funciona más de 10 minutos
No es una optimización única, es una llamada de señal a una función.
Ah, me equivoqué, tenía en la cabeza que estábamos hablando de una sola iteración de optimización, en lugar de una sola llamada a un manejador de eventos (aunque Stringo había mencionado específicamente una sola llamada a un manejador de eventos). Una sola llamada a un manejador de eventos que dure más de 10 minutos sería, en efecto, ridícula.Mis humildes disculpas - debo haber tenido un desvanecimiento cerebral - tiempo para descansar el cerebro. :)
Mmmmm - así que debe haber algo raro dentro de mi Expert que está causando que OnTick() ocasionalmente tome más de 10 minutos para completar una llamada. Es hora de empezar a investigar...
De todos modos, ¡gracias de nuevo por vuestra ayuda!
No es una optimización única, es una señal de llamada a una función.
Hola,
Sigo indagando pero no encuentro nada. El hecho de que mi Experto optimiza sin problemas en mis Agentes locales (es decir, ninguno de los porcentajes de progreso de mis Agentes se pausa o se detiene en ningún momento, lo que habría pensado que sería el caso si hubiera algún tipo de bucle interminable en mi función OnTick() que durara al menos 10 minutos o más) realmente lo hace difícil.
Una cosa que tengo curiosidad - ¿qué indica el número de PR al final del mensaje de error (es decir, ".... experto rechazado por MQL5 Cloud Network en 600 seg(PR116)". ¿Puede alguien arrojar algo de luz sobre esto?
Gracias de antemano por su ayuda con esto.
Hola,
Sigo indagando pero no encuentro nada. El hecho de que mi Experto optimiza sin problemas en mis Agentes locales (es decir, ninguno de los porcentajes de progreso de mis Agentes se pausa o se detiene en ningún momento, lo que habría pensado que sería el caso si hubiera algún tipo de bucle interminable en mi función OnTick() que durara al menos 10 minutos o más) realmente lo hace difícil.
Una cosa que tengo curiosidad - ¿qué indica el número de PR al final del mensaje de error (es decir, ".... experto rechazado por MQL5 Cloud Network en 600 seg(PR116)". ¿Puede alguien arrojar algo de luz sobre esto?
Gracias de antemano por su ayuda con esto.
Consulte aquí para obtener más información.
Hola,
Bueno, después de pasar muchas horas durante el fin de semana examinando mi código, no pude encontrar ningún lugar dentro del código de mi Expert donde pudiera surgir la posibilidad de un bucle sin fin. Y en el proceso, también me convencí cada vez más de que si mi Expert hubiera tenido problemas de bucle sin fin, debería haber visto que esto se hacía evidente al usar mis agentes locales para optimizar mi Expert. Como he mencionado anteriormente, mis agentes locales no se detienen en ningún momento durante la optimización de mi Expert, y mucho menos durante un periodo de diez minutos o más.
Tras convencerme de que los problemas no provenían de mi Experto, empecé a examinar las demás alternativas. Las únicas alternativas lógicas que pude ver fueron que había problemas con los propios agentes (es decir, errores) o problemas con las cajas en las que se ejecutaban. Parece que la segunda de estas alternativas es la culpable.
Por lo que he podido averiguar, la gente está ejecutando agentes en la nube en todo tipo de equipos. También estoy suponiendo que estos agentes de la nube son todos basados en Windows. La razón por la que menciono esto es que mi experiencia personal con las versiones de consumo de Windows es que son notoriamente inestables cuando se les somete a cualquier periodo de tiempo, y tienden a ralentizarse o incluso a agarrotarse cuando se les carga con cualquier demanda de procesamiento importante.
Las optimizaciones que he intentado llevar a cabo se refieren a un Experto razonablemente complejo que se ejecuta en 6-7 años de datos"Every Tick", es decir, que requiere demandas razonables de procesamiento y memoria. Sospechaba que los agentes en la nube que se encargaban de esta tarea no tenían las especificaciones suficientes, sobre todo teniendo en cuenta que serían equipos con Windows.
Así que puse la siguiente línea de código en mi controlador de eventos OnInit():
La razón por la que utilicé TERMINAL_MEMORY_PHYSICAL es que las otras opciones de memoria:TERMINAL_MEMORY_TOTAL y TERMINAL_MEMORY_AVAILABLE no son muy útiles ya que sólo te proporcionan el espacio de direcciones virtual total, en modo usuario, del procesador del host (es decir, 4GB para un procesador de 32 bits u 8TB para un procesador de 64 bits). No puedo imaginar ninguna máquina de 64 bits con 8TB de memoria - al menos, no todavía. :) TERMINAL_CPU_CORES fue otro de los que consideré, pero al final decidí simplemente probar la memoria, ya que asumí que cualquier caja con una cantidad decente de memoria estaría decentemente especificada en todas las demás áreas importantes.
Y adivina qué: ¡ya no hay problemas! Todas mis optimizaciones funcionan bien :)
Hola,
Bueno, después de pasar muchas horas durante el fin de semana examinando mi código, no pude encontrar ningún lugar dentro del código de mi Expert donde pudiera surgir la posibilidad de un bucle sin fin. Y en el proceso, también me convencí cada vez más de que si mi Expert hubiera tenido problemas de bucle sin fin, debería haber visto que esto se hacía evidente al usar mis agentes locales para optimizar mi Expert. Como he mencionado anteriormente, mis agentes locales no se detienen en ningún momento durante la optimización de mi Expert, y mucho menos durante un periodo de diez minutos o más.
Tras convencerme de que los problemas no provenían de mi Experto, empecé a examinar las demás alternativas. Las únicas alternativas lógicas que pude ver fueron que había problemas con los propios agentes (es decir, errores) o problemas con las cajas en las que se ejecutaban. Parece que la segunda de estas alternativas es la culpable.
Por lo que he podido averiguar, la gente está ejecutando agentes en la nube en todo tipo de equipos. También estoy suponiendo que estos agentes de la nube son todos basados en Windows. La razón por la que menciono esto es que mi experiencia personal con las versiones de consumo de Windows es que son notoriamente inestables cuando se les somete a cualquier periodo de tiempo, y tienden a ralentizarse o incluso a agarrotarse cuando se les carga con cualquier demanda de procesamiento importante.
Las optimizaciones que he intentado realizar se refieren a un Experto razonablemente complejo que se ejecuta en 6-7 años de datos "Every Tick", es decir, que requiere demandas razonables de procesamiento y memoria. Sospechaba que los agentes en la nube que se encargaban de esta tarea no tenían las especificaciones suficientes, sobre todo teniendo en cuenta que serían equipos con Windows.
Así que puse la siguiente línea de código en mi controlador de eventos OnInit():
La razón por la que utilicé TERMINAL_MEMORY_PHYSICAL es que las otras opciones de memoria:TERMINAL_MEMORY_TOTAL y TERMINAL_MEMORY_AVAILABLE no son muy útiles ya que sólo te proporcionan el espacio de direcciones virtual total, en modo usuario, del procesador del host (es decir, 4GB para un procesador de 32 bits u 8TB para un procesador de 64 bits). No puedo imaginar ninguna máquina de 64 bits con 8TB de memoria - al menos, no todavía. :) TERMINAL_CPU_CORES fue otro de los que consideré, pero al final decidí simplemente probar la memoria, ya que asumí que cualquier caja con una cantidad decente de memoria estaría decentemente especificada en todas las demás áreas importantes.
Y adivina qué: ¡ya no hay problemas! Todas mis optimizaciones funcionan ahora bien :)
Esto parece una gran idea y estoy agradecido por esa sugerencia.
Sin embargo, 3 cosas sobre eso:
1) Como mencioné anteriormente, también tengo el problema del bucle "interminable", pero como entendí de este hilo que "bucle interminable" es sólo la mejor suposición para "un evento tomó más de diez minutos" acepto que podría ser mi código. Utilizo indicadores bastante complejos, y como (al menos eso creo) calculan todo su historial cuando se crea su asa, esto podría (en ordenadores lentos) tardar más de diez minutos.
2) ¡Sin embargo! Por lo general, mi nube se estrelló después de 10-15 minutos. Pero anoche, funcionó perfectamente durante 8 horas. Ni una sola caída, aunque no cambié el código en absoluto. ¡Raro!
3) Y lo más importante, porque está relacionado con su enfoque: Cuando se rechaza un agente en base a su memoria, el agente (y por tanto toda la nube) no se bloquea, lo entiendo. Pero no creo que una máquina más potente vuelva a intentar el mismo conjunto de parámetros, por lo que básicamente se pierden puntos de datos de optimización, ¿estoy en lo cierto? ¿Diría usted que este es el precio que tendremos que pagar?
Tendré curiosidad por ver si mis agentes siguen funcionando cuando vuelva del trabajo...
...