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？同样的问题也开始出现了。但并不总是如此。有时，结果甚至是一样的，即我没有进行任何新的优化，但在测试时，由于某种原因，我得到了不同的结果。例如，图表中的最终利润与列表中的不同。一段时间后，一切都恢复了。在建立619 之前，我从未注意到这一点。
建设仍然是607（还没有更新到新的FIBO）。也许问题出在多货币和定时器上（OnTick()没有被使用），但不确定。
策略测试器 的最新版本出了问题。突然（不是 "突然"，而是在更新到619版本之后），专家顾问实际上已经停止了测试（与应用程序#329165相同）--它开始大量消耗内存（5年来的 "所有刻度 "模式）。
最后一栏是 "虚拟机大小"。正如你所看到的，我有4个核心+4个 "远程 "本地代理（一直运行良好）。
同时，系统开始严重滞后（是的，4GB内存+16GB专用于PageFile），优化速度趋向于无限大。正如你所看到的，CPU的时间，实际上是没有参与。
同时，日志中也有错误。
这显然是由于缺乏记忆。
我按下 "停止 "键 - 记忆没有立即释放。在5分钟内，本地代理消失了，在另外两分钟内，远程代理的内存被释放了。
只是不清楚为什么一个代理仍然有超过100Mb的挂起（我不相信它花了云 - 因为CPU时间没有被使用）。
嗯，我禁用了 "远程 "本地代理。没有任何变化（系统滞后和错误）。
嗯，我认为，错误在我的专家顾问。因此我开始测试一个标准的ExpertMACD，EURUSD，h12从2007.09.01到2012.03.26。
И...同样的图片 - 滞后，疯狂的内存使用（几乎与第一张图片中的数值相同）+"无法初始化专家"。
在这两种情况下，一些通行证还是成功了。
附上日志。
非常有趣的线条。
在我的EA中，代码中缝合了一个SGDJPY符号，为什么要下载USDNOK（根据日志，USDJPY已成功上传），而不是USDSGD？
如果有的话，该服务器是FIBOGroup-MT5服务器。
P.S.我在以前的版本中没有看到这样的问题。
P.P.S.请检查过去5年的标准ExpertMACD的优化情况，对所有的ticks。
策略测试器 的最新版本出了问题。突然（不是 "突然"，而是在更新到Build 619之后），EA几乎停止了测试（与应用程序#329165相同）--内存开始大量消耗（"所有刻度 "模式5年了）。
最后一栏是 "虚拟机大小"。正如你所看到的，我有4个核心+4个 "远程 "本地代理（一直运行良好）。系统开始非常可怕地变慢（是的，4GB内存+16GB赠送的PageFile），优化速度趋于无限大。正如你所看到的，CPU的时间，实际上是没有参与。
不建议运行比核心数量更多的代理。过多的代理数量导致速度非线性下降，资源消耗增加。特别是当只有4Gb的内存，而代理商却吃掉了1GB或更多的内存。
不要在你使用终端工作的同一台计算机上安装远程代理。
日志中出现了错误。
这一定是由于缺乏记忆。
我按下 "停止 "键--内存并没有一下子释放出来。在5分钟内，本地代理消失了，再过两分钟，远程内存被释放。
是的，内存（缓存）在大约5分钟后被释放。它们是特意为下一次运行而保留的，这样就不会浪费时间，预热的往往是上一次运行中使用的相同数据。
在最新的构建中，我们改变了处理缓存的方式，为了加快重新运行的速度，增加了缓存。
只是不清楚为什么一个代理会有超过100Mb的空间挂着（我不相信它是被云计算使用的，因为CPU时间没有被使用）。
嗯，我禁用了 "远程 "本地代理。没有任何变化（系统滞后和错误）。
嗯，我认为，错误在我的专家顾问。因此，我正在测试一个标准的ExpertMACD，EURUSD，h12从2007.09.01到2012.03.26。
在升级到最新版本后，你是否重新编译了专家顾问？
在你的情况下，问题是由于不断的交换和缺乏内存而导致的滞后。建议: 禁用不必要的远程代理。
不建议运行比核心数量更多的代理。过多的代理数量导致速度非线性下降，资源消耗增加。特别是当只有4Gb的内存，而代理却要吃掉一G甚至更多的时候。
不要在你用终端进行主要工作的同一台计算机上安装远程代理。
在升级到最新版本后，你是否重新编译了EA？
在你的情况下，问题在于由于不断交换和缺乏内存而导致的速度减慢。
一句话建议：禁用不必要的远程代理。
我禁用了它，运行ExpertMACD进行优化，并。
现在禁用了所有代理（包括本地代理），除了一个。
而现在呢？4GB对一个代理来说是不够的？(虽然内存使用量是350MB，虚拟机大小=1.24GB）。那些连4GB都没有的人怎么办？
你为什么不检查呢？重播步骤见上一篇文章。
你可以看一下云统计--无论是4个还是8个代理--PR仍然在150-190的范围内（除了一个/两个，这显然是落在浏览器的核心上）残疾的远程代理......专家重新编译。甚至常规的ExpertMACD也重新编译了。
禁用，运行ExpertMACD进行优化和。
现在禁用了所有代理（包括本地代理），除了一个。
而现在呢？4GB对一个代理来说是不够的？(虽然内存使用量是350MB，虚拟机大小=1.24GB）。
你为什么不检查它呢？复制步骤见上一篇文章
看一下EA的日志就可以看到这些错误。
选择正确的时间段和正确的设置。如果你使用默认限制，你会产生很多错误的设置。
看一下EA的日志就可以看到这些错误。
选择正确的时间段和正确的设置。如果你使用默认限制，你可能会产生很多错误的设置。
是的，的确，问题原来是出在默认参数上。我改变了它们--一切测试都很好。我回到我的专家顾问--到目前为止，它似乎在 "正常飞行"。
因此，如果说早些时候每个内核有两个代理是可以原谅的，那么现在肯定是不行的。
一句话2。错了，抱歉花了时间（但服务台--#329165还没有弄清楚）。
我们会想办法的。
这要花很长时间。在此期间，我发现了问题所在。
1）在重构代码时，我失去了对变量值的明确赋值，有时（相当随机地）收到随机的开仓量结果。修正了这个错误后，我看到结果并没有改变--测试结果与优化结果并不一致。各种记录和手鼓的技巧帮助我们发现，问题是相当古老的。
2）在锦标赛开始前-2011年，我报告说测试员在周末 做交易。雷纳特承诺会检查。但这个问题至今仍然存在。完全是意外，我选择了测试区间2007.09.01的开始，那是一个周末。因此，优化器在这一天不进行交易，但测试者会进行交易。更准确地说，周末在优化器中没有达到OrderSend，但在测试器中却达到了。根据我的专家顾问的逻辑判断，我成功地发现，如果优化期从周末开始，当计时器第一次响起时，ACCOUNT_EQUITY=0！！！。在测试器中，ACCOUNT_EQUITY = ACCOUNT_BALANCE（这就是我们在初始存款中设置的）。如果优化期的开始是在一个工作日，那么优化器和测试器的行为是相同的。
因此，你有两个错误。
1）优化器允许你在周末开启交易，这是不应该的（不要说这是我的错误--我会纠正我的错误，而测试人员的错误已经挂了半年多了）。
2) 当定时器第一次触发时，如果期初落在输出上，ACCOUNT_EQUITY = 0，而在测试器中ACCOUNT_EQUITY = ACCOUNT_BALANCE。我们需要把它变成同样的形式（当然，最好是ACCOUNT_EQUITY = ACCOUNT_BALANCE，并纠正第一个错误）。
在服务台的请求#329165中，我将附上一位专家进行测试。