PS 즉석에서 클라우드를 켭니다. 인터넷 손실로 인해 원격 에이전트가 떨어졌습니다. 그런 다음 그들은 연결하기를 원하지 않았습니다(승인된 상태, 적어도 두 개의 유전 세대가 연결되지 않음) - 분명히 테스터는 클라우드에 대한 작업이 충분하고 자유 에이전트가 쉬도록 하기로 결정했습니다. 비활성화된 클라우드. 원격 에이전트가 연결되었습니다. 클라우드가 켜졌습니다. 글쎄, 결국 나는 중단되었습니다.
+ 유전학의 속도는 가장 약한 코어의 속도에 따라 달라집니다 - 내 코어의 PR이 160-180이고 클라우드의 작업이 최대 100개의 코어에 분산되어 있는 경우. 결과적으로 모든 세대에서 내 코어는 강제로 상당한 시간 동안 유휴 상태를 유지하고 새로운 인구를 생성하기 위해 클라우드의 응답을 기다립니다. 100PR 한도를 포기하고 가장 약한 로컬 코어(+ 또는 원격 코어가 연결된 경우)의 PR 보다 PR이 큰 에이전트가 먼저 발행되어야 한다고 생각합니다. 아무 것도 없다면 부하는 어떻게 든 제 시간에 균형을 잡아야합니다. 예를 들어 모든 패스가 동일한 코어에서 동일한 속도로 실행된다고 가정하면(실제에서는 그렇지 않지만 많은 전문가는 몇 가지 가정을 통해 테스트 시간에 관계없이 테스트 시간이 안정적이라고 할 수 있습니다. 매개변수). 로컬 코어의 PR이 150이고 클라우드의 코어의 PR이 100이라면 로컬 에이전트는 클라우드의 에이전트보다 1.5배 많은 작업을 해야 합니다. 또는 낮은 PR로 클라우드의 에이전트에게 작업 팩을 발행하지 말고 한 번에 하나씩 더 넓은 범위의 에이전트에게 발행하십시오. 이 경우 가동 중지 시간이 최소화됩니다. 일반적으로 이 문제에 진전이 있기를 바랍니다.
그건 그렇고, ssd에서 에이전트를 공유하려고 했습니까? 작업 없이도 내 나사가 8개의 에이전트에서 크런치하기 시작하는 방식을 고려하면 ssd 리소스가 빠르게 소모되고 있다는 의혹이 있습니다. 그리고 상당히 가벼운 Expert Advisor를 테스트할 때 계산 속도가 하드 드라이브의 속도로 실행되기 시작합니다. 캐시에 몇 테라바이트가 펌핑되는지는 좋은 질문입니다.)
sion : 그건 그렇고, ssd에서 에이전트를 공유하려고 했습니까? 작업 없이도 내 나사가 8개의 에이전트에서 크런치하기 시작하는 방식을 고려하면 ssd 리소스가 빠르게 소모되고 있다는 의혹이 있습니다. 그리고 상당히 가벼운 Expert Advisor를 테스트할 때 계산 속도가 하드 드라이브의 속도로 실행되기 시작합니다. 캐시에 몇 테라바이트가 펌핑되는지는 좋은 질문입니다.)
알파벳에 그런 글자가 있지만(ssd에 대해 말하는 것입니다) 특정 테스트는 하지 않았습니다. 그러한 장치가 있는 서버는 도시의 반대편에 있습니다. 그러나 IMHO에는 모든 시스템에 빈번한 디스크 액세스를 원활하게 해주는 디스크 캐시가 있습니다.
이 클라우드에서 누가 그렇게 많은 리소스를 공유했는지 궁금합니다. 시스템의 마모와 전기 소비는 하루에 분명히 2-3센트 이상입니다. 여러 번 리소스를 제공 하려고 시도했지만 나사에 10GB 미만(9GB RAM 포함)이 있고 유전학 다운로드가 일부 포함되어 있으면 시스템이 먹히지 않더라도 멍청하게 멈춥니다. 모든 여유 공간(스왑 이전까지의 RAM 등), 하나의 무화과 나사가 캐시를 최대로 펌핑하려고 하므로 와일드 브레이크가 발생합니다.
나는 두 쌍의 모든 틱에서 간단한 그리더(30초 타이머, 새로운 m1 막대 제어)를 최적화하기로 결정했습니다. 제 i5 코어 4개(PR=160-170)와 i7 코어 8개(PR=170-180)는 약 90(!) 시간의 최적화 시간을 제공했습니다.
그런 다음 i5에 대한 패스가 2배 더 느리게 테스트되는 것으로 나타났습니다(여러 번 썼지만 이전에는 모든 것이 반대였습니다. i5 + winxp64가 i7 + win7x64보다 빠름). 처음에 나는 그것을 메모리로 깎았습니다 - 그것은 i7에 더 있습니다.
그러다 우연히 작업 관리자를 살펴보니 상담원의 우선 순위가 가장 낮습니다(낮음). 그리고 두 기계 모두에서. 그리고 win7에서 우선 순위를 Normal로 올릴 수 있었다면 어떤 이유로 winxp64bit는 그것을 허용하지 않습니다. i7에 대한 새로운 우선 순위로 반나절 동안 테스트 시간이 몇 시간 단축되었습니다(예: :)).
이러한 "브레이크"는 마지막 두 빌드인 것 같습니다(또는 나에게만 보일 수도 있음).
그리고 낮은 우선 순위는 너무 잔인합니다. 하루에 최소 12시간 동안 장비가 에이전트에게 가장 높은 우선 순위를 줄 수 있다면.
일반적으로 리소스 로딩부터 어떻게든 우선순위가 자동으로 바뀌는 줄 알았는데 자체는 바뀌지 않는 것 같아요 :(
8개 코어(사실상 4개 + 하이퍼트레이딩)에 24개 에이전트가 있으면 인프라 프로비저닝에 모든 프로세서 성능을 소비하게 될 것입니다.
과도한 수의 에이전트를 노출하면 PR 성과 지수가 급격히 떨어지며 지불의 다중 감소로 이어집니다.
한동안 클라우드를 사용하지 않았습니다. 매개변수를 선택할 때 사용하기로 결정했습니다. 클라우드의 작업은 매우 놀랐습니다.
분산 네트워크 시스템을 오랫동안 연마하면 결과가 좋습니다.
일반적으로 한 시간 반 동안 전혀 당기지 않습니다.
PS 즉석에서 클라우드를 켭니다. 인터넷 손실로 인해 원격 에이전트가 떨어졌습니다. 그런 다음 그들은 연결하기를 원하지 않았습니다(승인된 상태, 적어도 두 개의 유전 세대가 연결되지 않음) - 분명히 테스터는 클라우드에 대한 작업이 충분하고 자유 에이전트가 쉬도록 하기로 결정했습니다. 비활성화된 클라우드. 원격 에이전트가 연결되었습니다. 클라우드가 켜졌습니다. 글쎄, 결국 나는 중단되었습니다.
이러한 상황이 발생하지 않도록 네트워크를 약간 마무리해야 합니다(예: 최대 통과 시간을 기억하고 통과 대기 시간이 최대 통과 시간보다 2배 이상 지속되는 경우 - 최상의 로컬에서 동일한 프로세스 시작 (또는 원격) 코어).
+ TerminalInfoInteger 수정 필요(TERMINAL_MEMORY_AVAILABLE)
+ 유전학의 속도는 가장 약한 코어의 속도에 따라 달라집니다 - 내 코어의 PR이 160-180이고 클라우드의 작업이 최대 100개의 코어에 분산되어 있는 경우. 결과적으로 모든 세대에서 내 코어는 강제로 상당한 시간 동안 유휴 상태를 유지하고 새로운 인구를 생성하기 위해 클라우드의 응답을 기다립니다. 100PR 한도를 포기하고 가장 약한 로컬 코어(+ 또는 원격 코어가 연결된 경우)의 PR 보다 PR이 큰 에이전트가 먼저 발행되어야 한다고 생각합니다. 아무 것도 없다면 부하는 어떻게 든 제 시간에 균형을 잡아야합니다. 예를 들어 모든 패스가 동일한 코어에서 동일한 속도로 실행된다고 가정하면(실제에서는 그렇지 않지만 많은 전문가는 몇 가지 가정을 통해 테스트 시간에 관계없이 테스트 시간이 안정적이라고 할 수 있습니다. 매개변수). 로컬 코어의 PR이 150이고 클라우드의 코어의 PR이 100이라면 로컬 에이전트는 클라우드의 에이전트보다 1.5배 많은 작업을 해야 합니다. 또는 낮은 PR로 클라우드의 에이전트에게 작업 팩을 발행하지 말고 한 번에 하나씩 더 넓은 범위의 에이전트에게 발행하십시오. 이 경우 가동 중지 시간이 최소화됩니다. 일반적으로 이 문제에 진전이 있기를 바랍니다.
지난 12시간 동안 네트워크가 세 번 더 중단되었습니다.
(그리고 유전학 저널에 PR < 100인 에이전트가 있습니다)
그건 그렇고, ssd에서 에이전트를 공유하려고 했습니까? 작업 없이도 내 나사가 8개의 에이전트에서 크런치하기 시작하는 방식을 고려하면 ssd 리소스가 빠르게 소모되고 있다는 의혹이 있습니다. 그리고 상당히 가벼운 Expert Advisor를 테스트할 때 계산 속도가 하드 드라이브의 속도로 실행되기 시작합니다. 캐시에 몇 테라바이트가 펌핑되는지는 좋은 질문입니다.)
알파벳에 그런 글자가 있지만(ssd에 대해 말하는 것입니다) 특정 테스트는 하지 않았습니다. 그러한 장치가 있는 서버는 도시의 반대편에 있습니다. 그러나 IMHO에는 모든 시스템에 빈번한 디스크 액세스를 원활하게 해주는 디스크 캐시가 있습니다.
나는 두 쌍의 모든 틱에서 간단한 그리더(30초 타이머, 새로운 m1 막대 제어)를 최적화하기로 결정했습니다. 제 i5 코어 4개(PR=160-170)와 i7 코어 8개(PR=170-180)는 약 90(!) 시간의 최적화 시간을 제공했습니다.
그런 다음 i5에 대한 패스가 2배 더 느리게 테스트되는 것으로 나타났습니다(여러 번 썼지만 이전에는 모든 것이 반대였습니다. i5 + winxp64가 i7 + win7x64보다 빠름). 처음에 나는 그것을 메모리로 깎았습니다 - 그것은 i7에 더 있습니다.
그러다 우연히 작업 관리자를 살펴보니 상담원의 우선 순위가 가장 낮습니다(낮음). 그리고 두 기계 모두에서. 그리고 win7에서 우선 순위를 Normal로 올릴 수 있었다면 어떤 이유로 winxp64bit는 그것을 허용하지 않습니다. i7에 대한 새로운 우선 순위로 반나절 동안 테스트 시간이 몇 시간 단축되었습니다(예: :)).
이러한 "브레이크"는 마지막 두 빌드인 것 같습니다(또는 나에게만 보일 수도 있음).
그리고 낮은 우선 순위는 너무 잔인합니다. 하루에 최소 12시간 동안 장비가 에이전트에게 가장 높은 우선 순위를 줄 수 있다면.
일반적으로 리소스 로딩부터 어떻게든 우선순위가 자동으로 바뀌는 줄 알았는데 자체는 바뀌지 않는 것 같아요 :(