エラー、バグ、質問 - ページ 2904 1...289728982899290029012902290329042905290629072908290929102911...3185 新しいコメント Vladimir Karputov 2020.11.13 17:34 #29031 suncrypto:こんにちは。開発者に向けてのメッセージPython - MT5 のテストを続けています。もうひとつ、もしかしたらバグかもしれませんが、面白いことがあります。 エッセンスです。今、私は、ターミナルにあるすべての金融商品（約4000k）の中から、金融商品を選び始めています。 外部アプリケーションからターミナルに接続し、ターミナル内でスクリプトを起動しない。各シンボルの日足と分足のバーを取得し、「pandas」を使って計算と商品の初期選択を行います。 このような操作を1回行うと、端末が徐々にプロセッサに70～80%まで負荷をかけるようになることに気づきました。 スクリプト作業後、プロセッサの負荷は減らないが（15分ほど待ってみた）、端末が非常に遅い。端末を閉じることでしか 助けられない。 ターミナルを閉じずにスクリプトを2回実行すると、スクリプトはエラーなしで動作しますが、CPU負荷は70～80%のままです。実験を繰り返して見積もりだけを依頼したままにしておけるように、スクリプトを必要最小限に簡略化しました。それでも問題は解決しない。必要であれば、ビデオ撮影や他の形での情報提供の準備もする。コードはpyhtonです。敬称略、アレクサンダー 端末の動作にエラーはありません。1000文字以上の文字を扱うには、強力なアイロンと大量のメモリが必要であることを理解する必要があります。また、チャートのバーの数を厳しく制限することをお勧めします（端末の設定）。 第九世代以上の第十世代のi7またはi9以上。メモリは32GB以上。 "...見積もり依頼を残すのみ..."- もし、本当に見積もり依頼が非常に簡単な操作だと思うなら、取引をやめて、コンピュータに近づかないことです。 suncrypto 2020.11.13 18:48 #29032 Vladimir Karputov:端末の動作に間違いはない。1000以上のシンボルを扱うには、強力なハードウェアと大量のメモリが必要であることを理解する必要があります。また、チャート上のバー数を厳しく制限することをお勧めします（端末設定）。第九世代以上の第十世代のi7またはi9以上。メモリは32GB以上。"...見積もり依頼を残すのみ..."- もし、本当に見積もり依頼がとても簡単な操作だと思っているのなら、取引をやめて、コンピュータに近づかないでください。 もしかしたらエラーがないのかもしれない、あるとは言っていない、この挙動をバグの可能性として指摘しただけだ、このスレッドはそのために予約されているようだが、私の勘違いだろうか？ あなたの話からすると、私のハードウェアは十分すぎるほどです。ちなみにメモリ消費量は、この操作では3.5GB程度と比較的少ないです。メモリも問題なく、全般的にすべてが安定して動作しています。 さて、設定のバーの本 数を1mlnから1kにわざと減らしてみました。何の変化もなかった。ターミナルで数百のタブを開けば、もっと効果があると思います。 列挙処理でどれだけCPU時間を食うかではなく、全てのクエリーが終わった後、負荷が下がらないかが問題なのです。 もし、要求された文字ごとに別のスレッドがメモリに残され（破壊されない）、さらに使用されると仮定すれば、これですべてが説明でき、疑問は生じない。 また、見積もり依頼が簡単な操作だと言いましたか？そういうことを書いたのでは全然ないんです。他の要素が影響しないように、私がスクリプトをプリミティブに簡略化し、「見積もり依頼のみ」を残すことについて。 もし本当に、取引には見積もり依頼が厄介な操作であることを理解する必要があると思っているなら、それは全く違うのです。 トレードをやめてパソコンから離れろというアドバイスについては、遅すぎましたね。1点目は25年、2点目は10年遅れていますね。 開発者が必要と判断すれば、その情報を考慮することになります。そうでないなら、そうしない。 Alexanderさん、ありがとうございます。 Vladimir Karputov 2020.11.13 18:51 #29033 suncrypto: もしかしたら、エラーはないのかもしれません、私は主張しません、この動作をバグの可能性として指摘しました、このスレッドはそのために作られたようです、それとも私が間違っているのでしょうか？お話を伺っていると、ハードは十分すぎるほど持っています。ちなみに、この操作ではメモリ消費量は約3.5GBと比較的少ないです。メモリも問題なく、全般的にすべてが安定して動作しています。さて、設定のバーの本 数を1mlnから1kにわざと減らしてみました。何の変化もなかった。ターミナルで数百のタブを開けば、もっと効果があると思います。列挙処理でどれだけCPU時間を食うかではなく、全てのクエリーが終わった後、負荷が下がらないかが問題なのです。 もし、要求されたシンボルごとに、さらに使用するために別のスレッドがメモリに残される（破壊されない）と仮定すれば、これですべてが説明でき、疑問は生じません。また、見積もり依頼が簡単な操作だと言いましたか？そういうことを書いたのでは全然ないんです。他の要素が影響しないように、私がスクリプトをプリミティブに簡略化し、「見積もり依頼のみ」を残すことについて。もし、あなたが本当に、取引には見積もり依頼が厄介な操作であることを理解する必要があると思っているなら、それは全く違うのです。トレードをやめてパソコンから離れろというアドバイスについては、遅すぎましたね。1点目は25年、2点目は10年遅かったですね。開発者が必要と判断すれば、その情報を考慮することになります。そうでないなら、そうしない。Alexanderさん、ありがとうございます。 バーの数を減らした後、端末を再起動しましたか？ suncrypto 2020.11.13 18:59 #29034 Vladimir Karputov:バーの本数を減らした後、端末を再起動しましたか？ もちろん、そうです。 suncrypto 2020.11.13 19:32 #29035 Vladimir Karputov:バーの本数を減らした後、端末を再起動しましたか？ Suncrypto: もちろんです。 実験をしてみました。 ターミナルで100個くらいウィンドウを開きました（これ以上は開きません、限界があります）。 プロセッサーの負荷は8〜10％とわずかに増加し、使用メモリサイズも増加しましたが、これは論理的なものです。 その後、端末を閉じて 再び開くと、負荷が70～80%まで上がり、1分ほどで正常化し8～10%に戻りました。 (設定で100万小節に設定）。 したがって、上記のような状況（外部接続あり）は、よく言われるように、バグか機能かのどちらかです。 正解は開発者だけが知っている。 バグであれば、そのような操作の後、端末を一度閉じてから再度開いてください。操作の頻度は高くありません。 Andrey Khatimlianskii 2020.11.13 22:33 #29036 suncrypto: もし、このような機能があるのであれば、そのような操作の後に端末を閉じて、再度開くと、かなりの解決策になります。操作の頻度は高くありません。 はい、端末は最近要求された時系列のキャッシュを保持することになっています。 でも、いつまでもやる必要はなく、3分か5分のタイムアウトがあったと思います。 Vladimir Karputov 2020.11.14 04:10 #29037 suncrypto: ビルド2650以降ではご注意ください。 1.Terminal: 「未決済のポジションと注文にあらかじめチャートデータを読み込む」設定を追加。 トラフィックを節約するために、取引プラットフォームは、チャートを開くときやテストを実行する ときなど、実際に要求された瞬間にのみ、商品の価格履歴をダウンロードします。しかし、アクティブに使用される機器では、必ずしも便利ではないかもしれません。このオプションを有効にすると、オープンポジションまたは未決済注文を持つ商品のチャートは、プラットフォームを起動するたびにバックグラウンドで更新されます。このため、チャートを開くと、データの再ロードを待つことなく、すぐに分析に利用 できる。 Новая версия платформы MetaTrader 5 build 2650: Фоновая загрузка графиков и улучшения в профилировщике MQL5-кода 2020.10.08www.mql5.com В пятницу 9 октября 2020 года будет выпущена обновленная версия платформы MetaTrader 5... suncrypto 2020.11.14 05:04 #29038 Andrey Khatimlianskii:はい、端末は最近要求された時系列のキャッシュを保持することになっています。しかし、いつまでもこんなことをしていてはいけない、3分か5分のタイムアウトがあったと思う。 はい、端末自体はすべて正常です。不要な」ウィンドウを閉じることで、CPU負荷とメモリ消費量の両方を低減することができます。 今までの質問は、pythonからの外部接続についてだけです。 suncrypto 2020.11.14 05:29 #29039 Vladimir Karputov:ビルド2650以降ではご注意ください。 1.Terminal: 「未決済のポジションと注文にあらかじめチャートデータを読み込む」設定を追加。 トラフィックを節約するために、取引プラットフォームは、チャートを開くときやテストを実行する ときなど、実際に要求された瞬間にのみ、商品の価格履歴をダウンロードします。しかし、アクティブに使用される機器では、必ずしも便利ではないかもしれません。このオプションを有効にすると、オープンポジションまたは未決済注文を持つ商品のチャートは、プラットフォームを起動するたびにバックグラウンドで更新されます。このため、チャートを開いたときに、データの再読み込みを待つ必要がなく、すぐに分析に利用 できます。 この点については、「オープンポジションまたは未決済の注文を持つ商品のチャート」という免責事項があります。 しかも、スクリプトの実行中にすべてのチャートがすでにローカル・データベースにアップロードされているので、トラフィックは最小限です。 ちょっと違うかもしれませんが、SQL Serverに対して少なくとも100万回以上のデータ要求があった場合、確かにその瞬間はプロセッサの負荷がピークに達しますが、処理が完了すれば確実に負荷は軽減されるのです。 もちろん、メタトレーダーはSQLサーバーではなく、別のプラットフォームですが、なぜか、メタトレーダーへの見積もり依頼を実行し、それとの接続を閉じると、すべてが正常に戻るはずのような気がします。メタトレーダー開発者の方々の解説を期待します。 mox_dimass 2020.11.14 09:05 #29040 mox_dimass:テスターでのロールオーバーの不具合は？例として、 売りのオープンポジションが、買いのロールオーバーによって閉じられ、その後、売りによって再開されましたが、出来高はゼロでした。その結果、ポジションは再オープンされず、消滅してしまいます。スクリーンショットでハイライトされています。すでに記事にしていますが、写真なしです。どんなバグなんだ？ これではテストもできない。 この不具合に開発者は対応するのだろうか。結局、ロールオーバーはテスターが発生させるのであって、私のソフトではない。 1...289728982899290029012902290329042905290629072908290929102911...3185 新しいコメント 取引の機会を逃しています。 無料取引アプリ 8千を超えるシグナルをコピー 金融ニュースで金融マーケットを探索 新規登録 ログイン スペースを含まないラテン文字 このメールにパスワードが送信されます エラーが発生しました Googleでログイン WebサイトポリシーおよびMQL5.COM利用規約に同意します。 新規登録 MQL5.com WebサイトへのログインにCookieの使用を許可します。 ログインするには、ブラウザで必要な設定を有効にしてください。 ログイン/パスワードをお忘れですか？ Googleでログイン
こんにちは。
開発者に向けてのメッセージ
Python - MT5 のテストを続けています。もうひとつ、もしかしたらバグかもしれませんが、面白いことがあります。
エッセンスです。
今、私は、ターミナルにあるすべての金融商品（約4000k）の中から、金融商品を選び始めています。
外部アプリケーションからターミナルに接続し、ターミナル内でスクリプトを起動しない。
各シンボルの日足と分足のバーを取得し、「pandas」を使って計算と商品の初期選択を行います。
このような操作を1回行うと、端末が徐々にプロセッサに70～80%まで負荷をかけるようになることに気づきました。
スクリプト作業後、プロセッサの負荷は減らないが（15分ほど待ってみた）、端末が非常に遅い。端末を閉じることでしか 助けられない。
ターミナルを閉じずにスクリプトを2回実行すると、スクリプトはエラーなしで動作しますが、CPU負荷は70～80%のままです。
実験を繰り返して見積もりだけを依頼したままにしておけるように、スクリプトを必要最小限に簡略化しました。それでも問題は解決しない。
必要であれば、ビデオ撮影や他の形での情報提供の準備もする。
コードはpyhtonです。
敬称略、アレクサンダー
端末の動作にエラーはありません。1000文字以上の文字を扱うには、強力なアイロンと大量のメモリが必要であることを理解する必要があります。また、チャートのバーの数を厳しく制限することをお勧めします（端末の設定）。
第九世代以上の第十世代のi7またはi9以上。メモリは32GB以上。
"...見積もり依頼を残すのみ..."- もし、本当に見積もり依頼が非常に簡単な操作だと思うなら、取引をやめて、コンピュータに近づかないことです。
端末の動作に間違いはない。1000以上のシンボルを扱うには、強力なハードウェアと大量のメモリが必要であることを理解する必要があります。また、チャート上のバー数を厳しく制限することをお勧めします（端末設定）。
第九世代以上の第十世代のi7またはi9以上。メモリは32GB以上。
"...見積もり依頼を残すのみ..."- もし、本当に見積もり依頼がとても簡単な操作だと思っているのなら、取引をやめて、コンピュータに近づかないでください。
もしかしたらエラーがないのかもしれない、あるとは言っていない、この挙動をバグの可能性として指摘しただけだ、このスレッドはそのために予約されているようだが、私の勘違いだろうか？
あなたの話からすると、私のハードウェアは十分すぎるほどです。ちなみにメモリ消費量は、この操作では3.5GB程度と比較的少ないです。メモリも問題なく、全般的にすべてが安定して動作しています。
さて、設定のバーの本 数を1mlnから1kにわざと減らしてみました。何の変化もなかった。ターミナルで数百のタブを開けば、もっと効果があると思います。
列挙処理でどれだけCPU時間を食うかではなく、全てのクエリーが終わった後、負荷が下がらないかが問題なのです。
もし、要求された文字ごとに別のスレッドがメモリに残され（破壊されない）、さらに使用されると仮定すれば、これですべてが説明でき、疑問は生じない。
また、見積もり依頼が簡単な操作だと言いましたか？そういうことを書いたのでは全然ないんです。他の要素が影響しないように、私がスクリプトをプリミティブに簡略化し、「見積もり依頼のみ」を残すことについて。
もし本当に、取引には見積もり依頼が厄介な操作であることを理解する必要があると思っているなら、それは全く違うのです。
トレードをやめてパソコンから離れろというアドバイスについては、遅すぎましたね。1点目は25年、2点目は10年遅れていますね。
開発者が必要と判断すれば、その情報を考慮することになります。そうでないなら、そうしない。
Alexanderさん、ありがとうございます。
もしかしたら、エラーはないのかもしれません、私は主張しません、この動作をバグの可能性として指摘しました、このスレッドはそのために作られたようです、それとも私が間違っているのでしょうか？
お話を伺っていると、ハードは十分すぎるほど持っています。ちなみに、この操作ではメモリ消費量は約3.5GBと比較的少ないです。メモリも問題なく、全般的にすべてが安定して動作しています。
さて、設定のバーの本 数を1mlnから1kにわざと減らしてみました。何の変化もなかった。ターミナルで数百のタブを開けば、もっと効果があると思います。
列挙処理でどれだけCPU時間を食うかではなく、全てのクエリーが終わった後、負荷が下がらないかが問題なのです。
もし、要求されたシンボルごとに、さらに使用するために別のスレッドがメモリに残される（破壊されない）と仮定すれば、これですべてが説明でき、疑問は生じません。
また、見積もり依頼が簡単な操作だと言いましたか？そういうことを書いたのでは全然ないんです。他の要素が影響しないように、私がスクリプトをプリミティブに簡略化し、「見積もり依頼のみ」を残すことについて。
もし、あなたが本当に、取引には見積もり依頼が厄介な操作であることを理解する必要があると思っているなら、それは全く違うのです。
トレードをやめてパソコンから離れろというアドバイスについては、遅すぎましたね。1点目は25年、2点目は10年遅かったですね。
開発者が必要と判断すれば、その情報を考慮することになります。そうでないなら、そうしない。
Alexanderさん、ありがとうございます。
バーの数を減らした後、端末を再起動しましたか？
バーの本数を減らした後、端末を再起動しましたか？
バーの本数を減らした後、端末を再起動しましたか？
もちろんです。
実験をしてみました。
ターミナルで100個くらいウィンドウを開きました（これ以上は開きません、限界があります）。
プロセッサーの負荷は8〜10％とわずかに増加し、使用メモリサイズも増加しましたが、これは論理的なものです。
その後、端末を閉じて 再び開くと、負荷が70～80%まで上がり、1分ほどで正常化し8～10%に戻りました。
(設定で100万小節に設定）。
したがって、上記のような状況（外部接続あり）は、よく言われるように、バグか機能かのどちらかです。
正解は開発者だけが知っている。
バグであれば、そのような操作の後、端末を一度閉じてから再度開いてください。操作の頻度は高くありません。
もし、このような機能があるのであれば、そのような操作の後に端末を閉じて、再度開くと、かなりの解決策になります。操作の頻度は高くありません。
はい、端末は最近要求された時系列のキャッシュを保持することになっています。
でも、いつまでもやる必要はなく、3分か5分のタイムアウトがあったと思います。
ビルド2650以降ではご注意ください。
トラフィックを節約するために、取引プラットフォームは、チャートを開くときやテストを実行する ときなど、実際に要求された瞬間にのみ、商品の価格履歴をダウンロードします。しかし、アクティブに使用される機器では、必ずしも便利ではないかもしれません。このオプションを有効にすると、オープンポジションまたは未決済注文を持つ商品のチャートは、プラットフォームを起動するたびにバックグラウンドで更新されます。このため、チャートを開くと、データの再ロードを待つことなく、すぐに分析に利用 できる。
はい、端末は最近要求された時系列のキャッシュを保持することになっています。
しかし、いつまでもこんなことをしていてはいけない、3分か5分のタイムアウトがあったと思う。
今までの質問は、pythonからの外部接続についてだけです。
ビルド2650以降ではご注意ください。
トラフィックを節約するために、取引プラットフォームは、チャートを開くときやテストを実行する ときなど、実際に要求された瞬間にのみ、商品の価格履歴をダウンロードします。しかし、アクティブに使用される機器では、必ずしも便利ではないかもしれません。このオプションを有効にすると、オープンポジションまたは未決済注文を持つ商品のチャートは、プラットフォームを起動するたびにバックグラウンドで更新されます。このため、チャートを開いたときに、データの再読み込みを待つ必要がなく、すぐに分析に利用 できます。
この点については、「オープンポジションまたは未決済の注文を持つ商品のチャート」という免責事項があります。
しかも、スクリプトの実行中にすべてのチャートがすでにローカル・データベースにアップロードされているので、トラフィックは最小限です。
ちょっと違うかもしれませんが、SQL Serverに対して少なくとも100万回以上のデータ要求があった場合、確かにその瞬間はプロセッサの負荷がピークに達しますが、処理が完了すれば確実に負荷は軽減されるのです。
もちろん、メタトレーダーはSQLサーバーではなく、別のプラットフォームですが、なぜか、メタトレーダーへの見積もり依頼を実行し、それとの接続を閉じると、すべてが正常に戻るはずのような気がします。メタトレーダー開発者の方々の解説を期待します。
テスターでのロールオーバーの不具合は？例として、 売りのオープンポジションが、買いのロールオーバーによって閉じられ、その後、売りによって再開されましたが、出来高はゼロでした。
その結果、ポジションは再オープンされず、消滅してしまいます。スクリーンショットでハイライトされています。すでに記事にしていますが、写真なしです。どんなバグなんだ？ これではテストもできない。
この不具合に開発者は対応するのだろうか。結局、ロールオーバーはテスターが発生させるのであって、私のソフトではない。