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のサービスデスクでは、テストのために専門家を添付します。