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中,我将附上一位专家进行测试。