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
最適化とシングルパスでパスの結果が一致しない(サービスデスク - #329165 + EAが同じ場所にある)
最適化とシングルパスの結果が一致しない(サービスデスク - #329165 + EAも同様)。
ビルド619?同じ問題が発生するようになった。しかし、いつもそうとは限りません。結果は同じでも、つまり新しい最適化を行っていないのに、なぜかテスト中に違う結果が出ることもあります。例えば、チャートの最終利益とリストの最終利益が異なる。しばらくすると、すべてが復元されます。build619 以前は気がつかなかった。
ビルドは607のままです(まだ新しいFIBOにアップデートしていません)。多通貨とタイマー(OnTick()が使われていない)の問題かもしれませんが、定かではありません。
ストラテジーテスターの 最新ビルドに何か問題があるようです。突然(「突然」ではなく、619ビルドへのアップデート後)Expert Advisorが実質的にテストしなくなりました(アプリケーション#329165と同じ) - メモリをものすごく消費するようになりました(5年間「全ティック」モードです)。
最後の欄は「VMサイズ」です。ご覧のように、私は4つのコアと4つの「リモート」ローカルエージェントを持っています(常に問題なく動作しています)。
同時に、システムは非常にひどいラグを開始し(そう、4GB RAM + PageFile専用16GB)、最適化速度は無限大になる傾向があります。ご覧のように、CPUの時間、実質的には関与していません。
同時にログにエラーが発生する。
これはどうやらメモリ不足が原因のようです。
停止」を押しても、メモリがすぐに解放されない。5分後にローカルエージェントが消え、さらに2分後にリモートエージェントのメモリが解放されました。
ただ、なぜ1つのエージェントがまだ100Mb以上ハングアップしているのかは不明です(CPU時間が使われていないので、クラウドを取ったとは思えません)。
さて、私は「リモート」ローカルエージェントを無効にしています。何も変わらない(システムの遅れやエラー)。
まあ、私のExpert Advisorにエラーがあるのだと思います。そこで、標準的なExpertMACD、EURUSD、h12の2007.09.01から2012.03.26までのテストを開始します。
И...同じ写真 - ラグ、異常なメモリ使用量(最初の写真とほぼ同じ値)+「エキスパートを初期化できない」。
いずれの場合も、一部のパスは成功する。
ログを添付しました。
非常に興味深いラインです。
私のEAでは、SGDJPYのシンボルがコードに縫い付けられています - なぜUSDSGDの代わりにUSDNOK(ログによるとUSDJPYは正常にアップロードされました)をダウンロードするのですか?
どちらかというと、FIBOGroup-MT5サーバです。
P.S.以前のビルドでは、そのような問題は見られませんでした。
P.追伸:過去5年間の標準ExpertMACDの最適化を全ティックで確認してください。
ストラテジーテスターの 最新ビルドに何か問題があるようです。突然(「突然」ではなく、ビルド619へのアップデート後)EAが実質的にテストを停止しました(アプリケーション#329165と同じ) - メモリが膨大に消費され始めました(5年間「すべてのチック」モード)。
最後の欄は「VMサイズ」です。ご覧のように、私は4つのコアと4つの「リモート」ローカルエージェントを持っています(常に問題なく動作しています)。システムは非常に恐ろしいほど遅くなり始め(そう、4GB RAM + 16GBがPageFileのために配られた)、最適化速度は無限大になる傾向があります。ご覧のように、CPUの時間、実質的には関与していません。
コア数以上のエージェントを実行することは推奨されません。エージェント数が過剰になると、速度が非線形に低下し、リソースの消費量が増大する。特に、メモリが4Gbしかないのに、エージェントが1Gb以上食ってしまうのは、どうかと思います。
リモートエージェントは、端末で作業するのと同じコンピューターにインストールしないでください。
ログにエラーがある。
メモリ不足が原因でしょう。
停止」を押すと、メモリが一度に解放されない。5分後にローカルエージェントが消え、さらに2分後にリモートメモリが解放されます。
はい、メモリ(キャッシュ)は5分程度で解放されます。これは、前回使用したデータのウォームアップに無駄な時間がかからないようにするためです。
最新のビルドでは、キャッシュの処理方法を変更し、再実行の高速化のためにキャッシュを増やしました。
ただ、1つのエージェントが100Mb以上ぶら下がっている理由は不明です(CPU時間は使われていないので、クラウドで使われたとは思えません)。
さて、私は「リモート」ローカルエージェントを無効にしています。何も変わらない(システムの遅れやエラー)。
まあ、私のExpert Advisorにエラーがあるのだと思います。そこで、標準的なExpertMACD、EURUSD、h12を2007.09.01から2012.03.26までテストしているところです。
最新ビルドにアップグレードした後、Expert Advisorを再コンパイルしましたか?
あなたの場合は、常にスワップしているため、メモリ不足でラグが発生していることが問題なのです。アドバイス:不要なリモートエージェントを無効化する。
コア数以上のエージェントを実行することは推奨されません。エージェント数が過剰になると、速度が非線形に低下し、リソースの消費量が増加します。特にメモリが4Gbしかないのに、エージェントが1Gb以上食っているような場合。
端末で主な作業を行うのと同じコンピュータに、リモートエージェントをインストールしないでください。
最新ビルドにアップグレードした後、EAを再コンパイルしましたか?
あなたの場合、問題はスワップし続けることとメモリ不足によるスローダウンにあります。
アドバイス:不要なリモートエージェントは無効にしてください。
無効にして、最適化のためにExpertMACDを実行し、。
そして、1つを除くすべてのエージェント(ローカルエージェントを含む)を無効にしました。
で、どうする?4GBでは1エージェントに足りない?(ただし、Mem Usageは350MB、VM Sizeは1.24GBです)。4GBもない人はどうするんですか?
なぜ調べない?再生手順については、前回の記事をご参照ください。
クラウドの統計を見てください。4エージェントでも8エージェントでも、PRはまだ150~190の領域です(1/2を除いて、明らかにブラウザコアに該当します)無効なリモートエージェント・・・専門家が再コンパイルしています。通常のExpertMACDでも再コンパイルしています。
無効化し、最適化のためにExpertMACDを実行し、。
これで、1つを除くすべてのエージェント(ローカルエージェントを含む)が無効になりました。
で、どうする?4GBでは1エージェントに足りない?(ただし、Mem Usageは350MB、VM Sizeは1.24GBです)。
やっぱり確認したらどうですか?再現手順は前回の記事で
EAのログを見て、エラーを確認するくらいでした。
正しい期間と正しい設定を選択してください。デフォルトの制限を使用すると、間違った設定を大量に発生させる可能性があります。
EAのログを見て、エラーを確認するくらいでした。
適切な期間、適切な設定を選択する。デフォルトの制限を使用すると、間違った設定を大量に発生させる可能性があります。
はい、確かに、問題はデフォルトのパラメータにあることが判明しました。変更したところ、すべて正常にテストできるようになりました。Expert Advisorに戻りました。今のところ、「正常に飛んでいる」ようです。
つまり、以前は1カーネルあたり2エージェントの利用が許されていたのが、今は間違いなく許されていないのです。
結論2.間違っていました、時間がかかってすみません(しかし、サービスデスク - #329165はまだそれを理解していない)
何とかなるさ。
時間がかかっていますね。とりあえず、何が問題なのかがわかりました。
1) コードのリファクタリング中に、変数値の明示的な割り当てを失い、時々(かなりランダムに)オープンポジションのボリュームについてランダムな結果を受け取ることがありました。このエラーを修正した後も、結果は変わらず、テスト結果と最適化が一致しないことがわかりました。いろいろな伐採やタンバリンの仕掛けで、かなり古い問題であることがわかりました。
2)Championship-2011開始前に、テスターが土日に 取引をしていることを報告しました。レナートはそれを確認することを約束した。しかし、その問題は今も残っている。全く偶然に、テスト期間2007.09.01の開始日を選んだのですが、この日は週末でした。つまり、オプティマイザーはこの日に取引を行わないが、テスターは行うのである。正確には、週末のオプティマイザではOrderSendに到達しないが、テスターでは到達する。Expert Advisor のロジックから判断すると、最適化期間が週末に始まる場合、タイマーが最初に鳴ったときに ACCOUNT_EQUITY = 0 になることがわかりました!!!テスターでは、ACCOUNT_EQUITY = ACCOUNT_BALANCE(これは最初の入金で設定したものです)。最適化期間の開始が営業日にあたる場合、オプティマイザーとテスターの動作は同じになります。
つまり、2つのバグがあるということですね。
1) オプティマイザーは、あるはずのない週末に取引を開くことを可能にします(これは私のミスだと言わないでください - 私は私の間違いを修正します、一方テスターのバグは半年以上ぶら下がっています)。
2) タイマーが最初に起動したとき、ピリオドの先頭が出力に当たると ACCOUNT_EQUITY = 0 となるが、テスターでは ACCOUNT_EQUITY = ACCOUNT_BALANCE となる。同じ形にする必要がある(もちろん、最初の誤りを訂正してACCOUNT_EQUITY = ACCOUNT_BALANCEにした方が良い)。
リクエスト#329165のサービスデスクでは、テストのために専門家を添付します。