이들10분과 20분의 차이점은 무엇인가요? 다르지 않습니다. 10분은 단일 통화에 매우 깁니다. EA를 잘못 작성한 테스트를 원하십니까? 괜찮아요. 그러나 공용 클라우드 서버 에서 문제를 확장하지 마십시오. 다른 사용자들도 클라우드 서버를 사용하기를 원합니다. 제한 없이 로컬 에이전트와 원격 에이전트를 사용할 수 있습니다.
그러나 저는 MetaQuotes가 이에 대한 추론에 관심이 있습니다. 많은 양의 "Every Tick" 데이터가 사용되고(예: 2003.1.1 -> 2013.1.1) 최적화되는 Expert가 상당히 복잡한 경우 단일 최적화를 반복하는 데 10분 이상 걸리는 경우가 많습니다. 발생 . MetaQuotes가 10분을 타임아웃으로 선택한 특별한 이유가 있나요? 또한 클라우드 사용자가 이 시간 초과를 늘릴 수 있는 방법이 있습니까? 아니면 MetaQuotes에 의해 "고정 연결"되어 있습니까?
스트링고 : Cloud Agent에서만 무한 루프가 감지되었습니다. 호출(OnInit, OnDeinit, OnTick, OnTimer 등) 중 하나 가 10분 이상 작동하는 경우
아 - 내 실수 - Stringo가 단일 이벤트 핸들러 호출을 구체적으로 언급했음에도 불구하고 이벤트 핸들러에 대한 단일 호출이 아니라 단일 최적화 반복에 대해 이야기하고 있다는 것이 내 실수였습니다. 10분 이상 지속되는 이벤트 핸들러에 대한 단일 호출은 실제로 터무니없을 것입니다. 나의 겸손한 사과는 - 뇌가 퇴색되었을 것입니다 - 뇌를 쉬게 할 시간입니다. :)
음.. 내 Expert 내에서 이상한 일이 발생하여 OnTick()이 때때로 통화를 완료하는 데 10분 이상 걸리는 경우가 있습니다. 발굴을 시작할 시간...
여전히 파고 있지만 무엇이든 찾기 위해 고군분투합니다. 내 전문가가 내 로컬 에이전트에서 완벽하게 최적화한다는 사실(즉, 내 에이전트의 진행률이 일시 중지되거나 중지되지 않으며, 내 OnTick() 함수에 일종의 무한 루프가 있는 경우라고 생각했을 것입니다. 최소 10분 이상 지속) 정말 어렵습니다.
한 가지 궁금한 점이 있습니다. 오류 메시지 끝에 있는 PR 번호는 무엇을 나타냅니다(예: ".... 전문가가 600초 내에 MQL5 클라우드 네트워크 에 의해 거부됨( PR116 )"). 누구든지 이에 대해 설명할 수 있습니까?
여전히 파고 있지만 무언가를 찾기 위해 고군분투합니다. 내 전문가가 내 로컬 에이전트에서 완벽하게 최적화한다는 사실(즉, 내 에이전트의 진행률이 일시 중지되거나 중지되지 않으며, 내 OnTick() 함수에 일종의 무한 루프가 있는 경우라고 생각했을 것입니다. 최소 10분 이상 지속) 정말 어렵습니다.
한 가지 궁금한 점이 있습니다. 오류 메시지 끝에 있는 PR 번호는 무엇을 나타냅니다(예: ".... 전문가가 600초 내에 MQL5 클라우드 네트워크 에 의해 거부됨( PR116 )"). 누구든지 이에 대해 설명할 수 있습니까?
도움을 주셔서 미리 감사드립니다.
PR은 특별한 통합 방법에 따라 계산된 에이전트의 성과 등급입니다. 에이전트의 PR이 높을수록 작업을 더 빨리 수행하고 결과적으로 단위 시간당 임대 가격이 높아집니다.
글쎄, 주말에 내 코드를 검사하는 데 많은 시간을 보낸 후, 내 Expert의 코드에서 무한 루프의 가능성이 발생할 수 있는 곳을 찾을 수 없었습니다. 그리고 그 과정에서 내 Expert에게 무한 루프 문제가 있었다면 로컬 에이전트를 사용하여 Expert를 최적화할 때 이 문제가 명백해지는 것을 보았어야 한다는 확신이 점점 더 많이 생겼습니다. 위에서 언급했듯이 내 지역 상담원은 내 Expert를 최적화하는 동안 10분 이상은 고사하고 어떤 단계에서도 일시 중지하지 않습니다.
문제가 내 전문가에게서 발생하지 않았다는 확신을 갖게 된 후 다른 대안을 검토하기 시작했습니다. 내가 볼 수 있는 유일한 논리적 대안은 에이전트 자체에 문제(즉, 버그)가 있거나 에이전트가 실행 중인 상자에 문제가 있다는 것이었습니다. 두 번째 대안이 범인인 것 같습니다.
내가 해결할 수 있는 바에 따르면 사람들은 모든 종류의 상자에서 클라우드 에이전트를 실행하고 있습니다. 또한 이러한 클라우드 에이전트는 모두 Windows 기반이라고 가정합니다. 내가 이것을 언급하는 이유는 Windows 소비자 버전에 대한 개인적인 경험이 시간에 관계없이 충돌할 때 불안정하기로 악명이 높기 때문입니다.
내가 수행하려고 시도한 최적화는 합리적으로 복잡한 Expert가 6-7년 동안의 " Every Tick " 데이터에서 실행되는 것과 관련되어 있습니다. 즉, 합리적인 처리 및 메모리 요구가 필요합니다. 나는 이 작업을 수행하는 클라우드의 에이전트가 특히 Windows 상자일 것이라는 점을 고려할 때 충분히 지정되지 않았다고 의심했습니다.
내가 TERMINAL_MEMORY_PHYSICAL을 사용한 이유는 다른 메모리 옵션인 TERMINAL_MEMORY_TOTAL 및 TERMINAL_MEMORY_AVAILABLE이 호스트 프로세서의 전체 사용자 모드 가상 주소 공간(즉, 32비트 프로세서의 경우 4GB 또는 8TB의 경우 8TB)만 제공하므로 많이 사용되지 않기 때문입니다. 64비트 프로세서). 적어도 아직까지는 8TB의 메모리를 가진 64비트 머신은 상상할 수 없습니다. :) TERMINAL_CPU_CORES는 내가 고려한 또 다른 것이지만 적절한 양의 메모리가 있는 모든 상자가 다른 모든 중요한 영역에서 적절하게 지정될 것이라고 가정하기 때문에 결국 메모리 테스트를 진행하기로 결정했습니다.
글쎄, 주말에 내 코드를 검사하는 데 많은 시간을 보낸 후, 내 Expert의 코드에서 무한 루프의 가능성이 발생할 수 있는 곳을 찾을 수 없었습니다. 그리고 그 과정에서 내 Expert에게 무한 루프 문제가 있었다면 로컬 에이전트를 사용하여 Expert를 최적화할 때 이 문제가 명백해지는 것을 보았어야 한다는 확신이 점점 더 많이 생겼습니다. 위에서 언급했듯이 내 지역 상담원은 내 Expert를 최적화하는 동안 10분 이상은 고사하고 어떤 단계에서도 일시 중지하지 않습니다.
문제가 내 전문가에게서 발생하지 않았다는 확신을 갖게 된 후 다른 대안을 검토하기 시작했습니다. 내가 볼 수 있는 유일한 논리적 대안은 에이전트 자체에 문제(즉, 버그)가 있거나 에이전트가 실행 중인 상자에 문제가 있다는 것이었습니다. 이러한 대안 중 두 번째가 범인으로 보입니다.
내가 해결할 수 있는 바에 따르면 사람들은 모든 종류의 상자에서 클라우드 에이전트를 실행하고 있습니다. 또한 이러한 클라우드 에이전트는 모두 Windows 기반이라고 가정합니다. 내가 이것을 언급하는 이유는 Windows 소비자 버전에 대한 개인적인 경험이 시간에 관계없이 충돌할 때 불안정하기로 악명이 높기 때문입니다.
내가 수행하려고 시도한 최적화는 6-7년 간의 "Every Tick" 데이터에서 실행되는 합리적으로 복잡한 Expert에 관한 것입니다. 즉, 합리적인 처리 및 메모리 요구가 필요합니다. 나는 이 작업을 수행하는 클라우드의 에이전트가 특히 Windows 상자일 것이라는 점을 고려할 때 충분히 지정되지 않았다고 의심했습니다.
그래서 OnInit() 이벤트 핸들러에 다음 코드 줄을 넣었습니다.
내가 TERMINAL_MEMORY_PHYSICAL을 사용한 이유는 다른 메모리 옵션인 TERMINAL_MEMORY_TOTAL 및 TERMINAL_MEMORY_AVAILABLE이 호스트 프로세서의 전체 사용자 모드 가상 주소 공간(즉, 32비트 프로세서의 경우 4GB 또는 8TB의 경우 8TB)만 제공하므로 많이 사용되지 않기 때문입니다. 64비트 프로세서). 적어도 아직까지는 8TB의 메모리를 가진 64비트 머신은 상상할 수 없습니다. :) TERMINAL_CPU_CORES는 내가 고려한 또 다른 것이지만 적절한 양의 메모리가 있는 모든 상자가 다른 모든 중요한 영역에서 적절하게 지정될 것이라고 가정하기 때문에 결국 메모리 테스트를 진행하기로 결정했습니다.
그리고 더 이상 문제가 없습니다! 이제 모든 최적화가 제대로 실행되고 있습니다. :)
이것은 좋은 아이디어처럼 들리며 그 힌트에 감사드립니다.
그러나 그것에 대해 3가지:
1) 위에서 언급했듯이 "무한" 루프의 문제도 있지만 이 스레드에서 "무한 루프"가 "하나의 이벤트가 10분 이상 소요됨"에 대한 최선의 추측일 뿐이라는 것을 이해했기 때문에 내 코드가 될 수 있습니다. 나는 매우 복잡한 표시기를 사용하며 (적어도 그렇게 생각합니다) 핸들이 생성될 때 전체 기록을 계산하기 때문에 (느린 컴퓨터에서는) 10분 이상 걸릴 수 있습니다.
2) 그러나! 일반적으로 내 클라우드는 10-15분 후에 충돌했습니다. 하지만 어젯밤에는 8시간 동안 완벽하게 작동했습니다. 코드를 전혀 변경하지 않았지만 단일 충돌은 발생하지 않았습니다. 기이한!
3) 그리고 가장 중요한 것은 접근 방식과 관련이 있기 때문입니다. 메모리를 기반으로 에이전트를 거부하면 에이전트(및 전체 클라우드)가 충돌하지 않습니다. 이해합니다. 그러나 더 강력한 기계가 동일한 매개변수 집합을 다시 시도하므로 기본적으로 최적화 데이터 포인트를 잃게 된다고 생각하지 않습니다. 맞습니까? 이것이 우리가 치러야 할 대가입니까?
안녕하세요 Stringo님
먼저 정보 감사합니다.
그러나 저는 MetaQuotes가 이에 대한 추론에 관심이 있습니다. 많은 양의 "Every Tick" 데이터가 사용되고(예: 2003.1.1 -> 2013.1.1) 최적화되는 Expert가 상당히 복잡한 경우 단일 최적화를 반복하는 데 10분 이상 걸리는 경우가 많습니다. 발생 . MetaQuotes가 10분을 타임아웃으로 선택한 특별한 이유가 있나요? 또한 클라우드 사용자가 이 시간 초과를 늘릴 수 있는 방법이 있습니까? 아니면 MetaQuotes에 의해 "고정 연결"되어 있습니까?
Cloud Agent에서만 무한 루프가 감지되었습니다. 호출(OnInit, OnDeinit, OnTick, OnTimer 등) 중 하나 가 10분 이상 작동하는 경우
단일 최적화가 아니라 함수에 대한 신호 호출입니다.
아 - 내 실수 - Stringo가 단일 이벤트 핸들러 호출을 구체적으로 언급했음에도 불구하고 이벤트 핸들러에 대한 단일 호출이 아니라 단일 최적화 반복에 대해 이야기하고 있다는 것이 내 실수였습니다. 10분 이상 지속되는 이벤트 핸들러에 대한 단일 호출은 실제로 터무니없을 것입니다. 나의 겸손한 사과는 - 뇌가 퇴색되었을 것입니다 - 뇌를 쉬게 할 시간입니다. :)
음.. 내 Expert 내에서 이상한 일이 발생하여 OnTick()이 때때로 통화를 완료하는 데 10분 이상 걸리는 경우가 있습니다. 발굴을 시작할 시간...
어쨌든, 당신의 도움에 다시 한번 감사드립니다!
단일 최적화가 아니라 함수에 대한 신호 호출입니다.
안녕,
여전히 파고 있지만 무엇이든 찾기 위해 고군분투합니다. 내 전문가가 내 로컬 에이전트에서 완벽하게 최적화한다는 사실(즉, 내 에이전트의 진행률이 일시 중지되거나 중지되지 않으며, 내 OnTick() 함수에 일종의 무한 루프가 있는 경우라고 생각했을 것입니다. 최소 10분 이상 지속) 정말 어렵습니다.
한 가지 궁금한 점이 있습니다. 오류 메시지 끝에 있는 PR 번호는 무엇을 나타냅니다(예: ".... 전문가가 600초 내에 MQL5 클라우드 네트워크 에 의해 거부됨( PR116 )"). 누구든지 이에 대해 설명할 수 있습니까?
도움을 주셔서 미리 감사드립니다.
안녕,
여전히 파고 있지만 무언가를 찾기 위해 고군분투합니다. 내 전문가가 내 로컬 에이전트에서 완벽하게 최적화한다는 사실(즉, 내 에이전트의 진행률이 일시 중지되거나 중지되지 않으며, 내 OnTick() 함수에 일종의 무한 루프가 있는 경우라고 생각했을 것입니다. 최소 10분 이상 지속) 정말 어렵습니다.
한 가지 궁금한 점이 있습니다. 오류 메시지 끝에 있는 PR 번호는 무엇을 나타냅니다(예: ".... 전문가가 600초 내에 MQL5 클라우드 네트워크 에 의해 거부됨( PR116 )"). 누구든지 이에 대해 설명할 수 있습니까?
도움을 주셔서 미리 감사드립니다.
자세한 내용은 여기 를 참조하세요.
안녕,
글쎄, 주말에 내 코드를 검사하는 데 많은 시간을 보낸 후, 내 Expert의 코드에서 무한 루프의 가능성이 발생할 수 있는 곳을 찾을 수 없었습니다. 그리고 그 과정에서 내 Expert에게 무한 루프 문제가 있었다면 로컬 에이전트를 사용하여 Expert를 최적화할 때 이 문제가 명백해지는 것을 보았어야 한다는 확신이 점점 더 많이 생겼습니다. 위에서 언급했듯이 내 지역 상담원은 내 Expert를 최적화하는 동안 10분 이상은 고사하고 어떤 단계에서도 일시 중지하지 않습니다.
문제가 내 전문가에게서 발생하지 않았다는 확신을 갖게 된 후 다른 대안을 검토하기 시작했습니다. 내가 볼 수 있는 유일한 논리적 대안은 에이전트 자체에 문제(즉, 버그)가 있거나 에이전트가 실행 중인 상자에 문제가 있다는 것이었습니다. 두 번째 대안이 범인인 것 같습니다.
내가 해결할 수 있는 바에 따르면 사람들은 모든 종류의 상자에서 클라우드 에이전트를 실행하고 있습니다. 또한 이러한 클라우드 에이전트는 모두 Windows 기반이라고 가정합니다. 내가 이것을 언급하는 이유는 Windows 소비자 버전에 대한 개인적인 경험이 시간에 관계없이 충돌할 때 불안정하기로 악명이 높기 때문입니다.
내가 수행하려고 시도한 최적화는 합리적으로 복잡한 Expert가 6-7년 동안의 " Every Tick " 데이터에서 실행되는 것과 관련되어 있습니다. 즉, 합리적인 처리 및 메모리 요구가 필요합니다. 나는 이 작업을 수행하는 클라우드의 에이전트가 특히 Windows 상자일 것이라는 점을 고려할 때 충분히 지정되지 않았다고 의심했습니다.
그래서 OnInit() 이벤트 핸들러에 다음 코드 줄을 넣었습니다.
내가 TERMINAL_MEMORY_PHYSICAL을 사용한 이유는 다른 메모리 옵션인 TERMINAL_MEMORY_TOTAL 및 TERMINAL_MEMORY_AVAILABLE이 호스트 프로세서의 전체 사용자 모드 가상 주소 공간(즉, 32비트 프로세서의 경우 4GB 또는 8TB의 경우 8TB)만 제공하므로 많이 사용되지 않기 때문입니다. 64비트 프로세서). 적어도 아직까지는 8TB의 메모리를 가진 64비트 머신은 상상할 수 없습니다. :) TERMINAL_CPU_CORES는 내가 고려한 또 다른 것이지만 적절한 양의 메모리가 있는 모든 상자가 다른 모든 중요한 영역에서 적절하게 지정될 것이라고 가정하기 때문에 결국 메모리 테스트를 진행하기로 결정했습니다.
그리고 더 이상 문제가 없습니다! 이제 모든 최적화가 제대로 실행되고 있습니다. :)
안녕,
글쎄, 주말에 내 코드를 검사하는 데 많은 시간을 보낸 후, 내 Expert의 코드에서 무한 루프의 가능성이 발생할 수 있는 곳을 찾을 수 없었습니다. 그리고 그 과정에서 내 Expert에게 무한 루프 문제가 있었다면 로컬 에이전트를 사용하여 Expert를 최적화할 때 이 문제가 명백해지는 것을 보았어야 한다는 확신이 점점 더 많이 생겼습니다. 위에서 언급했듯이 내 지역 상담원은 내 Expert를 최적화하는 동안 10분 이상은 고사하고 어떤 단계에서도 일시 중지하지 않습니다.
문제가 내 전문가에게서 발생하지 않았다는 확신을 갖게 된 후 다른 대안을 검토하기 시작했습니다. 내가 볼 수 있는 유일한 논리적 대안은 에이전트 자체에 문제(즉, 버그)가 있거나 에이전트가 실행 중인 상자에 문제가 있다는 것이었습니다. 이러한 대안 중 두 번째가 범인으로 보입니다.
내가 해결할 수 있는 바에 따르면 사람들은 모든 종류의 상자에서 클라우드 에이전트를 실행하고 있습니다. 또한 이러한 클라우드 에이전트는 모두 Windows 기반이라고 가정합니다. 내가 이것을 언급하는 이유는 Windows 소비자 버전에 대한 개인적인 경험이 시간에 관계없이 충돌할 때 불안정하기로 악명이 높기 때문입니다.
내가 수행하려고 시도한 최적화는 6-7년 간의 "Every Tick" 데이터에서 실행되는 합리적으로 복잡한 Expert에 관한 것입니다. 즉, 합리적인 처리 및 메모리 요구가 필요합니다. 나는 이 작업을 수행하는 클라우드의 에이전트가 특히 Windows 상자일 것이라는 점을 고려할 때 충분히 지정되지 않았다고 의심했습니다.
그래서 OnInit() 이벤트 핸들러에 다음 코드 줄을 넣었습니다.
내가 TERMINAL_MEMORY_PHYSICAL을 사용한 이유는 다른 메모리 옵션인 TERMINAL_MEMORY_TOTAL 및 TERMINAL_MEMORY_AVAILABLE이 호스트 프로세서의 전체 사용자 모드 가상 주소 공간(즉, 32비트 프로세서의 경우 4GB 또는 8TB의 경우 8TB)만 제공하므로 많이 사용되지 않기 때문입니다. 64비트 프로세서). 적어도 아직까지는 8TB의 메모리를 가진 64비트 머신은 상상할 수 없습니다. :) TERMINAL_CPU_CORES는 내가 고려한 또 다른 것이지만 적절한 양의 메모리가 있는 모든 상자가 다른 모든 중요한 영역에서 적절하게 지정될 것이라고 가정하기 때문에 결국 메모리 테스트를 진행하기로 결정했습니다.
그리고 더 이상 문제가 없습니다! 이제 모든 최적화가 제대로 실행되고 있습니다. :)
이것은 좋은 아이디어처럼 들리며 그 힌트에 감사드립니다.
그러나 그것에 대해 3가지:
1) 위에서 언급했듯이 "무한" 루프의 문제도 있지만 이 스레드에서 "무한 루프"가 "하나의 이벤트가 10분 이상 소요됨"에 대한 최선의 추측일 뿐이라는 것을 이해했기 때문에 내 코드가 될 수 있습니다. 나는 매우 복잡한 표시기를 사용하며 (적어도 그렇게 생각합니다) 핸들이 생성될 때 전체 기록을 계산하기 때문에 (느린 컴퓨터에서는) 10분 이상 걸릴 수 있습니다.
2) 그러나! 일반적으로 내 클라우드는 10-15분 후에 충돌했습니다. 하지만 어젯밤에는 8시간 동안 완벽하게 작동했습니다. 코드를 전혀 변경하지 않았지만 단일 충돌은 발생하지 않았습니다. 기이한!
3) 그리고 가장 중요한 것은 접근 방식과 관련이 있기 때문입니다. 메모리를 기반으로 에이전트를 거부하면 에이전트(및 전체 클라우드)가 충돌하지 않습니다. 이해합니다. 그러나 더 강력한 기계가 동일한 매개변수 집합을 다시 시도하므로 기본적으로 최적화 데이터 포인트를 잃게 된다고 생각하지 않습니다. 맞습니까? 이것이 우리가 치러야 할 대가입니까?
직장에서 돌아온 후에도 에이전트가 계속 작동하는지 궁금할 것입니다...
...