云同步错误 - 页 2

[Slava]

10分钟和20分钟之间有什么不同？没有不同。10分钟对于单次呼叫来说是非常长的时间。你想测试错误的书面EA？没问题。但不要把你的问题扩大到公共云服务器 上。其他用户也想使用云服务器。你可以使用本地代理和远程代理，没有任何限制--欢迎你。

[Alain Verleyen]

cowil:

嗨，斯特林戈。

首先，感谢你提供的信息。

但是，我对MetaQuotes的理由感兴趣。如果使用大量的 "Every Tick "数据（例如，2003.1.1 -> 2013.1.1），并且被优化的专家相当复杂，往往需要超过10分钟 的时间来进行 一次优化 迭代。MetaQuotes选择10分钟作为超时时间，有什么具体原因吗？另外，云用户是否有办法增加这个超时时间，还是MetaQuotes已经 "硬性规定 "了这个时间？

stringo。
仅在云代理上检测到无休止的循环。如果其中一个调用（OnInit, OnDeinit, OnTick, OnTimer等）工作超过10分钟

这不是单一的优化，是对一个函数 的信号调用。

[cowil]

angevoyageur:
这不是一个单一的优化，是对一个函数的信号调用。

啊--我的错误--我脑子里不知怎么想的，我们说的是一次优化迭代，而不是一次对事件处理程序的调用（尽管Stringo特别提到了一次事件处理程序的调用）。对一个事件处理程序的单次调用如果持续超过10分钟，那确实是很荒谬的。我谦虚地道歉--一定是脑子进水了--该让脑子休息一下了。）

嗯--所以在我的专家系统中一定有什么奇怪的事情发生，导致OnTick()偶尔需要超过10分钟才能完成一次调用。是时候开始挖掘了...

无论如何，再次感谢你们的帮助

[Slava]

angevoyageur:
这不是一个单一的优化，是对一个函数的信号调用。

正是如此。单次调用不能超过10分钟，在云计算代理中的一个。

[cowil]

你好。

我还在挖掘，但很难找到任何东西。我的专家在我的本地代理上优化得完美无缺（即我的代理的进度百分比都没有暂停或停止，而我认为如果我的OnTick()函数中存在某种无休止的循环，至少持续10分钟或更长时间，就会出现这种情况），这确实让人感到困难。

有一件事我很好奇--错误信息末尾的PR号码表示什么（例如：".... expert rejected byMQL5 Cloud Network in 600 sec(PR116)"。有谁能对此进行说明？

提前感谢您对这个问题的帮助。

[Alain Verleyen]

cowil:

你好。

我还在挖掘，但很难找到任何东西。我的专家在我的本地代理上优化得完美无缺（即我的代理的进度百分比都没有暂停或停止，而我认为如果我的OnTick()函数中存在某种无休止的循环，至少持续10分钟或更长时间，就会出现这种情况），这确实让人感到困难。

有一件事我很好奇--错误信息末尾的PR号码表示什么（例如：".... expert rejected byMQL5 Cloud Network in 600 sec(PR116)"。有谁能对此进行说明？

提前感谢您对这个问题的帮助。

PR是根据特殊的统一方法计算的代理的性能等级。代理商的PR越高，它完成任务的速度就越快，因此其单位时间的租金价格也越高。

更多信息请看这里。

[cowil]

angevoyageur:
更多信息见这里。

啊--这当然解释了事情。谢谢你的帮助!

[cowil]

你好。

好吧，在周末花了很多时间检查我的代码后，我无法在我的专家号代码中找到可能出现无尽循环的地方。在这个过程中，我也越来越相信，如果我的专家号有无尽循环的问题，我应该在使用我的本地代理来优化我的专家号时看到这个问题变得明显。正如我在上面提到的，我的本地代理在优化我的专家号的任何阶段都不会暂停--更不用说10分钟以上的时间了。

在确信这些问题不是由我的专家号引起的之后，我开始研究其他的选择。我所看到的唯一合乎逻辑的选择是，代理本身有问题（即bug），或者它们所运行的盒子有问题。看起来，第二种选择似乎是罪魁祸首。

