Python - MT5 번들을 계속 테스트합니다. 또 다른 흥미로운 점, 아마도 버그가 밝혀졌습니다. 본질.
가끔 단말기에 있는 모든 금융상품(약 400만) 중에서 금융상품을 선택하는 작업을 합니다. 외부 응용 프로그램에서 터미널에 연결합니다. 스크립트는 터미널 내에서 실행되지 않습니다.
각 기호에 대해 매일 및 분 막대를 얻은 다음 "판다"를 통해 계산 및 초기 도구 선택을 수행합니다. 그러한 작업을 한 번 수행한 후 터미널 자체가 점차적으로 프로세서를 최대 70-80%까지 로드하기 시작하는 것으로 나타났습니다. 스크립트를 실행한 후 프로세서 부하가 떨어지지 않고(15분 동안 기다리려고 시도했습니다) 터미널 자체가 많이 느려집니다. 터미널을 닫는 것만 으로도 도움이 됩니다. 터미널을 닫지 않고 스크립트를 2회 실행하면 오류 없이 스크립트가 작동하지만 프로세서 로드는 70~80% 수준으로 유지됩니다.
실험을 반복할 수 있도록 스크립트를 최소한으로 단순화하고 견적 요청만 남겼습니다. 문제도 남아 있습니다.
필요한 경우 비디오를 녹화하거나 다른 형식으로 정보를 제공할 준비가 되어 있습니다.
파이썬 코드:
진심으로, 알렉산더
터미널 동작에는 오류가 없습니다. 1000자 이상으로 작업하려면 강력한 하드웨어와 많은 메모리가 필요하다는 것을 이해해야 합니다. 또한 차트의 막대 수를 엄격하게 제한하는 것이 좋습니다(터미널 설정에서).
9세대의 적어도 i7 또는 i9, 바람직하게는 10세대. 메모리 최소 32GB.
"... 견적 요청만 남겼습니다..." - 견적 요청이 정말 간단한 작업이라고 생각한다면 거래를 중단하고 컴퓨터에 절대 가지 마세요.
터미널 동작에는 오류가 없습니다. 1000자 이상으로 작업하려면 강력한 하드웨어와 많은 메모리가 필요하다는 것을 이해해야 합니다. 또한 차트의 막대 수를 엄격하게 제한하는 것이 좋습니다(터미널 설정에서).
9세대의 적어도 i7 또는 i9, 바람직하게는 10세대. 메모리 최소 32GB.
"... 견적 요청만 남겼습니다..." - 견적 요청이 정말 간단한 작업이라고 생각한다면 거래를 중단하고 컴퓨터에 절대 가지 마세요.
아마도 오류가 없을 것입니다. 저는 주장하지 않습니다. 이 동작에 가능한 버그로 주의를 기울였습니다. 이 스레드는 이를 위한 것으로 보입니까, 아니면 제가 착각한 것입니까?
당신의 말에 따르면 나는 철분이 충분합니다. 그런데 메모리 소비는이 작업의 경우 약 3.5GB로 비교적 작습니다. 메모리를 사용하면 모든 것이 정상이며 일반적으로 모든 것이 안정적으로 작동합니다.
이제 설정에서 막대 수가 100만에서 1000으로 특별히 줄었습니다. 확인했습니다. 별 효과가 없었습니다. 터미널에서 수백 개의 탭을 열면 더 많은 효과가 있을 것이라고 생각합니다.
문제는 열거 과정에서 얼마나 많은 CPU 시간이 소모되는지가 아니라 모든 요청이 완료된 후에도 부하가 가라앉지 않는다는 것입니다. 요청된 각 문자에 대해 추가 사용을 위해 별도의 스트림이 메모리에 남아 있다고 가정하면(파괴되지 않음) 모든 것을 설명하고 질문이 없습니다.
그리고 견적요청은 간단한 작업이라고 말씀드렸나요? 나는 완전히 다른 것에 대해 썼습니다. 다른 요소가 영향을 미치지 않고 "견적 요청만"을 남기기 위해 스크립트를 원시적인 것으로 단순화했다는 사실에 대해.
거래에 견적 요청이 쉬운 작업이 아니라는 이해가 필요하다고 생각한다면 전혀 그렇지 않습니다.
거래를 중단하고 컴퓨터에 접근하지 말라는 조언에 대해 우리는 늦었습니다. 첫 번째 항목에서는 최소 25년, 두 번째 항목에서는 최소 10년입니다.
아마도 오류가 없을 것입니다. 저는 주장하지 않습니다. 이 동작에 가능한 버그로 주의를 기울였습니다. 이 스레드는 이를 위한 것으로 보입니까, 아니면 제가 착각한 것입니까?
당신의 말에 따르면, 나는 충분한 양의 철분을 가지고 있습니다. 그런데 메모리 소비는이 작업의 경우 약 3.5GB로 비교적 작습니다. 메모리를 사용하면 모든 것이 정상이며 일반적으로 모든 것이 안정적으로 작동합니다.
이제 설정에서 막대 수가 100만에서 1000으로 특별히 줄었습니다. 확인했습니다. 별 효과가 없었습니다. 터미널에서 수백 개의 탭을 열면 더 많은 효과가 있을 것이라고 생각합니다.
문제는 열거 과정에서 얼마나 많은 CPU 시간이 소모되는지가 아니라 모든 요청이 완료된 후에도 부하가 가라앉지 않는다는 것입니다. 요청된 각 문자에 대해 추가 사용을 위해 별도의 스트림이 메모리에 남아 있다고 가정하면(파괴되지 않음) 모든 것을 설명하고 질문이 없습니다.
그리고 견적요청은 간단한 작업이라고 말씀드렸나요? 나는 완전히 다른 것에 대해 썼습니다. 다른 요소가 영향을 미치지 않고 "견적 요청만"을 남기기 위해 스크립트를 원시적인 것으로 단순화했다는 사실에 대해.
거래에 견적 요청이 쉬운 작업이 아니라는 이해가 필요하다고 생각한다면 전혀 그렇지 않습니다.
거래를 중단하고 컴퓨터에 접근하지 말라는 조언에 대해 우리는 늦었습니다. 첫 번째 항목에서는 최소 25년, 두 번째 항목에서는 최소 10년입니다.
터미널에서 약 100개의 창을 열었습니다(터미널이 더 이상 열리지 않음, 제한). 프로세서의 부하가 최대 8-10%로 약간 증가하고 사용되는 메모리 양이 증가하여 논리적입니다. 그런 다음 터미널을 닫고 다시 열면 부하가 70-80%로 증가하고 약 1분 후에 정상으로 돌아와 8-10%로 돌아갔습니다.
(저는 설정에서 100만 막대를 설정했습니다.)
따라서 위에서 설명한 상황(외부 연결 포함)은 버그이거나 기능입니다. 정답은 개발자만이 알고 있습니다. 이것이 기능이라면 그러한 작업 후에 터미널을 닫았다가 다시 여는 것이 꽤 해결책입니다. 수술은 빈번하지 않습니다.
1.터미널: "오픈 포지션 및 주문에 대해 사전에 차트 데이터 로드" 설정이 추가되었습니다.
트래픽을 절약하기 위해 거래 플랫폼은 차트를 열거나 테스트가 시작될 때와 같이 실제 요청 순간에만 상품의 가격 기록을 다운로드합니다. 그러나 적극적으로 사용되는 도구의 경우 이것이 항상 편리한 것은 아닙니다. 새 옵션을 활성화하면 플랫폼이 시작될 때마다 오픈 포지션 또는 보류 중인 주문이 있는 상품 차트가 백그라운드에서 업데이트됩니다. 따라서 차트를 열 때 추가 데이터 로드를 기다릴 필요가 없으며 즉시 분석에 사용할 수 있습니다.
1.터미널: "오픈 포지션 및 주문에 대해 사전에 차트 데이터 로드" 설정이 추가되었습니다.
트래픽을 절약하기 위해 거래 플랫폼은 차트를 열거나 테스트가 시작될 때와 같이 실제 요청 순간에만 상품의 가격 기록을 다운로드합니다. 그러나 적극적으로 사용되는 도구의 경우 이것이 항상 편리한 것은 아닙니다. 새 옵션을 활성화하면 플랫폼이 시작될 때마다 오픈 포지션 또는 보류 중인 주문이 있는 상품 차트가 백그라운드에서 업데이트됩니다. 따라서 차트를 열 때 추가 데이터 로드를 기다릴 필요가 없으며 즉시 분석에 사용할 수 있습니다.
이 시점에서 주의 사항 이 있습니다. " 오픈 포지션 또는 보류 중인 주문이 있는 상품 차트 ". 게다가, 나는 이미 모든 차트를 로컬 데이터베이스에 로드했고 스크립트가 실행될 때 트래픽이 부족합니다.
이것이 완전히 정확하지는 않지만 데이터에 대해 최소 100만 건의 요청을 하는 SQL 서버와 유추하면 예, 현재 프로세서에 최대 부하가 있지만 결국에는 작업의 프로세서에 대한 부하가 확실히 감소합니다.
물론 메타트레이더는 여전히 sql 서버가 아니고 다른 플랫폼이지만 어떤 이유에서인지 메타트레이더에 견적을 요청하고 연결을 닫으면 모든 것이 정상으로 돌아가야 하는 것 같습니다. 메타트레이더의 개발자들이 설명해주기를 바랍니다.
안녕하세요!
개발자에게 호소합니다.
Python - MT5 번들을 계속 테스트합니다. 또 다른 흥미로운 점, 아마도 버그가 밝혀졌습니다.
본질.
가끔 단말기에 있는 모든 금융상품(약 400만) 중에서 금융상품을 선택하는 작업을 합니다.
외부 응용 프로그램에서 터미널에 연결합니다. 스크립트는 터미널 내에서 실행되지 않습니다.
각 기호에 대해 매일 및 분 막대를 얻은 다음 "판다"를 통해 계산 및 초기 도구 선택을 수행합니다.
그러한 작업을 한 번 수행한 후 터미널 자체가 점차적으로 프로세서를 최대 70-80%까지 로드하기 시작하는 것으로 나타났습니다.
스크립트를 실행한 후 프로세서 부하가 떨어지지 않고(15분 동안 기다리려고 시도했습니다) 터미널 자체가 많이 느려집니다. 터미널을 닫는 것만 으로도 도움이 됩니다.
터미널을 닫지 않고 스크립트를 2회 실행하면 오류 없이 스크립트가 작동하지만 프로세서 로드는 70~80% 수준으로 유지됩니다.
실험을 반복할 수 있도록 스크립트를 최소한으로 단순화하고 견적 요청만 남겼습니다. 문제도 남아 있습니다.
필요한 경우 비디오를 녹화하거나 다른 형식으로 정보를 제공할 준비가 되어 있습니다.
파이썬 코드:
진심으로, 알렉산더
터미널 동작에는 오류가 없습니다. 1000자 이상으로 작업하려면 강력한 하드웨어와 많은 메모리가 필요하다는 것을 이해해야 합니다. 또한 차트의 막대 수를 엄격하게 제한하는 것이 좋습니다(터미널 설정에서).
9세대의 적어도 i7 또는 i9, 바람직하게는 10세대. 메모리 최소 32GB.
"... 견적 요청만 남겼습니다..." - 견적 요청이 정말 간단한 작업이라고 생각한다면 거래를 중단하고 컴퓨터에 절대 가지 마세요.
터미널 동작에는 오류가 없습니다. 1000자 이상으로 작업하려면 강력한 하드웨어와 많은 메모리가 필요하다는 것을 이해해야 합니다. 또한 차트의 막대 수를 엄격하게 제한하는 것이 좋습니다(터미널 설정에서).
9세대의 적어도 i7 또는 i9, 바람직하게는 10세대. 메모리 최소 32GB.
"... 견적 요청만 남겼습니다..." - 견적 요청이 정말 간단한 작업이라고 생각한다면 거래를 중단하고 컴퓨터에 절대 가지 마세요.
아마도 오류가 없을 것입니다. 저는 주장하지 않습니다. 이 동작에 가능한 버그로 주의를 기울였습니다. 이 스레드는 이를 위한 것으로 보입니까, 아니면 제가 착각한 것입니까?
당신의 말에 따르면 나는 철분이 충분합니다. 그런데 메모리 소비는이 작업의 경우 약 3.5GB로 비교적 작습니다. 메모리를 사용하면 모든 것이 정상이며 일반적으로 모든 것이 안정적으로 작동합니다.
이제 설정에서 막대 수가 100만에서 1000으로 특별히 줄었습니다. 확인했습니다. 별 효과가 없었습니다. 터미널에서 수백 개의 탭을 열면 더 많은 효과가 있을 것이라고 생각합니다.
문제는 열거 과정에서 얼마나 많은 CPU 시간이 소모되는지가 아니라 모든 요청이 완료된 후에도 부하가 가라앉지 않는다는 것입니다.
요청된 각 문자에 대해 추가 사용을 위해 별도의 스트림이 메모리에 남아 있다고 가정하면(파괴되지 않음) 모든 것을 설명하고 질문이 없습니다.
그리고 견적요청은 간단한 작업이라고 말씀드렸나요? 나는 완전히 다른 것에 대해 썼습니다. 다른 요소가 영향을 미치지 않고 "견적 요청만"을 남기기 위해 스크립트를 원시적인 것으로 단순화했다는 사실에 대해.
거래에 견적 요청이 쉬운 작업이 아니라는 이해가 필요하다고 생각한다면 전혀 그렇지 않습니다.
거래를 중단하고 컴퓨터에 접근하지 말라는 조언에 대해 우리는 늦었습니다. 첫 번째 항목에서는 최소 25년, 두 번째 항목에서는 최소 10년입니다.
개발자가 필요하다고 판단하는 경우 제공된 정보를 고려합니다. 그렇지 않다면 아니요.
진심으로, 알렉산더.
아마도 오류가 없을 것입니다. 저는 주장하지 않습니다. 이 동작에 가능한 버그로 주의를 기울였습니다. 이 스레드는 이를 위한 것으로 보입니까, 아니면 제가 착각한 것입니까?
당신의 말에 따르면, 나는 충분한 양의 철분을 가지고 있습니다. 그런데 메모리 소비는이 작업의 경우 약 3.5GB로 비교적 작습니다. 메모리를 사용하면 모든 것이 정상이며 일반적으로 모든 것이 안정적으로 작동합니다.
이제 설정에서 막대 수가 100만에서 1000으로 특별히 줄었습니다. 확인했습니다. 별 효과가 없었습니다. 터미널에서 수백 개의 탭을 열면 더 많은 효과가 있을 것이라고 생각합니다.
문제는 열거 과정에서 얼마나 많은 CPU 시간이 소모되는지가 아니라 모든 요청이 완료된 후에도 부하가 가라앉지 않는다는 것입니다.
요청된 각 문자에 대해 추가 사용을 위해 별도의 스트림이 메모리에 남아 있다고 가정하면(파괴되지 않음) 모든 것을 설명하고 질문이 없습니다.
그리고 견적요청은 간단한 작업이라고 말씀드렸나요? 나는 완전히 다른 것에 대해 썼습니다. 다른 요소가 영향을 미치지 않고 "견적 요청만"을 남기기 위해 스크립트를 원시적인 것으로 단순화했다는 사실에 대해.
거래에 견적 요청이 쉬운 작업이 아니라는 이해가 필요하다고 생각한다면 전혀 그렇지 않습니다.
거래를 중단하고 컴퓨터에 접근하지 말라는 조언에 대해 우리는 늦었습니다. 첫 번째 항목에서는 최소 25년, 두 번째 항목에서는 최소 10년입니다.
개발자가 필요하다고 판단하는 경우 제공된 정보를 고려합니다. 그렇지 않다면 아니요.
진심으로, 알렉산더.
막대 수를 줄인 후 터미널을 다시 시작하셨습니까?
막대 수를 줄인 후 터미널을 다시 시작하셨습니까?
막대 수를 줄인 후 터미널을 다시 시작하셨습니까?
틀림없이.
실험을 진행했습니다.
터미널에서 약 100개의 창을 열었습니다(터미널이 더 이상 열리지 않음, 제한).
프로세서의 부하가 최대 8-10%로 약간 증가하고 사용되는 메모리 양이 증가하여 논리적입니다.
그런 다음 터미널을 닫고 다시 열면 부하가 70-80%로 증가하고 약 1분 후에 정상으로 돌아와 8-10%로 돌아갔습니다.
(저는 설정에서 100만 막대를 설정했습니다.)
따라서 위에서 설명한 상황(외부 연결 포함)은 버그이거나 기능입니다.
정답은 개발자만이 알고 있습니다.
이것이 기능이라면 그러한 작업 후에 터미널을 닫았다가 다시 여는 것이 꽤 해결책입니다. 수술은 빈번하지 않습니다.
이것이 기능이라면 그러한 작업 후에 터미널을 닫았다가 다시 여는 것이 꽤 해결책입니다. 수술은 빈번하지 않습니다.
예, 이론적으로 터미널은 최근에 요청한 시계열의 캐시를 유지 관리합니다.
그러나 그는 그것을 영원히 해서는 안 됩니다. 3~5분의 타임아웃이 있었던 것 같습니다.
빌드 2650부터 다음을 참고하세요.
트래픽을 절약하기 위해 거래 플랫폼은 차트를 열거나 테스트가 시작될 때와 같이 실제 요청 순간에만 상품의 가격 기록을 다운로드합니다. 그러나 적극적으로 사용되는 도구의 경우 이것이 항상 편리한 것은 아닙니다. 새 옵션을 활성화하면 플랫폼이 시작될 때마다 오픈 포지션 또는 보류 중인 주문이 있는 상품 차트가 백그라운드에서 업데이트됩니다. 따라서 차트를 열 때 추가 데이터 로드를 기다릴 필요가 없으며 즉시 분석에 사용할 수 있습니다.
예, 이론적으로 터미널은 최근에 요청한 시계열의 캐시를 유지 관리합니다.
그러나 그는 그것을 영원히 해서는 안 됩니다. 3~5분의 타임아웃이 있었던 것 같습니다.
지금까지의 질문은 파이썬의 외부 연결에 관한 것입니다.
빌드 2650부터 다음을 참고하세요.
트래픽을 절약하기 위해 거래 플랫폼은 차트를 열거나 테스트가 시작될 때와 같이 실제 요청 순간에만 상품의 가격 기록을 다운로드합니다. 그러나 적극적으로 사용되는 도구의 경우 이것이 항상 편리한 것은 아닙니다. 새 옵션을 활성화하면 플랫폼이 시작될 때마다 오픈 포지션 또는 보류 중인 주문이 있는 상품 차트가 백그라운드에서 업데이트됩니다. 따라서 차트를 열 때 추가 데이터 로드를 기다릴 필요가 없으며 즉시 분석에 사용할 수 있습니다.
이 시점에서 주의 사항 이 있습니다. " 오픈 포지션 또는 보류 중인 주문이 있는 상품 차트 ".
게다가, 나는 이미 모든 차트를 로컬 데이터베이스에 로드했고 스크립트가 실행될 때 트래픽이 부족합니다.
이것이 완전히 정확하지는 않지만 데이터에 대해 최소 100만 건의 요청을 하는 SQL 서버와 유추하면 예, 현재 프로세서에 최대 부하가 있지만 결국에는 작업의 프로세서에 대한 부하가 확실히 감소합니다.
물론 메타트레이더는 여전히 sql 서버가 아니고 다른 플랫폼이지만 어떤 이유에서인지 메타트레이더에 견적을 요청하고 연결을 닫으면 모든 것이 정상으로 돌아가야 하는 것 같습니다. 메타트레이더의 개발자들이 설명해주기를 바랍니다.
테스터의 롤오버 버그는 무엇입니까? 첨부된 예시는 스크린샷입니다. 오픈 포지션 매도, 매수를 통해 롤오버 시 닫은 다음 매도를 통해 재개장하지만 거래량은 0입니다.
결과적으로 포지션이 다시 열리지 않고 사라집니다. 화면에 강조 표시됩니다. 나는 이미 사진 없이 이것에 대해 썼습니다. 이 버그는 무엇입니까? 이 때문에 테스트할 방법이 없습니다.
개발자가 이 결함에 응답할지 궁금합니다. 결국 롤오버는 내 프로그램이 아니라 테스터에 의해 생성됩니다.