クラウド同期エラー - ページ 2

[Slava]

10分と20分では何が違うのですか？変わりません。10分というのは、1回の呼び出しに対して非常に長い時間です。間違ったEAをテストしたい？問題ありません。しかし、あなたの問題を公共のクラウドサーバーに 拡大しないでください。他のユーザーもクラウドサーバーを使いたいのです。ローカルエージェントやリモートエージェントを制限なく使用することができます。

[Alain Verleyen]

cowil:

Stringoさん、こんにちは。

まず、情報をありがとうございます。

しかし、私はMetaQuotesの理由に興味があります。大量の「Every Tick」データを使用し（例えば、2003.1.1 -> 2013.1.1）、最適化されるExpertがある程度複雑であれば、 1回の最適化 反復に10分以上かかることが多いでしょう。MetaQuotes がタイムアウトを 10 分に設定した理由は何ですか？また、クラウドユーザーがこのタイムアウトを増やす方法はあるのでしょうか、それともMetaQuotesによって「ハードワイヤリング」されているのでしょうか？

stringo:
クラウドエージェントのみでエンドレスループが検出されました。いずれかのコール（OnInit, OnDeinit, OnTick, OnTimerなど）が10分以上動作すると

1回の最適化ではなく、関数への シグナル呼び出しです。

[cowil]

angevoyageur:
これは単一の最適化ではなく、関数への信号呼び出しです。

イベント・ハンドラへの1回のコールではなく、1回の最適化反復について話していると思い込んでいました（Stringoはイベント・ハンドラへの1回のコールと明確に述べていたにもかかわらず）。10分以上続くイベントハンドラへの1回の呼び出しは、確かに馬鹿げています。謙虚に謝罪します - 脳が衰えたのでしょう - 脳を休ませる時間です。）

OnTick()の呼び出しが完了するまでに10分以上かかることがあるのは、私のExpertの中で何かおかしなことが起きているに違いありません。調べる時間だ...。

とにかく、皆さんの協力に感謝します。

[Slava]

angevoyageur:
1回の最適化ではなく、関数のシグナルコールですね。

その通りです。1回の呼び出しで、クラウドエージェント1社で10分以上かかることはありえない

[cowil]

こんにちは。

まだ調べているのですが、何も見つけられずにいます。私のエキスパートが私のローカルエージェント上で完璧に最適化される（つまり、私のエージェントの進捗パーセントが一時停止したり、停止したりしないことです。

エラーメッセージの最後にあるPR番号は何を示しているのでしょうか（例：「...expert rejected byMQL5 Cloud Network in 600 sec(PR116)」）。どなたかこの件について教えていただけませんか？

この件に関するあなたの助けに感謝します。

[Alain Verleyen]

cowil:

こんにちは。

まだ調べているのですが、何も見つけられずにいます。私のエキスパートが私のローカルエージェント上で完璧に最適化される（つまり、私のエージェントの進捗パーセントが一時停止したり、停止したりしないことです。

エラーメッセージの最後にあるPR番号は何を示しているのでしょうか（例：「...expert rejected byMQL5 Cloud Network in 600 sec(PR116)」）。どなたかこの件について教えていただけませんか？

よろしくお願いします。

PR は、特別な統一された方法に従って計算されたエージェントのパフォーマンス評価です。エージェントのPRが高いほど、タスクを速く達成し、結果として単位時間あたりのレンタル料金が高くなります。

詳しくはこちらを ご覧ください。

[cowil]

angevoyageur:
詳しくはこちらを ご覧ください。

あ～、確かに説明がつきますね。ありがとうございました。

[cowil]

こんにちは。

週末に何時間もかけて自分のコードを調べた結果、Expertのコードのどこにも無限ループが発生する可能性のある箇所は見つかりませんでした。また、その過程で、もし私のExpertに無限ループの問題があるのなら、ローカルエージェントを使って私のExpertを最適化するときに、それが明らかになるはずだとますます確信するようになりました。前述のとおり、私のローカルエージェントは、私のExpertの最適化中に一時停止することはなく、ましてや10分以上にわたって停止することはありません。

問題が私のExpertに起因していないことを確信した後、私は他の選択肢を検討し始めました。論理的に考えると、エージェント自体に問題があるか（つまりバグ）、エージェントが動作しているマシンに問題があるかのどちらかです。どうやら、このうち2つ目が原因であるようです。

私が調べたところでは、人々はあらゆる種類のコンピュータでクラウドエージェントを動かしているようです。また、これらのクラウドエージェントはすべてWindowsベースであると推測されます。なぜこのようなことを言うかというと、私の個人的な経験では、コンシューマーバージョンのWindowsは、長時間使い続けると不安定になり、深刻な処理要求を受けると速度が落ちたり、固まったりする傾向がある。