据我所知，人们正在各种盒子上运行云代理。我还推测这些云代理都是基于Windows的。我提到这一点的原因是，我自己对消费者版本的Windows的个人经验是，它们在任何长度的时间内都是出了名的不稳定，当有任何严重的处理需求时，往往会减慢甚至停止。

我一直试图执行的优化涉及一个相当复杂的专家，在6-7年的"每一次"数据上运行，即需要合理的处理和内存需求。我怀疑在云中承担这项任务的代理不够规范--特别是考虑到它们是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）。我无法想象有任何64位的机器有8TB的内存--至少，现在还没有。）TERMINAL_CPU_CORES是我考虑过的另一个问题，但最后决定只测试内存，因为我认为任何有相当数量内存的盒子都会在所有其他 重要领域 有适当的规格。

你猜怎么着--没有问题了我所有的优化现在都运行良好。）

[Clock]

cowil:

你好。

好吧，在周末花了很多时间检查我的代码后，我无法在我的专家号代码中找到可能出现无尽循环的地方。在这个过程中，我也越来越相信，如果我的专家号有无尽循环的问题，我应该在使用我的本地代理来优化我的专家号时看到这个问题变得明显。正如我在上面提到的，我的本地代理在优化我的专家号的任何阶段都不会暂停--更不用说10分钟以上的时间了。

在确信这些问题不是由我的专家号引起的之后，我开始研究其他的选择。我所看到的唯一合乎逻辑的选择是，代理本身有问题（即bug），或者它们所运行的盒子有问题。现在看来，其中的第二个选择似乎是罪魁祸首。

据我所知，人们正在各种盒子上运行云代理。我还推测这些云代理都是基于Windows的。我提到这一点的原因是，我自己对消费者版本的Windows的个人经验是，它们在任何长度的时间内都是出了名的不稳定，当有任何严重的处理需求时，往往会减慢甚至停止。

我一直试图执行的优化涉及一个相当复杂的专家，在6-7年的 "每一次 "数据上运行，即需要合理的处理和内存需求。我怀疑在云中承担这项任务的代理不够规范--特别是考虑到它们是Windows盒子。

所以我在我的OnInit()事件处理程序中加入了以下一行代码。

我使用TERMINAL_MEMORY_PHYSICAL的原因是其他的内存选项：TERMINAL_MEMORY_TOTAL和TERMINAL_MEMORY_AVAILABLE并没有什么用，因为它们只为你提供主机处理器的用户模式虚拟地址空间总量（即32位处理器为4GB，64位处理器为8TB）。我无法想象有任何64位的机器有8TB的内存--至少，现在还没有。）TERMINAL_CPU_CORES是我考虑过的另一个问题，但最后决定只测试内存，因为我认为任何有相当数量内存的盒子都会在所有其他 重要领域 有适当的规格。

你猜怎么着--没有问题了我所有的优化现在都运行良好。）

这听起来是个好主意，我很感谢这个提示。

然而，关于这一点，有3件事。

1）正如我上面提到的，我也有 "无尽 "循环的问题，但由于我从这个主题中了解到 "无尽循环 "只是对 "一个事件花了超过10分钟 "的最佳猜测，我接受这可能是我的代码。我使用相当复杂的指标，由于（至少我认为如此）它们在创建句柄时计算其整个历史，这可能（在缓慢的计算机上）需要超过十分钟。

2) 然而!通常我的云计算在10-15分钟后就崩溃了。但是昨天晚上，它完美地工作了8个小时。没有一次崩溃，尽管我根本就没有改变代码。很奇怪!

3) 最重要的是，因为与你的方法有关。当你基于内存拒绝一个代理时，代理（以及整个云）不会崩溃，我明白这一点。但我不认为，更强大的机器会再次尝试相同的参数集，所以你基本上失去了优化数据点，我说的对吗？你说这是我们必须付出的代价吗？

我很想知道，一旦我下班回来，我的代理人是否还能工作......

[Alain Verleyen]

cowil:
...

当 你拒绝所有 内存小于 32G 的人时，有多少代理人 可用 ？