1) 위에서 언급했듯이 "무한" 루프의 문제도 있지만 이 스레드에서 "무한 루프"가 "하나의 이벤트가 10분 이상 소요됨"에 대한 최선의 추측일 뿐이라는 것을 이해했기 때문에 내 코드가 될 수 있습니다. 나는 매우 복잡한 표시기를 사용하며 (적어도 그렇게 생각합니다) 핸들이 생성될 때 전체 기록을 계산하기 때문에 (느린 컴퓨터에서는) 10분 이상 걸릴 수 있습니다.
2) 그러나! 일반적으로 내 클라우드는 10-15분 후에 충돌했습니다. 하지만 어젯밤에는 8시간 동안 완벽하게 작동했습니다. 코드를 전혀 변경하지 않았지만 단일 충돌은 발생하지 않았습니다. 기이한!
3) 그리고 가장 중요한 것은 접근 방식과 관련이 있기 때문입니다. 에이전트의 메모리를 기반으로 에이전트를 거부하면 에이전트(및 전체 클라우드)가 충돌하지 않습니다. 이해합니다. 그러나 더 강력한 기계가 동일한 매개변수 집합을 다시 시도하므로 기본적으로 최적화 데이터 포인트를 잃게 된다고 생각하지 않습니다. 맞습니까? 이것이 우리가 치러야 할 대가입니까?
직장에서 돌아온 후에도 에이전트가 계속 작동하는지 궁금할 것입니다...
안녕하세요 시계님
1) 첫째, 지표를 사용하지 않는 한 10년 동안의 100만 데이터와 지표는 믿을 수 없을 정도로 복잡합니다. 나는 오늘날과 같은 처리 능력의 시대에 NORMAL 시스템에서 5분도 걸리지 않는 처리 능력에 매우 놀랐을 것입니다. . 여기에서 정상이라고 강조하는 이유는 클라우드에 부하가 극도로 많거나 단순히 Windows(외상 후 스트레스) 속도 저하 블루스의 나쁜 경우가 있는 시스템에서 실행되는 많은 에이전트가 있다고 여전히 의심하기 때문입니다. 그리고 당신의 최적화를 죽이는 데 단 한 명의 멍청한 에이전트가 필요합니다....
2) 나는 당신과 정확히 똑같았습니다. 즉, 최적화가 시작된 후 많은 클라우드 에이전트가 문제 없이 결과를 반환했습니다. 그런 다음 5-20분 또는 그보다 약간 더 긴 시간이 지나면 에이전트가 두려운 오류와 BANG - 최적화 종료를 던질 것입니다. 또한 문제 없이 완료되는 가끔 최적화도 있었습니다. 무슨 일이 일어나고 있는지 볼 수 있도록 에이전트 로그 파일, 시스템 세부 정보, CPU 사용량 등에 액세스할 수 없기 때문에 매우 실망스럽습니다.
3) 그것은 당신이 만드는 매우 흥미로운 포인트입니다. 내가 이해한 바에 따르면 옵티마이저는 매개변수의 특정 조합에 대한 결과를 얻었을 때 "사용된" 매개변수 의 특정 조합만 고려합니다. MetaQuotes의 누군가가 이 점에 대해 논평할 수 있습니까?
angevoyageur : 램 이 32G미만인 에이전트를 모두 거부할때 사용할 수 있는에이전트는 몇 명입니까?
안녕,
소비자용 PC에는 대용량 램으로 보이지만 클라우드에서는 이 사양의 머신을 찾는데 문제가 없어 보인다. 최적화를 시작하면 옵티마이저는 초기 64개 에이전트를 쉽게 찾은 다음 128개로 매우 빠르게 증가합니다(물론 매개변수 세트 구성에 따라 다름). 처음에는 8GB를 시도했습니다. 최적화가 더 오래 실행되고 종종 완료되었지만 여전히 정기적으로 에이전트가 오류를 생성하고 결과적으로 최적화가 중단되었습니다. 그런 다음 16GB를 시도했습니다. 다시 말하지만 더 좋았지만 완벽하지는 않았습니다. 나는 24GB를 시도하는 것을 귀찮게하지 않았습니다. 나는 곧장 32GB로 가서 무슨 일이 일어 났는지 볼 것이라고 생각했습니다. :) 그리고 짜잔 - 완벽한 최적화.
더 많이 놀아보고 에이전트 구성 요구 사항을 좀 더 잘 연마할 수 있는지 확인하고 싶었지만 장난으로 요금이 부과되면 인센티브가 빨리 사라집니다. :)
소비자용 PC에는 대용량 램으로 보이지만 클라우드에서는 이 사양의 머신을 찾는데 문제가 없어 보인다. 최적화를 시작하면 옵티마이저는 초기 64개 에이전트를 쉽게 찾은 다음 128개로 매우 빠르게 증가합니다(물론 매개변수 세트 구성에 따라 다름). 처음에는 8GB를 시도했습니다. 최적화가 더 오래 실행되고 종종 완료되었지만 여전히 정기적으로 에이전트가 오류를 생성하고 결과적으로 최적화가 중단되었습니다. 그런 다음 16GB를 시도했습니다. 다시 말하지만 더 좋았지만 완벽하지는 않았습니다. 나는 24GB를 시도하는 것을 귀찮게하지 않았습니다. 나는 곧장 32GB로 가서 무슨 일이 일어 났는지 볼 것이라고 생각했습니다. :) 그리고 짜잔 - 완벽한 최적화.
더 많이 놀아보고 에이전트 구성 요구 사항을 좀 더 잘 연마할 수 있는지 확인하고 싶었지만 장난으로 요금이 부과되면 인센티브가 빨리 사라집니다. :)
Metaquote에서 약간의 수익을 얻는 것은 흥미로울 것입니다. 16G 램이 장착된 시스템이 최적화를 실행하기에 충분하지 않은 경우 조사해야 할 사항이 있습니다. 내가 잘 이해한다면 로컬에서 최적화를 실행할 때 문제가 없는데 클라우드를 사용할 때 왜 그렇게 많은 메모리가 필요합니까?
angevoyageur : Metaquote에서 약간의 수익을 얻는 것은 흥미로울 것입니다. 16G 램이 장착된 시스템이 최적화를 실행하기에 충분하지 않은 경우 조사해야 할 사항이 있습니다. 내가 잘 이해한다면 로컬에서 최적화를 실행할 때 문제가 없는데 클라우드를 사용할 때 왜 그렇게 많은 메모리가 필요합니까?
나는 전혀 모른다. 내 로컬 시스템은 8GB i7 프로세서 시스템으로 MT5가 8개의 로컬 에이전트를 설치했습니다(분명히 4코어 프로세서이지만 하이퍼 스레딩을 사용하면 Windows 및 MT5는 이를 8코어 프로세서로 볼 수 있음). 최적화가 수행될 때 에이전트는 각각 약 400MB의 메모리를 사용하는 것으로 보이며 이는 분명히 8개의 에이전트에 필요한 약 3.2GB의 메모리로 작동합니다. 32GB도 안됨....
실제로 이 문제의 근본 원인이 될 수 있다고 생각했던 다른 것은 하나의 "나쁜" 클라우드 에이전트가 전체 최적화를 종료한다는 사실입니다. 실제로 일어날 수 있는 일은 클라우드 서버 가 최적화 작업을 위해 에이전트를 할당할 때(메모리 요구 사항은 명시되지 않음) 동일한 "나쁜" 에이전트가 선택된다는 것입니다. 메모리 요구 사항이 OnInit()에 명시되어 있으면 실행 중인 상자가 요구 사항을 충족하지 않고 좋은 에이전트만 선택되기 때문에 "불량" 에이전트는 무시됩니다. 곰곰이 생각해보면 아마 이게 더 맞을 것 같다.
그리고 네, 저는 이 문제를 MetaQuotes에 등록했지만 아직 아무 소식도 듣지 못했습니다.
느린 에이전트에서도 OnInit(또는 다른 기능)이 10분 이상 실행되면 MQL5 클라우드 네트워크에 유해한 무한 루프로 간주됩니다(로컬 및 원격 에이전트에는 이러한 제한이 없음).
이러한 상황을 위해 OnInit 함수에 대한 반환 코드 INIT_AGENT_NOT_SUITABLE을 구현했습니다. 이를 사용하여 클라우드 네트워크 사용자는 테스트 실행 초기에 부적합한 에이전트를 확인하고 거부할 수 있습니다.
이 댓글은 서비스 데스크 티켓에 대한 공식 답변으로 간주할 수 있습니다. 귀하가 위에 제공된 정보를 알고 있음을 알고 있습니다.
추가: 어떤 기능이든 가장 느린 PC에서도 실행이 10분 이상 걸린다면 어떤 기능이든 비정상적이고 비효율적이며 최적이 아닌 것으로 간주됩니다.
안녕하세요 MetaQuotes님,
먼저, 귀하의 의견에 진심으로 감사드립니다. 대단히 감사합니다.
내가 직면한 문제(및 이 게시물을 다시 보면 분명히 다른 사람들)는 로컬 에이전트를 사용하여 최적화를 수행할 때 최적화가 잘 실행된다는 것입니다. 즉, 최적화가 진행됨에 따라 각 에이전트의 "완료 비율" 상태가 꾸준히 증가합니다. 진행합니다. 내 Expert의 OnTick() 이벤트 핸들러에 완료하는 데 10분 이상(10분은 고사)이 소요되는 코드가 포함된 경우 "완료율" 백분율이 이 시간에 일시 중지됩니까? 내 코드에 클라우드 에이전트 오류가 암시하는 무한 반복 형식이 포함된 경우 이러한 상태 백분율에서 10분(또는 그 이상)의 일시 중지가 표시되어야 하지 않습니까?
글쎄, 몇 시간 동안 내 Expert를 축소한 후 OnInit() 또는 OnTick() "무한 루프" 오류 - 이것은 SymbolInfoInteger() 명령과 관련된 문제의 원인을 찾은 것으로 보입니다. SymbolInfoDouble() 또는 SymbolInfoTick()이 아직 더 이상 실험할 기회가 없었기 때문에 동일한 문제를 일으키는지 모르겠습니다. 누구든지 이것을 시도하고 싶다면 클라우드 에이전트를 사용하여 옵티마이저에서 다음 전문가를 실행하십시오.
OnInit() 또는 OnTick()을 테스트할지 여부를 선택하고 var1 및 var2에 충분한 시작/단계/중지 값을 지정하여 약 1000개의 조합을 생성하고(아마도 적은 수지만 이것이 제가 사용한 것입니다) 실행합니다. 옵티마이저. 약 10분 후에 "무한 루프가 감지되었습니다" 오류가 표시됩니다.
아, 그리고 OnTick() 끝에 "ExpertRemove()"를 넣은 이유 는 오류를 생성하기 위해 OnTick()을 한 번만 반복하면 된다는 것을 보여주기 위해서였습니다.
이것은 좋은 아이디어처럼 들리며 그 힌트에 감사드립니다.
그러나 그것에 대해 3가지:
1) 위에서 언급했듯이 "무한" 루프의 문제도 있지만 이 스레드에서 "무한 루프"가 "하나의 이벤트가 10분 이상 소요됨"에 대한 최선의 추측일 뿐이라는 것을 이해했기 때문에 내 코드가 될 수 있습니다. 나는 매우 복잡한 표시기를 사용하며 (적어도 그렇게 생각합니다) 핸들이 생성될 때 전체 기록을 계산하기 때문에 (느린 컴퓨터에서는) 10분 이상 걸릴 수 있습니다.
2) 그러나! 일반적으로 내 클라우드는 10-15분 후에 충돌했습니다. 하지만 어젯밤에는 8시간 동안 완벽하게 작동했습니다. 코드를 전혀 변경하지 않았지만 단일 충돌은 발생하지 않았습니다. 기이한!
3) 그리고 가장 중요한 것은 접근 방식과 관련이 있기 때문입니다. 에이전트의 메모리를 기반으로 에이전트를 거부하면 에이전트(및 전체 클라우드)가 충돌하지 않습니다. 이해합니다. 그러나 더 강력한 기계가 동일한 매개변수 집합을 다시 시도하므로 기본적으로 최적화 데이터 포인트를 잃게 된다고 생각하지 않습니다. 맞습니까? 이것이 우리가 치러야 할 대가입니까?
직장에서 돌아온 후에도 에이전트가 계속 작동하는지 궁금할 것입니다...
안녕하세요 시계님
1) 첫째, 지표를 사용하지 않는 한 10년 동안의 100만 데이터와 지표는 믿을 수 없을 정도로 복잡합니다. 나는 오늘날과 같은 처리 능력의 시대에 NORMAL 시스템에서 5분도 걸리지 않는 처리 능력에 매우 놀랐을 것입니다. . 여기에서 정상이라고 강조하는 이유는 클라우드에 부하가 극도로 많거나 단순히 Windows(외상 후 스트레스) 속도 저하 블루스의 나쁜 경우가 있는 시스템에서 실행되는 많은 에이전트가 있다고 여전히 의심하기 때문입니다. 그리고 당신의 최적화를 죽이는 데 단 한 명의 멍청한 에이전트가 필요합니다....
2) 나는 당신과 정확히 똑같았습니다. 즉, 최적화가 시작된 후 많은 클라우드 에이전트가 문제 없이 결과를 반환했습니다. 그런 다음 5-20분 또는 그보다 약간 더 긴 시간이 지나면 에이전트가 두려운 오류와 BANG - 최적화 종료를 던질 것입니다. 또한 문제 없이 완료되는 가끔 최적화도 있었습니다. 무슨 일이 일어나고 있는지 볼 수 있도록 에이전트 로그 파일, 시스템 세부 정보, CPU 사용량 등에 액세스할 수 없기 때문에 매우 실망스럽습니다.
3) 그것은 당신이 만드는 매우 흥미로운 포인트입니다. 내가 이해한 바에 따르면 옵티마이저는 매개변수의 특정 조합에 대한 결과를 얻었을 때 "사용된" 매개변수 의 특정 조합만 고려합니다. MetaQuotes의 누군가가 이 점에 대해 논평할 수 있습니까?
어쨌든, 나는 당신이 발전하기를 바랍니다! :)
램 이 32G 미만인 에이전트를 모두 거부할 때 사용할 수 있는 에이전트 는 몇 명입니까?
안녕,
소비자용 PC에는 대용량 램으로 보이지만 클라우드에서는 이 사양의 머신을 찾는데 문제가 없어 보인다. 최적화를 시작하면 옵티마이저는 초기 64개 에이전트를 쉽게 찾은 다음 128개로 매우 빠르게 증가합니다(물론 매개변수 세트 구성에 따라 다름). 처음에는 8GB를 시도했습니다. 최적화가 더 오래 실행되고 종종 완료되었지만 여전히 정기적으로 에이전트가 오류를 생성하고 결과적으로 최적화가 중단되었습니다. 그런 다음 16GB를 시도했습니다. 다시 말하지만 더 좋았지만 완벽하지는 않았습니다. 나는 24GB를 시도하는 것을 귀찮게하지 않았습니다. 나는 곧장 32GB로 가서 무슨 일이 일어 났는지 볼 것이라고 생각했습니다. :) 그리고 짜잔 - 완벽한 최적화.
더 많이 놀아보고 에이전트 구성 요구 사항을 좀 더 잘 연마할 수 있는지 확인하고 싶었지만 장난으로 요금이 부과되면 인센티브가 빨리 사라집니다. :)
안녕,
소비자용 PC에는 대용량 램으로 보이지만 클라우드에서는 이 사양의 머신을 찾는데 문제가 없어 보인다. 최적화를 시작하면 옵티마이저는 초기 64개 에이전트를 쉽게 찾은 다음 128개로 매우 빠르게 증가합니다(물론 매개변수 세트 구성에 따라 다름). 처음에는 8GB를 시도했습니다. 최적화가 더 오래 실행되고 종종 완료되었지만 여전히 정기적으로 에이전트가 오류를 생성하고 결과적으로 최적화가 중단되었습니다. 그런 다음 16GB를 시도했습니다. 다시 말하지만 더 좋았지만 완벽하지는 않았습니다. 나는 24GB를 시도하는 것을 귀찮게하지 않았습니다. 나는 곧장 32GB로 가서 무슨 일이 일어 났는지 볼 것이라고 생각했습니다. :) 그리고 짜잔 - 완벽한 최적화.
더 많이 놀아보고 에이전트 구성 요구 사항을 좀 더 잘 연마할 수 있는지 확인하고 싶었지만 장난으로 요금이 부과되면 인센티브가 빨리 사라집니다. :)
Metaquote에서 약간의 수익을 얻는 것은 흥미로울 것입니다. 16G 램이 장착된 시스템이 최적화를 실행하기에 충분하지 않은 경우 조사해야 할 사항이 있습니다. 내가 잘 이해한다면 로컬에서 최적화를 실행할 때 문제가 없는데 클라우드를 사용할 때 왜 그렇게 많은 메모리가 필요합니까?
나는 전혀 모른다. 내 로컬 시스템은 8GB i7 프로세서 시스템으로 MT5가 8개의 로컬 에이전트를 설치했습니다(분명히 4코어 프로세서이지만 하이퍼 스레딩을 사용하면 Windows 및 MT5는 이를 8코어 프로세서로 볼 수 있음). 최적화가 수행될 때 에이전트는 각각 약 400MB의 메모리를 사용하는 것으로 보이며 이는 분명히 8개의 에이전트에 필요한 약 3.2GB의 메모리로 작동합니다. 32GB도 안됨....
실제로 이 문제의 근본 원인이 될 수 있다고 생각했던 다른 것은 하나의 "나쁜" 클라우드 에이전트가 전체 최적화를 종료한다는 사실입니다. 실제로 일어날 수 있는 일은 클라우드 서버 가 최적화 작업을 위해 에이전트를 할당할 때(메모리 요구 사항은 명시되지 않음) 동일한 "나쁜" 에이전트가 선택된다는 것입니다. 메모리 요구 사항이 OnInit()에 명시되어 있으면 실행 중인 상자가 요구 사항을 충족하지 않고 좋은 에이전트만 선택되기 때문에 "불량" 에이전트는 무시됩니다. 곰곰이 생각해보면 아마 이게 더 맞을 것 같다.
그리고 네, 저는 이 문제를 MetaQuotes에 등록했지만 아직 아무 소식도 듣지 못했습니다.
느린 에이전트에서도 OnInit(또는 다른 기능)이 10분 이상 실행되면 MQL5 클라우드 네트워크에 유해한 무한 루프로 간주됩니다(로컬 및 원격 에이전트에는 이러한 제한이 없음).
이러한 상황을 위해 OnInit 함수에 대한 반환 코드 INIT_AGENT_NOT_SUITABLE을 구현했습니다. 이를 사용하여 클라우드 네트워크 사용자는 테스트 실행 초기에 부적합한 에이전트를 확인하고 거부할 수 있습니다.
이 댓글은 서비스 데스크 티켓에 대한 공식 답변으로 간주할 수 있습니다. 귀하가 위에 제공된 정보를 알고 있음을 알고 있습니다.
추가: 어떤 기능이든 가장 느린 PC에서도 실행이 10분 이상 걸린다면 어떤 기능이든 비정상적이고 비효율적이며 최적이 아닌 것으로 간주됩니다.
느린 에이전트에서도 OnInit(또는 다른 기능)이 10분 이상 실행되면 MQL5 클라우드 네트워크에 유해한 무한 루프로 간주됩니다(로컬 및 원격 에이전트에는 이러한 제한이 없음).
이러한 상황을 위해 OnInit 함수에 대한 반환 코드 INIT_AGENT_NOT_SUITABLE을 구현했습니다. 이를 사용하여 클라우드 네트워크 사용자는 테스트 실행 초기에 부적합한 에이전트를 확인하고 거부할 수 있습니다.
이 댓글은 서비스 데스크 티켓에 대한 공식 답변으로 간주할 수 있습니다. 귀하가 위에 제공된 정보를 알고 있음을 알고 있습니다.
추가: 어떤 기능이든 가장 느린 PC에서도 실행이 10분 이상 걸린다면 어떤 기능이든 비정상적이고 비효율적이며 최적이 아닌 것으로 간주됩니다.
안녕하세요 MetaQuotes님,
먼저, 귀하의 의견에 진심으로 감사드립니다. 대단히 감사합니다.
내가 직면한 문제(및 이 게시물을 다시 보면 분명히 다른 사람들)는 로컬 에이전트를 사용하여 최적화를 수행할 때 최적화가 잘 실행된다는 것입니다. 즉, 최적화가 진행됨에 따라 각 에이전트의 "완료 비율" 상태가 꾸준히 증가합니다. 진행합니다. 내 Expert의 OnTick() 이벤트 핸들러에 완료하는 데 10분 이상(10분은 고사)이 소요되는 코드가 포함된 경우 "완료율" 백분율이 이 시간에 일시 중지됩니까? 내 코드에 클라우드 에이전트 오류가 암시하는 무한 반복 형식이 포함된 경우 이러한 상태 백분율에서 10분(또는 그 이상)의 일시 중지가 표시되어야 하지 않습니까?
글쎄, 몇 시간 동안 내 Expert를 축소한 후 OnInit() 또는 OnTick() "무한 루프" 오류 - 이것은 SymbolInfoInteger() 명령과 관련된 문제의 원인을 찾은 것으로 보입니다. SymbolInfoDouble() 또는 SymbolInfoTick()이 아직 더 이상 실험할 기회가 없었기 때문에 동일한 문제를 일으키는지 모르겠습니다. 누구든지 이것을 시도하고 싶다면 클라우드 에이전트를 사용하여 옵티마이저에서 다음 전문가를 실행하십시오.
OnInit() 또는 OnTick()을 테스트할지 여부를 선택하고 var1 및 var2에 충분한 시작/단계/중지 값을 지정하여 약 1000개의 조합을 생성하고(아마도 적은 수지만 이것이 제가 사용한 것입니다) 실행합니다. 옵티마이저. 약 10분 후에 "무한 루프가 감지되었습니다" 오류가 표시됩니다.
아, 그리고 OnTick() 끝에 "ExpertRemove()"를 넣은 이유 는 오류를 생성하기 위해 OnTick()을 한 번만 반복하면 된다는 것을 보여주기 위해서였습니다.
말할것도 없이 서비스데스크에도 신고했는데...
이 문제를 확인할 수 있습니다.
2013.05.20 14:22:31 MQL5 Cloud Europe 2 유전자 패스(0, 22)가 602초(PR 140)에 "OnInit 기능에서 무한 루프 감지, MQL5 Cloud Network 에서 전문가 거부" 오류로 테스트됨