Python 为什么在linux APM解决服务器上使用GEKKO时周期会持续增加？

我用GEKKO来研究MPC和MHE对建筑能源使用的影响。为了提高性能，我现在通过设置

m.GEKKO（remote=True，server=True）切换到专用的解决服务器http://10.0.0.10）

。此服务器是一台新安装的Ubuntu 20.04.1机器，只托管linux APmonitor服务器。到目前为止，一切正常，除了我的控制和估计周期时间随着远程解算选项的每次额外解算线性增加。对于MPC，我使用的建筑模型为

IMODE=6

；对于MHE，我使用的建筑模型为

IMODE=5

，两者表现出相同的行为

在下图中，您可以看到本地和远程解算的循环时间和解算时间。这些测试是使用IPOPT MA57解算器进行的，但其他测试显示了相同的行为。除了从

remote=False

切换到我的求解服务器

remote=True，server=True之外，我的程序不会更改http://10.0.0.10“

此外，我在几个步骤（左）和几百个步骤（右）之后添加了解算器的计时诊断输出。它清楚地显示了一个更高的系统时间，但解决时间非常相似，但我在这里也找不到罪魁祸首。除此测试外，我始终设置

DIAGLEVEL=0

和

m.solve（disp=False）

，以减少控制台输出

但是，重新初始化GEKKO模型并再次启动会立即降低循环时间。这表明，随着时间的推移，服务器的计算能力降低并不是问题。对我来说，这看起来像是进程读取和/或写入的某个文件随着迭代次数而膨胀，但我在当前模型目录中找不到任何有意义的内容。也许有人知道这个问题，可以帮我解决这个问题

编辑1:

尝试John Hedengren在其回答中提供的示例脚本，我得到了不同的结果。下图再次显示了相同的线性增长行为。我用不同的物理机器运行了这个测试，也在解决服务器上使用了不同的物理网络适配器。之前，我甚至切换了解决服务器的物理机器。使用Python版本2.7.16、3.7.7和3.8.5进行测试

对我来说，这导致的结论是，这种情况不是由我的MPC申请造成的。它似乎也与客户端、网络或服务器的硬件问题无关。看来这是服务器软件问题

以下是一些规格：

• Ubuntu 20.04.1
• Apache 2.4.41
• PHP 7.4.3
• APMonitor，版本0.9.2

编辑2:

在使用John Hedengrens的示例问题测试多个解决服务器后，我得出结论，周期时间上升的行为并不是我的Ubuntu linux设置所独有的。这里有几个例子：

• CentOS7上带有MA97Solver（LAN）的自定义APMonitor服务器

• Windows 10（局域网）上的APMonitor服务器

• 官方APMonitor解决服务器（Web）
  为了让它变得更明显，我在下一步中移除了欧利埃 图画

在我的例子中，无论使用何种远程解算器，循环时间每1000个循环增加约1秒（对于此示例问题），都会发生（本地解算总是可以的）。如果解算/循环时间更长或循环次数不够多，则这种稳定循环时间增加的效果就不那么显著。然而，对于我的应用程序来说，这是一个非常有问题的问题，因为我必须以尽可能快的速度运行大约40k个周期

编辑3:

实现对

gekko.py

和

apm_line.php

John Hedengren在其回答中建议的更改部分解决了问题，但并非完全解决了问题。循环时间仍在增加。再一次，更近更远的观察揭示了这个问题。下图显示了常用测试脚本的输出，这次是针对更新版本的

gekko.py

和

apm_line.php

linux apm服务器（Windows显示相同的行为）和5k步骤。仔细观察，你甚至可以在John在其答案编辑中发布的图表（1k跑步）中看到这种效果

---

下面是一个示例脚本，它使用远程（公共服务器）或本地解算来解算100个周期。远程（公共服务器）解算器位于带有解算器IPOPT的Linux服务器上。本地解算在Windows 10上使用

apm.exe

。这两个问题都是用Python3.7解决的

将numpy导入为np
从gekko进口gekko
将matplotlib.pyplot作为plt导入
导入时间
对于枚举中的ri，r（[True，False]）：
m=GEKKO（远程=r）
m、 时间=np.linspace（0,10,21）
质量=500；b=m.Param（值=50）；K=m.Param（值=0.8）
p=m.MV（值=0，磅=0，磅=100）；v=m.CV（值=0）
m、 方程（质量*v.dt（）==-v*b+K*b*p）
m、 options.IMODE=6#控制
p、 状态=1；p、 DCOST=0.1；p、 DMAX=20
v、 状态=1；m、 options.CV_TYPE=2
v、 SP=40；v、 TR_INIT=1；v、 TAU=5
s=时间。时间（）；ct=[]；st=[]#周期时间，求解时间
对于范围（100）内的i：
m、 求解（disp=False）
e=时间。时间（）；ct.append（e-s）；s=e
st.append（m.options.SOLVETIME）
plt子批次（2,1,1+ri）
plt.绘图（ct，标签=‘时钟时间’）
plt.plot（st，label='solve time'）
plt.legend（）
如果r：
plt.title（'远程解算'）
其他：
plt.title（'本地解算'）
plt.xlabel（‘循环’）；
plt.ylabel（'时间（秒）'）
plt.show（）

在本例中，求解时间没有线性增加。在应用程序的solve循环中可能还发生了一些事情，使得

remote=True

的时间线性增加。这也可能与网络有关

来自gekko.py的信息

gekko库有不同的远程和本地解决方法。求解rem时

-rw-r--r--. 1 apache apache  76911 Jan 26 07:43 overrides.dbs
-rw-r--r--. 1 apache apache 119305 Jan 26 07:43 overrides.dbs
-rw-r--r--. 1 apache apache 219745 Jan 26 07:44 overrides.dbs