私が試みた最適化は、6-7年分の"Every Tick"データで実行される複雑なエキスパートに関するものでした。このタスクを実行するクラウド上のエージェントは、特に Windows マシンを考えると、スペックが十分でないのではと疑っていました。

そこで、OnInit()イベントハンドラに次のようなコードを入れました。

    // Check optimisation agent stats...
    if (MQL5InfoInteger(MQL5_OPTIMIZATION) && TerminalInfoInteger(TERMINAL_MEMORY_PHYSICAL) < 32000)
        return(INIT_AGENT_NOT_SUITABLE);

TERMINAL_MEMORY_PHYSICALを使った理由は、他のメモリオプションであるTERMINAL_MEMORY_TOTALやTERMINAL_MEMORY_AVAILABLEは、ホストプロセッサのユーザーモード仮想アドレス空間の合計（つまり、32ビットプロセッサなら4GB、64ビットプロセッサなら8TB）を提供するだけなので、あまり役に立たないと 思ったからです。8TBのメモリを搭載した64bitマシンが存在するとは思えませんね。）TERMINAL_CPU_CORES も検討したのですが、最終的にはメモリのテストにとどめる ことにしました。

するとどうでしょう、もう問題はありません!私の最適化はすべてうまくいっています。）

[Clock]

cowil:

こんにちは。

週末に何時間もかけて自分のコードを調べた結果、Expertのコードのどこにも無限ループが発生する可能性のある箇所は見つかりませんでした。また、その過程で、もし私のExpertに無限ループの問題があるのなら、ローカルエージェントを使って私のExpertを最適化するときに、それが明らかになるはずだと確信しました。前述のとおり、私のローカルエージェントは、私のExpertの最適化中に一時停止することはなく、ましてや10分以上にわたって停止することはありません。

問題が私のExpertに起因していないことを確信した後、私は他の選択肢を検討し始めました。論理的に考えて、エージェント自体に問題があるか（つまりバグ）、エージェントが動作しているマシンに問題があるかのどちらかしか考えられません。どうやら、このうち2つ目が原因であるように思われます。

私が調べたところでは、人々はあらゆる種類のボックスでクラウドエージェントを実行しているようです。また、これらのクラウドエージェントはすべてWindowsベースであると推測されます。なぜこのようなことを言うかというと、私の個人的な経験では、コンシューマーバージョンのWindowsは、長時間使い続けると不安定になり、深刻な処理要求を受けると速度が落ちたり、固まったりする傾向がある。

私が試みた最適化は、6-7年分の "Every Tick "データで実行される複雑なエキスパートに関するものでした。このタスクを実行するクラウド上のエージェントは、特に Windows マシンを考えると、スペックが十分でないのではと疑っていました。

そこで、OnInit()イベントハンドラに次のようなコードを入れました。

TERMINAL_MEMORY_PHYSICALを使った理由は、他のメモリオプションであるTERMINAL_MEMORY_TOTALやTERMINAL_MEMORY_AVAILABLEは、ホストプロセッサのユーザーモード仮想アドレス空間の合計（つまり、32ビットプロセッサなら4GB、64ビットプロセッサなら8TB）を提供するだけなので、あまり意味が ないんです。8TBのメモリを搭載した64bitマシンが存在するとは思えませんね。）TERMINAL_CPU_CORES も検討したのですが、最終的にはメモリのテストにとどめました。

するとどうでしょう、もう問題はありません!私の最適化はすべてうまくいっています。）

これは素晴らしいアイデアだと思いますし、そのヒントには感謝しています。

しかし、それについて3つのことがあります。

1) 上で述べたように、私も「無限」ループの問題を抱えていますが、このスレッドで「無限ループ」が「1つのイベントが10分以上かかった」場合の最良の推測であると理解したので、私のコードのせいかもしれないと受け止めています。私は非常に複雑な指標を使用しており、（少なくとも私はそう思う）ハンドルが作成されるとき、彼らは彼らの全体の履歴を計算するので、これは（遅いコンピュータ上で）10分以上かかる場合があります。

2) しかし!通常、私のクラウドは10-15分後にクラッシュします。しかし、昨晩は8時間完璧に動きました。コードを全く変えていないのに、一度もクラッシュしませんでした。不思議です。

3) そして、最も重要な ことは、あなたのアプローチに関連することです。メモリに基づいてエージェントを拒否する場合、エージェント（そしてクラウド全体）はクラッシュしない、それはわかります。しかし、より強力なマシンが同じパラメータセットを再度試すとは思えないので、基本的に最適化のデータポイントを失うことになりますね。これは、私たちが支払わなければならない代償と言えるでしょうか？

私が仕事から戻ったら、私のエージェントがまだ使えるかどうか知りたくなりますね...。

[Alain Verleyen]

cowil:
...

32G 以下のメモリを持つエージェントを すべて拒否 した場合、どれだけの エージェントが 利用可能 ですか？