notused : 최적화 중 패스 결과와 싱글 패스 결과가 일치하지 않습니다. (서비스 데스크 - #329165 + 같은 자리에 있는 어드바이저)
빌드 619 ? 같은 문제가 나타나기 시작했습니다. 하지만 항상 그런 것은 아닙니다. 결과가 동일한 경우, 즉 새로운 최적화를 수행하지 않았지만 어떤 이유로 테스트할 때 결과가 이미 다릅니다. 예를 들어, 차트의 총 이익은 목록의 이익과 다릅니다. 잠시 후 모든 것이 복원됩니다. 빌드 619 전에는 이것을 눈치채지 못했습니다.
tol64 : 빌드 619 ? 같은 문제가 나타나기 시작했습니다. 하지만 항상 그런 것은 아닙니다. 결과가 동일한 경우, 즉 새로운 최적화를 수행하지 않았지만 어떤 이유로 테스트할 때 결과가 이미 다릅니다. 예를 들어, 차트의 총 이익은 목록의 이익과 다릅니다. 잠시 후 모든 것이 복원됩니다. 빌드 619 전에는 이것을 눈치채지 못했습니다.
빌드 607 이상(아직 새로운 FIBO로 업데이트되지 않음). 아마도 문제는 다중 통화 및 타이머(OnTick()는 사용되지 않음)에 있지만 확실하지 않습니다.
전략 테스터 로 마지막 빌드 에서 뭔가 엉망 입니다 . 갑자기(아주 "갑자기"는 아니지만 빌드 619로 업데이트한 후) EA 테스트가 거의 중단되었습니다(요청 #329165에서와 동일) - 메모리가 헤아릴 수 없을 정도로 소모되기 시작했습니다(5년 동안 "모든 틱" 모드):
마지막 열은 "VM 크기"입니다. 보시다시피 4개의 코어 + 4개의 "원격" 로컬 에이전트가 있습니다(항상 잘 작동함).
동시에 시스템이 매우 심하게 느려지기 시작하고(예, PageFile에 대해 4GB RAM + 16GB를 제공했습니다) 최적화 속도는 무한대가 되는 경향이 있습니다. 보시다시피 프로세서 시간은 실제로 사용되지 않습니다.
로그의 오류는 다음과 같습니다.
이것은 메모리 부족으로 인한 것 같습니다.
"중지"를 누릅니다. 메모리가 즉시 해제되지 않습니다. 5분 후 로컬 에이전트가 사라지고 2분 후에 원격 에이전트의 메모리가 해제되었습니다.
한 에이전트가 중단할 수 있는 시간이 100MB 이상 남아 있는 이유는 명확하지 않습니다(프로세서 시간이 사용되지 않기 때문에 클라우드가 이를 가져갔다고 믿지 않습니다).
음, "원격" 로컬 에이전트를 비활성화하고 있습니다. 변경 사항 없음(시스템 브레이크 및 오류).
글쎄, 나는 그것이 죄라고 생각한다. 내 조언자에게 오류가 있다. 따라서 테스트를 위해 2007.09.01에서 2012.03.26까지 표준 ExpertMACD, EURUSD, h12를 시작합니다.
그리고 ... 같은 그림 - 브레이크, 미친 메모리 소비 (표시기는 첫 번째 그림과 거의 동일함) + "전문가를 초기화할 수 없음".
두 경우 모두 일부 구절은 여전히 발생합니다.
로그가 첨부되었습니다.
매우 흥미로운 라인:
CJ 0 local4 17 : 42 : 32 USDNOK: history synchronization started
QL 0 Core 117 : 42 : 33 USDNOK: history synchronization started
RK 0 local4 17 : 43 : 49 USDNOK: history downloading completed
GL 0 Core 117 : 43 : 49 USDNOK: history downloading completed
NM 0 Core 117 : 43 : 49 USDNOK: history for2006 year synchronized
QJ 0 local4 17 : 43 : 49 USDNOK: history for2006 year synchronized
등 USDNOK - 하나의 SGDJPY 기호가 내 EA 코드에서 깜박였습니다. - USDSGD 대신 USDNOK(USDJPY는 로그에 의해 성공적으로 업로드됨)를 다운로드하는 이유는 무엇입니까?
있는 경우 서버는 FIBOGroup-MT5-server입니다.
PS 이전 빌드에서는 이러한 문제를 관찰하지 못했습니다.
PPS 게으르지 않은 사람 - 모든 틱에 대해 지난 5년 동안 표준 ExpertMACD의 최적화를 확인하십시오.
전략 테스터 로 마지막 빌드 에서 뭔가 엉망 입니다 . 갑자기(아주 "갑자기"는 아니지만 빌드 619로 업데이트한 후) EA 테스트가 거의 중단되었습니다(요청 #329165에서와 동일) - 메모리가 헤아릴 수 없을 정도로 소모되기 시작했습니다(5년 동안 "모든 틱" 모드):
마지막 열은 "VM 크기"입니다. 보시다시피 4개의 코어 + 4개의 "원격" 로컬 에이전트가 있습니다(항상 잘 작동함).
동시에 시스템이 매우 심하게 느려지기 시작하고(예, PageFile에 대해 4GB RAM + 16GB를 제공했습니다) 최적화 속도는 무한대가 되는 경향이 있습니다. 보시다시피 프로세서 시간은 실제로 사용되지 않습니다.
코어보다 더 많은 에이전트를 실행하지 않는 것이 좋습니다. 에이전트 수가 너무 많으면 속도가 비선형적으로 떨어지고 리소스 비용이 증가합니다. 특히 4Gb의 메모리만 있고 에이전트가 기가바이트 이상을 차지하는 경우에 그렇습니다.
기본 터미널 작업을 수행하는 동일한 컴퓨터에 원격 에이전트를 설치하지 마십시오.
로그의 오류는 다음과 같습니다.
이것은 메모리 부족으로 인한 것 같습니다.
"중지"를 누릅니다. 메모리가 즉시 해제되지 않습니다. 5분 후 로컬 에이전트가 사라지고 2분 후에 원격 에이전트의 메모리가 해제되었습니다.
예, 메모리(캐시)는 약 5분 후에 해제됩니다. 그들은 다음 출시의 경우에 특별히 보관되므로 마지막 출시에서 사용된 것과 동일한 데이터를 가장 자주 워밍업하는 데 시간을 낭비하지 않습니다.
최신 빌드에서는 캐시 작동 방식을 변경하여 반복 패스 속도를 높이기 위해 캐시를 늘렸습니다.
한 에이전트가 중단할 수 있는 시간이 100MB 이상 남아 있는 이유는 명확하지 않습니다(프로세서 시간이 사용되지 않기 때문에 클라우드가 이를 가져갔다고 믿지 않습니다).
음, "원격" 로컬 에이전트를 비활성화합니다. 변경 사항 없음(시스템 브레이크 및 오류).
글쎄, 나는 그것이 죄라고 생각한다. 내 조언자에게 오류가 있다. 따라서 테스트를 위해 2007.09.01에서 2012.03.26까지 표준 ExpertMACD, EURUSD, h12를 시작합니다.
최신 빌드로 업그레이드한 후 EA를 다시 컴파일하셨나요?
귀하의 경우 문제는 지속적인 스와핑과 메모리 부족으로 인한 브레이크에 있습니다. 팁: 불필요한 원격 에이전트를 비활성화하십시오.
notused : 클라우드 통계에서 볼 수 있습니다 - 4개, 에이전트 8개 - PR은 여전히 150-190 영역에 있습니다(브라우저 코어에 분명히 속하는 1/2 제외) 비활성화된 원격 에이전트 ... 전문가 재컴파일 . 나는 심지어 일반 ExpertMACD를 다시 컴파일했습니다.
비활성화, 최적화를 위해 ExpertMACD 시작 및:
이제 하나를 제외한 모든 에이전트(로컬 에이전트 포함)를 비활성화했습니다.
그리고 지금 무엇? 상담원 1명에 4GB로는 부족하다? (메모리 사용량이 350MB이지만 VM 크기 = 1.24GB).
확인해보시겠어요? 재생 단계 - 이전 게시물에서
오류를 보기 위해 전문가의 로그를 보는 것으로 충분했습니다.
ExpertMACD (EURUSD,H1) 22 : 50 : 541971.01 . 0500 : 00 : 00 CExpertBase::InitHigh: error initializing object
ExpertMACD (EURUSD,H1) 22 : 50 : 541971.01 . 0500 : 00 : 00OnInit : error initializing indicators
ExpertMACD (EURUSD,H1) 22:55:07 2012.01.01 00:00:00 CSignalMACD::ValidationSettings: slow period must be greater than fast period
ExpertMACD (EURUSD,H1) 22:55:07 2012.01.01 00:00:00 OnInit: error signal parameters
적절한 기간과 적절한 설정을 선택하십시오. 기본 제한을 사용하면 잘못된 매개변수를 많이 생성할 수 있습니다.
1) 코드를 리팩토링하는 동안 변수 값의 명시적 할당을 잃어버렸고 열린 위치의 볼륨에 대해 때때로 (매우 무작위로) 임의의 결과를 얻었습니다. 이 오류를 수정한 후 결과가 변경되지 않았음을 확인했습니다. 테스트 결과가 최적화와 일치하지 않습니다. 다양한 벌목과 탬버린으로 춤을 추면서 문제가 상당히 오래된 것으로 나타났습니다.
2) 2011년 챔피언십이 시작되기 전에 테스터가 주말 에 거래를 한다고 보고했습니다. 레나트는 확인하겠다고 약속했다. 그러나 문제는 여전히 남아 있습니다. 저는 우연찮게 시험기간의 시작일인 2007.09.01을 쉬는 날로 선택했습니다. 그래서 옵티마이저는 그날 거래를 하지 않지만 테스터는 거래를 합니다. 또는 옵티마이저에서는 출력에서 OrderSend에 도달하지 않지만 테스터에서는 도달합니다. 내 Expert Advisor의 논리에 따라 최적화 간격의 시작이 쉬는 날이면 첫 번째 타이머 트리거에서 ACCOUNT_EQUITY = 0!!! 그리고 테스터에서 ACCOUNT_EQUITY = ACCOUNT_BALANCE(초기 예금에서 설정한 것). 최적화 간격의 시작이 근무일이면 옵티마이저와 테스터의 동작이 동일합니다.
전체적으로 두 가지 버그가 있습니다.
1) 테스터를 사용하면 주말에 거래를 열 수 있습니다. 그러면 안됩니다. (그리고 이것이 내 실수라고 말하지 마십시오. 내 실수를 수정하고 테스터의 버그가 반년 이상 걸려 있음)
2) 타이머의 첫 번째 트리거에서 기간의 시작이 쉬는 날이면 ACCOUNT_EQUITY = 0이고 테스터에서는 ACCOUNT_EQUITY = ACCOUNT_BALANCE입니다. 하나의 형식으로 가져와야 합니다(물론 첫 번째 오류가 수정된 ACCOUNT_EQUITY = ACCOUNT_BALANCE에 더 좋습니다).
최적화 중 패스 결과와 싱글 패스 결과가 일치하지 않습니다. (서비스 데스크 - #329165 + 같은 자리에 있는 어드바이저)
최적화 중 패스 결과와 싱글 패스 결과가 일치하지 않습니다. (서비스 데스크 - #329165 + 같은 자리에 있는 어드바이저)
빌드 619 ? 같은 문제가 나타나기 시작했습니다. 하지만 항상 그런 것은 아닙니다. 결과가 동일한 경우, 즉 새로운 최적화를 수행하지 않았지만 어떤 이유로 테스트할 때 결과가 이미 다릅니다. 예를 들어, 차트의 총 이익은 목록의 이익과 다릅니다. 잠시 후 모든 것이 복원됩니다. 빌드 619 전에는 이것을 눈치채지 못했습니다.
빌드 607 이상(아직 새로운 FIBO로 업데이트되지 않음). 아마도 문제는 다중 통화 및 타이머(OnTick()는 사용되지 않음)에 있지만 확실하지 않습니다.
전략 테스터 로 마지막 빌드 에서 뭔가 엉망 입니다 . 갑자기(아주 "갑자기"는 아니지만 빌드 619로 업데이트한 후) EA 테스트가 거의 중단되었습니다(요청 #329165에서와 동일) - 메모리가 헤아릴 수 없을 정도로 소모되기 시작했습니다(5년 동안 "모든 틱" 모드):
마지막 열은 "VM 크기"입니다. 보시다시피 4개의 코어 + 4개의 "원격" 로컬 에이전트가 있습니다(항상 잘 작동함).
동시에 시스템이 매우 심하게 느려지기 시작하고(예, PageFile에 대해 4GB RAM + 16GB를 제공했습니다) 최적화 속도는 무한대가 되는 경향이 있습니다. 보시다시피 프로세서 시간은 실제로 사용되지 않습니다.
로그의 오류는 다음과 같습니다.
이것은 메모리 부족으로 인한 것 같습니다.
"중지"를 누릅니다. 메모리가 즉시 해제되지 않습니다. 5분 후 로컬 에이전트가 사라지고 2분 후에 원격 에이전트의 메모리가 해제되었습니다.
한 에이전트가 중단할 수 있는 시간이 100MB 이상 남아 있는 이유는 명확하지 않습니다(프로세서 시간이 사용되지 않기 때문에 클라우드가 이를 가져갔다고 믿지 않습니다).
음, "원격" 로컬 에이전트를 비활성화하고 있습니다. 변경 사항 없음(시스템 브레이크 및 오류).
글쎄, 나는 그것이 죄라고 생각한다. 내 조언자에게 오류가 있다. 따라서 테스트를 위해 2007.09.01에서 2012.03.26까지 표준 ExpertMACD, EURUSD, h12를 시작합니다.
그리고 ... 같은 그림 - 브레이크, 미친 메모리 소비 (표시기는 첫 번째 그림과 거의 동일함) + "전문가를 초기화할 수 없음".
두 경우 모두 일부 구절은 여전히 발생합니다.
로그가 첨부되었습니다.
매우 흥미로운 라인:
등 USDNOK - 하나의 SGDJPY 기호가 내 EA 코드에서 깜박였습니다. - USDSGD 대신 USDNOK(USDJPY는 로그에 의해 성공적으로 업로드됨)를 다운로드하는 이유는 무엇입니까?
있는 경우 서버는 FIBOGroup-MT5-server입니다.
PS 이전 빌드에서는 이러한 문제를 관찰하지 못했습니다.
PPS 게으르지 않은 사람 - 모든 틱에 대해 지난 5년 동안 표준 ExpertMACD의 최적화를 확인하십시오.
전략 테스터 로 마지막 빌드 에서 뭔가 엉망 입니다 . 갑자기(아주 "갑자기"는 아니지만 빌드 619로 업데이트한 후) EA 테스트가 거의 중단되었습니다(요청 #329165에서와 동일) - 메모리가 헤아릴 수 없을 정도로 소모되기 시작했습니다(5년 동안 "모든 틱" 모드):
마지막 열은 "VM 크기"입니다. 보시다시피 4개의 코어 + 4개의 "원격" 로컬 에이전트가 있습니다(항상 잘 작동함).동시에 시스템이 매우 심하게 느려지기 시작하고(예, PageFile에 대해 4GB RAM + 16GB를 제공했습니다) 최적화 속도는 무한대가 되는 경향이 있습니다. 보시다시피 프로세서 시간은 실제로 사용되지 않습니다.
코어보다 더 많은 에이전트를 실행하지 않는 것이 좋습니다. 에이전트 수가 너무 많으면 속도가 비선형적으로 떨어지고 리소스 비용이 증가합니다. 특히 4Gb의 메모리만 있고 에이전트가 기가바이트 이상을 차지하는 경우에 그렇습니다.
기본 터미널 작업을 수행하는 동일한 컴퓨터에 원격 에이전트를 설치하지 마십시오.
로그의 오류는 다음과 같습니다.
이것은 메모리 부족으로 인한 것 같습니다.
"중지"를 누릅니다. 메모리가 즉시 해제되지 않습니다. 5분 후 로컬 에이전트가 사라지고 2분 후에 원격 에이전트의 메모리가 해제되었습니다.
예, 메모리(캐시)는 약 5분 후에 해제됩니다. 그들은 다음 출시의 경우에 특별히 보관되므로 마지막 출시에서 사용된 것과 동일한 데이터를 가장 자주 워밍업하는 데 시간을 낭비하지 않습니다.
최신 빌드에서는 캐시 작동 방식을 변경하여 반복 패스 속도를 높이기 위해 캐시를 늘렸습니다.
한 에이전트가 중단할 수 있는 시간이 100MB 이상 남아 있는 이유는 명확하지 않습니다(프로세서 시간이 사용되지 않기 때문에 클라우드가 이를 가져갔다고 믿지 않습니다).
음, "원격" 로컬 에이전트를 비활성화합니다. 변경 사항 없음(시스템 브레이크 및 오류).
글쎄, 나는 그것이 죄라고 생각한다. 내 조언자에게 오류가 있다. 따라서 테스트를 위해 2007.09.01에서 2012.03.26까지 표준 ExpertMACD, EURUSD, h12를 시작합니다.
최신 빌드로 업그레이드한 후 EA를 다시 컴파일하셨나요?
귀하의 경우 문제는 지속적인 스와핑과 메모리 부족으로 인한 브레이크에 있습니다. 팁: 불필요한 원격 에이전트를 비활성화하십시오.
코어보다 더 많은 에이전트를 실행하지 않는 것이 좋습니다. 에이전트 수가 너무 많으면 속도가 비선형적으로 떨어지고 리소스 비용이 증가합니다. 특히 4Gb의 메모리만 있고 에이전트가 기가바이트 이상을 소비하는 경우에는 더욱 그렇습니다.
기본 터미널 작업을 수행하는 동일한 컴퓨터에 원격 에이전트를 설치하지 마십시오.
최신 빌드로 업그레이드한 후 EA를 다시 컴파일하셨나요?
귀하의 경우 문제는 지속적인 스와핑과 메모리 부족으로 인한 브레이크에 있습니다.
팁: 불필요한 원격 에이전트를 비활성화하십시오.
비활성화, 최적화를 위해 ExpertMACD 시작 및:
이제 하나를 제외한 모든 에이전트(로컬 에이전트 포함)를 비활성화했습니다.
그리고 지금 무엇? 4GB로는 상담원 1명으로 충분하지 않습니까? (메모리 사용량이 350MB이지만 VM 크기 = 1.24GB). 그리고 4GB도 없는 사람들은 어떻습니까?
확인해보시겠어요? 재생 단계 - 이전 게시물에서
클라우드 통계에서 볼 수 있습니다 - 4개, 에이전트 8개 - PR은 여전히 150-190 영역에 있습니다(브라우저 코어에 분명히 속하는 1/2 제외) 비활성화된 원격 에이전트 ... 전문가 재컴파일 . 나는 심지어 일반 ExpertMACD를 다시 컴파일했습니다.
비활성화, 최적화를 위해 ExpertMACD 시작 및:
이제 하나를 제외한 모든 에이전트(로컬 에이전트 포함)를 비활성화했습니다.
그리고 지금 무엇? 상담원 1명에 4GB로는 부족하다? (메모리 사용량이 350MB이지만 VM 크기 = 1.24GB).
확인해보시겠어요? 재생 단계 - 이전 게시물에서
오류를 보기 위해 전문가의 로그를 보는 것으로 충분했습니다.
적절한 기간과 적절한 설정을 선택하십시오. 기본 제한을 사용하면 잘못된 매개변수를 많이 생성할 수 있습니다.
오류를 보기 위해 전문가의 로그를 보는 것으로 충분했습니다.
적절한 기간과 적절한 설정을 선택하십시오. 기본 제한을 사용하면 잘못된 매개변수를 많이 생성할 수 있습니다.
예, 실제로 문제는 기본 매개변수에 있었습니다. 변경됨 - 모든 것이 정상적으로 테스트됩니다. 나는 나의 고문에게 돌아왔다 - 그것은 "비행도 정상"인 것 같다.
전체적으로 코어당 두 에이전트의 존재가 이전에 작별 인사였다면 지금은 확실히 그렇지 않습니다.
합계2. 내가 틀렸어, 시간을 들여서 미안하다 (그러나 서비스 데스크 - # 329165는 아직 그것을 알아내지 못했다)
알아봅시다.
뭔가 지연되었습니다. 그 동안 나는 무슨 일이 일어나고 있는지 알아 냈습니다.
1) 코드를 리팩토링하는 동안 변수 값의 명시적 할당을 잃어버렸고 열린 위치의 볼륨에 대해 때때로 (매우 무작위로) 임의의 결과를 얻었습니다. 이 오류를 수정한 후 결과가 변경되지 않았음을 확인했습니다. 테스트 결과가 최적화와 일치하지 않습니다. 다양한 벌목과 탬버린으로 춤을 추면서 문제가 상당히 오래된 것으로 나타났습니다.
2) 2011년 챔피언십이 시작되기 전에 테스터가 주말 에 거래를 한다고 보고했습니다. 레나트는 확인하겠다고 약속했다. 그러나 문제는 여전히 남아 있습니다. 저는 우연찮게 시험기간의 시작일인 2007.09.01을 쉬는 날로 선택했습니다. 그래서 옵티마이저는 그날 거래를 하지 않지만 테스터는 거래를 합니다. 또는 옵티마이저에서는 출력에서 OrderSend에 도달하지 않지만 테스터에서는 도달합니다. 내 Expert Advisor의 논리에 따라 최적화 간격의 시작이 쉬는 날이면 첫 번째 타이머 트리거에서 ACCOUNT_EQUITY = 0!!! 그리고 테스터에서 ACCOUNT_EQUITY = ACCOUNT_BALANCE(초기 예금에서 설정한 것). 최적화 간격의 시작이 근무일이면 옵티마이저와 테스터의 동작이 동일합니다.
전체적으로 두 가지 버그가 있습니다.
1) 테스터를 사용하면 주말에 거래를 열 수 있습니다. 그러면 안됩니다. (그리고 이것이 내 실수라고 말하지 마십시오. 내 실수를 수정하고 테스터의 버그가 반년 이상 걸려 있음)
2) 타이머의 첫 번째 트리거에서 기간의 시작이 쉬는 날이면 ACCOUNT_EQUITY = 0이고 테스터에서는 ACCOUNT_EQUITY = ACCOUNT_BALANCE입니다. 하나의 형식으로 가져와야 합니다(물론 첫 번째 오류가 수정된 ACCOUNT_EQUITY = ACCOUNT_BALANCE에 더 좋습니다).
요청 시 서비스 데스크에서 #329165 테스트를 위해 전문가를 연결하겠습니다.